Modern web applications aim to provide users with an exceptional and engaging experience by offering advanced services.
Think about push notifications offered by messaging and voice apps or instant chat services offered by retailers. How are these services integrated within apps?
Dynamic services—such as real-time notifications, geographical information and streaming content—require that specific information is pushed from the server to the client, with low latency and within the context of the specific application.
There’s an old way and a new way to handle dynamic services in an application, and in this post I will compare and contrast the traditional approach based on HTTP protocol with the new capabilities offered by the WebSocket. In addition, the WebSocket protocol discussed here is implemented in an IBM product, WebSphere Application Server Liberty Core profile 8.5.5 beta.
The old way
The design and implementation of dynamic application services has traditionally used the request-response paradigm offered by the HTTP protocol. This approach is far from trivial for a wide array of reasons, as explained below.
Since the information available on the server side should be sent to the client in a timely fashion, there is a need for bidirectional communication. Given the dynamic user interactions, both participants—the client and server—should be able to transmit data over the communication channel in full-duplex mode.
Although the HTTP protocol was not designed to support this kind of communication, in the last few decades several client-server integration patterns have been explored to address the requirements for bidirectional communication, including the following:
Basic polling. The client application polls the server periodically to check the availability of new information. This polling strategy works fine only when data is available in predicable fashion and polling frequency is not so high as to avoid the overhead associated to the creation of a new connection.
Long polling. The client application establishes the connection to the server, and this connection is kept open to allow the server to send data. Once the server has sent data, the client will immediately open a new connection to the server. Although this polling communication loop allows the server to send content as it is available, the overhead associated with looping the connection can be prohibitive even for moderate volumes.
Streaming. The client establishes the initial connection to allow the server to send data when available. The server will use this connection to continuously send data to the client as a stream. While this approach addresses the requirement for a server-to-client communication, it doesn’t allow the client to send requests across the established connection.
Multiple connections. Two separate connections are maintained from client to server and from server to client to allow two single-duplex communications. This approach is impractical in real life, given the complexity associated with the coordination of two separate connections and the overhead associated with the management of two connections for every client.
The new way: WebSocket
The WebSocket protocol was introduced in 2011 to overcome the limitations of HTTP-based approaches and to efficiently address the requirements set by low-latency applications.
Developed as part of HTML5 specification, the WebSocket is a protocol that offers a full-duplex communication channel over a single TCP/IP connection.
To establish a WebSocket connection, the client initiates the handshake request to the server. Upon completion, the connection is established and the client and server can exchange messages over this connection in full-duplex mode.
Compared to HTTP and custom extensions, the WebSocket offers a wide array of benefits, including the following:
Efficiency in nature. A single TCP connection is maintained to support the communication between client and server over a potential extended period of time.
Bidirectional and full-duplex by design. The client and server can exchange data over a single connection any time and concurrently.
Proxy and firewall friendly. WebSocket uses the HTTP handshake semantics to establish the connection, making it suitable to be used in any existing networking infrastructure.
The WebSocket protocol has undergone several standardization processes, becoming an Internet Engineering Task Force (IETF) standard (RFC 6455), while the associated WebSocket API has been incorporated into the Web IDL browser specification. In addition, WebSocket has been incorporated into the Java Enterprise Edition 7 platform (JSR 356), becoming a standard service offered by application servers.
IBM WebSphere Application Server Liberty profile 8.5.5 beta offers preliminary support to the WebSocket API protocol. Learn how to implement WebSocket applications on Liberty profile by walking through this tutorial.
What is your experience with the WebSocket protocol? Have you seen the benefits of this approach to powering dynamic web applications? Please share your thoughts! Connect with me on Twitter @_freddies.