How does websockets maintain persistent connection and how stable it is to be used on live?

Question

I am in need of a event based server where data is pushed to the client readily. As i have read in forums that websocket based servers are my best bet. Please explain it working and how stable is its usuage on production boxes ?

Answer 1

Because web sockets are so new I don't believe that many application servers have great support for web sockets yet. For example Tomcat states the following "Tomcat provides support for WebSocket as defined by RFC 6455. This feature is not yet finalised and you are encouraged to provide feedback in the form of bug reports". However, you can utilize the advantages of web-sockets if you view your architecture in a slightly different way. A sample application that would be sending event based stock quote changes could work in the following logical steps.

1) The client application (web app or other web-socket enable app) would establish a web-socket connection with the requested resource serving server.
2) The server would then be responsible for receiving an external (backend event) and selecting which clients receive the corresponding message.
3) That message would then send over the websocket connection to the client. Websockets as defined by the standard should allow that connection to remain open as long as the client is online and should deliver that data in near real time. Moreover, it will offer the advantage of running on standardized ports/protocol that can be reliably delivered over the web.

From this you can see there are really 4 logical parts of the infrastructure. 1) The backend that is customized to receive the events. For stock quotes this would be the institutions back end. 2) The message broker that is responsable for logically linking the events to the corresponding clients. 3) The websocket connection to the client. and 4) The client itself

The backend: can really be written in whatever is necessary to connect to your events. For the stock quote system this would be some custom application linked into a financial service provider

For the Message Broker I would suggest you use JMS or AMQP to handle your "event based service". These message brokers are well defined and used in a lot of enterprise applications. From a hardware point of view they could run directly on your back end or separately. Moreover, they offer you a wide variety of services (point to point, publish subscribe etc) that you may want to utilize in your application. Alternatively, if you wanted to create your own custom messaging service you could use something like Netty.

For the websocket connection you will need a service that can easily and reliably connect to your message broker system. For example, Kaazing (Disclaimer and full disclosure I work for Kaazing) offers both an enterprise AMQP edition and JMS edition that could connect directly to you message brokers.

Issues with the client: Include whether the browsers support web-sockets and what fall back mechanisms are (long polling, ajax). These are really dependent upon what service you use to create your websocket connection. While there are are plenty of open source services that provide fallback mechanisms, Kaazing also offers an emulated websocket connection that logically works more like websockets rather than the fallback mechanisms (long polling/ajax) that websockets were created to replace.

IN TERMS OF STABILITY: JMS and AMQP are widely used and stable. There is an impressive list of industry users that are already operating on their technology.

Check out this living web architecture white paper for more detail