In this article, I am going to examine a few of the established techniques that became popular for delivering dynamic content in the pre-websocket environment.
Cross Frame Communication
Cross frame communication is a technique that allows content to be loaded into the current page and giving the user the impression of an application style experience.
This method works by loading a new page from a server into a hidden frame. The data from that page is then retrieved and displayed in the current page visible to the user. This could be achieved without reloading the current page, and therefore giving the impression that the data was loaded directly from the server.
The polling technique is similar to cross frame communication, in the sense that it makes periodic requests to the server for data and it does this regardless of whether there is new data or not. For each request, a new connection is made, so it’s easy to see how this is very inefficient and makes the web page very chatty.
Long polling is an improvement on this technique. The client establishes a connection to the server and holds the connection open until it is closed. The server sends data to the client when there is new data available. This simulates a server push type feature. The advantages over simple polling are that data is sent only when it is necessary, and so, therefore, using server and client resources more efficiently. It also performs well with low traffic, but does not scale well and can be prone to latency issues at higher processing levels.
The main feature of AJAX is that it is non-blocking. This means that the user does not have to wait for the response and can continue using the site. When a response is received by the client, a callback method is executed and passed the response data.
Typical examples of AJAX in action would be, auto-completing drop downs and news tickets.
This is a great solution and has been used very effectively for many years, but suffers from one major drawback, which is that its behaviour when moving high volumes of data creates a bottleneck.
I have describes some of the most popular solutions for providing real-time, bi-directional communication between client and server, and they have served us well for much of the last decade or so, but they suffer from the same main issues:
- They are very resource intensive and use those resources inefficiently. This may occur on either the client where data has to be moved and processed or on the server side when unnecessary requests are made for data.
- All techniques use the HTTP protocol, which is a text-based protocol, which sends complete headers with each request and response. This makes each communication larger and inefficient. Although the HTTP/2 protocol, which is a binary protocol, benefits from header compression.
- Except for AJAX, these solutions are really just workarounds that overcome the limitations of HTTP and browsers. Wherever you see a hack, you’ve got to think that there is an inadequacy in the technology that needs to be addressed.
- And most importantly, the communication is not full duplex; it’s only half-duplex which means that one end of the communication must wait for the other end to finish before it can act.
The Websocket Solution
All of the issues associated with these workarounds disappear when the websocket protocol is implemented. The websocket protocol is lightweight, bi-directional and provides a fully-duplexed communication channel that is supported by all modern browsers. It is relatively simple to implement and is specifically designed to solve the problems of delivering dynamic rich media content.
Java EE Websocket Course
Test Drive the Course
You can take advantage of a free trial to Lynda.com and test drive all my courses. They are
- An Introduction to Java EE
- JAX-RS RESTful web services
- Websocket Programming for Java EE
- Bean Validation
- JSON Processing
- Context and Dependency Injection (CDI) and
- Java EE patterns and architecture.
Here is some article that you might be interested in reading.