We Keep Coding

Easy way to generate web service clients in Java WITHOUT using Axis

I've always used the web service generation in Eclipse WTP to build my web service clients due to it's relative easy of use.
However, in the last couple years, as I've learned more about it I've seen the error of my ways.
I've read that one should use one of the plethora of other java web service client platforms such as CXF, Metro, etc.
At this point, I don't particularly care which platform I use - so long as it is not Axis.
My question is - the WTP tooling makes it easy to generate web service clients in java. Are there any similar tools, scripts, programs or tutorials that are of similar ease of use?
I don't really have time to learn all the intricacies of SOAP, RPC, etc. so please keep in mind that I'm not really trying to be lazy so much as I am pragmatic.
Thanks in advance.

SoapUI can generate the soap clients for many multiple java soap stacks like axis 1 & 2, xfire, GStep, JAX-WS, JAX-RPC, JBoss WS, Oracle Proxy, cxf, .Net, GStep. Here is the tutorial on how to do it.

Best Java framework for server side WebSockets [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to create simple server having low load. The goal is to give a few javascript clients access to some functionality implemented in Java through WebSockets. I seek for best library to use for that - it should be simple, robust etc. Now I consider 3 alternatives
- jWebSocket
- jetty
- netty
What is the best? Or may be something else?
Thanks in advance

I'd go with proven Java servlet servers: Jetty or Resin. The have both been extended to handle WebSockets:
Jetty WebSockets
Resin WebSockets
My personal choice would be Jetty, as it's very simple to use and I've been using it as embedded server in several projects.
There are also some new kids on the block like Atmosphere and jWebSocket, but for servers I prefer to go with a proven solution. Jetty and Resin are also generic Servlet servers, so you can go with one product for all your serving needs.

jWebSocket now includes the Jetty 8.0 engine including SSL and includes many nice-to-haves on top of it. It provides cross-browser and cross-platform compatible clients even more mobile apps e.g. under Android, Symbian and BlackBerry. The server can easily be extended with plug-in and already includes lots of them (e.g. for Authentication/Autorization, JDBC, SMTP, XMPP/Jabber, RPC, Twitter, Filesharing, Chat etc.). Just check it out... http://jwebsocket.org. Looking forward to your feedback.
Regards
Alex

The PlayFramework! is the other very good option.

FYI, Atmosphere run on top of Resin, GlassFish and Jetty. Atmosphere free you from being stuck with one server by giving you Websocket portability amongst Websocket server. It also offer a client library that can be select the best transport in case websocket isn't supported by the browser. So you can't compare Atmosphere with Jetty or Rsin

Take a look at Atmosphere. Here is an article about websocket and atmosphere.

While I value the implementations of JWebsockets and Autobahn a lot, I prefer Atmosphere.
Ramp-Up::
Ramp-Up time is low. Francois Arcand puts a lot of effort into testing and examples, helping everyone to achived quick wins. (And I have no clue why he's able to respond so quickly to any architectural questions I rise. Impressive.)
Maintenance Perspective::
To me, maintainability is fundamental, if a software goes beyond major release version 1.0.0. The project is maintained at a top Maven-POM level with a properly constructed hierarchy. It prevents library incompatability. Libraries are reference at the correct level. That is well done.
Technical/Functional Perspective::
It offers a Java SE client library (wasync) that can either do native websocket communication (onMessage) or build on Jersey REST annotations (#Path). Subsequently this makes it as simple as it gets with the benefit of maintaining an open connection for subscriptions and the popular remote procedure calls (RPC) paradigm. It is a common attempt to merge those two paradigms. See also http://wamp.ws/, which heads for the same approach. Also, the library offers to establish QoS properties like robustness (e.g. in case a client disconnects) and reliability (caching undelivered messages). That is great for professional software to harness.

Maybe you should try Bristleback Server? Using Bristleback, you may choose from several WebSockets engines, like Jetty, Netty and Tomcat. You can have standalone server as well as web application that uses WebSockets (Jetty and Tomcat 7). Bristleback uses Spring Framework. If you have worked with web frameworks like Struts, Stripes or Play!, it will be very easy for you to start. Of course, Bristleback has its own JavaScript client library for even easier development.
Full disclosure: I am one of the co-creators of Bristleback Server.

I would also add vert.x to the list. It can server Websockets and SockJS (websocket emulation when the browser doesn't support them).
Update:
Undertow http://undertow.io also supports websockets.

Follow my blog. I'll be ready for release sometime in the not too far off future. Light-weight has been emphasized through the whole thing - but it's also fast. I don't know yet how well it will ramp up to higher loads. But I've been running the demo for a while now with relatively low load and what I have has been working well. (I'll test heavier loads later and make sure that it can be ramped up.)
http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html

If you are looking for infrastructure around message management, user grouping ("rooms"), and data synchronization ("shared variables"), you might want to consider Union Platform:
http://www.unionplatform.com
[Full disclosure: I am one of the co-creators of Union]

Why don't you just write your application on an open standard like JMS, and let the clients sit on the JMS bus as message clients?
The whole point of websockets is to bring any native TCP protocol directly to the client instead of converting it from your back end to http request/response.
Your back end services would talk to a JMS broker like ActiveMQ, and your clients speak AMQP in the browser via a Javascript API that looks just like the JMS API in Java. All you need for that is a websocket gateway, for example Kaazing has such a gateway, all it does is route your JMS TCP traffic out to the web clients over websockets. They also provide fan-out so that you don't overload your JMS bus, i.e. you just use a handful of connections to the broker to offload a million browser client connections.
The bottom line is that you don't need to tie yourself to any specific platform. Stick with standards, that way you have 100% freedom to swap out components as your environment changes.

How to make my Java Swing application a Client-Server application?

I have made a Java Swing application. Now I would like to make it a Client-Server application. All clients should be notified when data on the server is changed, so I'm not looking for a Web Service. The Client-Server application will be run on a single LAN, it's a business application. The Server will contain a database, JavaDB.
What technology and library is easiest to start with? Should I implement it from scratch using Sockets, or should I use Java RMI, or maybe JMS? Or are there other alternatives that are easier to start with?
And is there any server library that I should use? Is Jetty an alternative?

Given that you have the application already, perhaps the simplest thing to do is to identify the interface that you require between the client and server, and first of all to refactor your application to use that interface to talk between the back-end/front-end within the same process.
Then you can start to split this apart. A simple solution would be to split this apart using RMI (since you're talking Java objects and have Java method calls). Spring contains useful tools to simplify/automate the RMI exposure of interfaces.
For the notification requirement, a simple UDP multicast (or broadcast) would suffice.
Note that as soon as you split your application up, you have issues re. maintaining consistent views of data, managing timely updates, handling cases when the server is down, possible loading issues when you get lots of clients etc. In a sense, splitting the application up into a client and server is just the start of a new architecture process.

Mina is a good choice as a network application framework for building a simple server for this purpose - it's a much better option than using raw sockets.
http://mina.apache.org/
If you really need an application server then you could take look at JBoss. It also provides a remoting component (as an alternative to something like Mina):
http://www.jboss.org/jbossremoting
You probably won't have much need for Enterprise Java Beans though. In most cases a simple POJO based framework is more than sufficient - you could tie this altogether with a dependency injection framework such as Guice:
http://code.google.com/p/google-guice/
or Spring. Keep it simple, don't use a J2EE server unless you really need to. Hope that helps.

This is much of what J2EE does, but it's a whole new learning curve because they have pre-solved many of the problems you will run into and many you may not and therefore add on a lot of new technologies.
But at it's most basic, J2EE answers just that question.

I worked in a project like this. We implemented Client-Side Swing and Server side with J2EE. We used EJB,Stateless beans and Message Driven Beans.Also I have been in a device tracking, management project. Our clients were trucks+Swing users and We have used Servets+TCP/UDP,Apache Mina framework to handle and keep connections.

I have been working in Java Swing Client/Server applications for almost 3 years. I would suggest you to go for RMI/EJBs. The initial application that we developed was doing this using RMI/EJB for client-server communication with WebLogic being the server.
But we later found out that there are lot of "browser-like" features to be included to the application such as session-timeout etc., So, we used the BrightSide Framework which wraps the RMI calls through HTTP. One more enhancment we made is that we replaced Weblogic with the open source JBoss server.
The wrapping of calls with HTTP will become very handy and you can make your swing applications really rich. Later, when the situation demands for you to use a website strictly, you can deploy your swing using jnlp.
Hope this helped.

Is there a want for a Java 7 Cloud Server Framework that is not Spring/Tomcat based?

Is there a demand out there for a small, lightweight, Java 7 based open source project that is geared toward making Cloud services more elegant? I have written several servers in my lifetime, and was curious if there was a need for this.
My thoughts were to keep it simple, lightweight, and use the Java 7 NIO 2 functionality for network communications. I was also thinking of using either a broadcast address for local cloud based communications between servers in a rack solution (MBONE) or a serialization-based communications protocol.
I don't want to use Spring or Tomcat, as they are overweight, and they are written on older Java technology. Furthermore, I don't want to use another Apache project because it's too dependent on Apache technologies. Keywords here are "small", "lightweight", "portable", and "efficient".
Maybe this will even have the potential of being installed and used in mobile devices as background servers, or even mobile cloud networks.

From my own point of view, no.
If I want a lightweight servlet server, I use Jetty.
If I want a more powerful, versatile Web app server, I use Tomcat.
If I want a full J2EE server, I use Glassfish.
All of these are of course highly proven. Memory is cheap enough these days that I'm not very worried about a little bloat. That comes standard with Java apps :)
Also, I'd consider it crazy to deploy server technology on mobile devices. Maybe other people have bright new ideas, I think mobile devices should communicate with central servers.
I would probably not want to use a Java 7 server not based on J2EE, at least the servlet part, unless someone comes up with a really compelling alternative. On the other hand, I wonder how small you could make a compliant server.
Finally, as far as I know, Tomcat already (optionally) supports nio: http://tomcat.apache.org/tomcat-6.0-doc/aio.html .
Strictly a personal opinion from an old curmudgeon.

What is the best way to make a .net client consume service from a Java server?

I have a user interface in .net which needs to receive data from a server, on a request/reply/update model. The only constraint is to use Java only on the server box.
What is the best approach to achieve this ? Is it by creating a Webservice in Java and then accessing it in .net, or should I create Java proxies and convert them in .net by using IKM ? Or do you have any better idea ? It can be HTTP based, used a direct socket connection, or any middleware.

I recommend the web service route. It offers a standard interface that can be consumed by other client platforms in the future.
.NET clients interact with Java web services pretty well, though there are some gotchas. The best two technologies available for you for the .NET client are Microsoft Web Service Enhancements (WSE) and Windows Communication Foundation (WCF). WSE is an older technology that is no longer being updated by Microsoft, but still works great in Visual Studio 2005 and older. I find WSE to be a bit easier to get started with in terms of how you interface with basic services, but WCF has much more support for WS-* protocols (security, trust, etc.). If your needs are basic and you're still using Visual Studio 2005 (.NET framework 2 or older), then go with WSE. If you like the cutting edge, or you anticipate more advanced security needs (doesn't sound like you will), then go with WCF. Please note that WSE will not work easily in Visual Studio 2008 and newer, and WCF will not work in Visual Studio 2005 and older.
Going the web service route will mean that you will design to an interface that can be reused and will result in a more loosely coupled system when you're done than most of the other routes. The downside is primarily performance: xml serialization will be slower than binary over the wire, and web services do not handle large amounts of data well.

Write webservice in Java and access it in .net

Using a standard type of web service (e.g. SOAP or XML-RPC) is best because not only is it easy to produce/consume, it's easy in other languages as well.