Extending AJAX applications with asynchronous servlet--multiplexing client sockets

The advent of Ajax as a Web application model has changed the face of the server side dramatically. Users fill out a form on a Web page and click the Submit button to go to the next link the typical Web usage mode is now being transformed into more advanced Client JavaScript and a richer user interface, as long as the form is manipulated, such as clicking a check box, By pressing a key or moving the mouse over a tab, the user interface continues to interact with the server.

Consider how much data is transferred from the client to the server. From a usability standpoint, users get a rich user interface on a thin client browser without having to install anything. However, when extending these applications on the server side, there is a price to pay. Typical capacity plans for Ajax applications can be 3 to 4 times times that of standard Web applications.

One might ask: How does this affect the WebLogic server? Each HTTP request sent to WebLogic uses an execution thread. Depending on the nature of Ajax programming and the constant dispatch of many short-term requests in the form of polling, this behavior pattern can cause a large number of client requests to continually impact the server situation. Over the years, WebLogic has taken this issue into account and has built a pretty good feature, the Futureresponseservlet. This paradigm is built on the basis of the asynchronous servlet concept. Starting with version 6.1, this feature allows developers to provide truly asynchronous notifications from the server without requiring client rotation of events and using thread execution on the server side. Before 9.x, Bea was in no hurry to expose the class.

How do you use this class in real life? Let's take a look at an example. Suppose the business requirement is to build a web-based application that sends data to the server in an almost real-time manner without refreshing the browser. Such an application can submit a request to the server that takes a long time to process, and still be able to receive asynchronous events about its state and listen for events. From a technical point of view, there are many ways to implement this. One approach is to use a Java applet that communicates with the Java servlet to obtain asynchronous information. This is a good approach, but it's a little inconvenient for users because they have to download a JVM and download an applet to the browser. In addition, you must maintain a persistent socket connection from the client to the server to receive asynchronous messages. Imagine that if 1000 users use the applet, then 1000 execution threads are almost empty waiting to send an event notification to the client. Of course, there are other methods, such as building polling mechanisms from applets or AJAX applications to periodically check for new data. If the data is not often received, polling becomes useless, and the server resource is wasted and the execution thread is consumed. Instead, the server can poll periodically, propagate the event back to the client, and maintain the socket thread without using a persistent thread of execution. This is very similar to how Java NiO is run. Ideally, we would like to build an application that receives event notifications asynchronously from the server without using persistent thread execution on the server side, whether it is an applet or a thin Web application based on Ajax.