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.