Chapter 1 Introduction to the Asynchronous HTTP Server

Chapter 1 Introduction to the Asynchronous HTTP Server

The Asynchronous HTTP Server (AHS) is an HTTP server capable of handling long-lived asynchronous XMLHttpRequests in a scalable fashion. In the standard Servlet model, each outstanding asynchronous XMLHttpRequest occupies its own thread, which means that thread requirements can grow linearly with the number of clients. The long-livedness of these requests will have significant impact on thread-level scalability of the application. If server-initiated rendering occurs frequently, thread consumption will be somewhat mitigated, but if server-initiated rendering occurs infrequently, large numbers of users will cause excessive thread consumption, and the scalability of the application will be compromised. It is strongly recommended that the Asynchronous HTTP Server be used in all ICEfaces application deployments where asynchronous update mode is used.

Before discussing the architecture of an Asynchronous HTTP Server deployment, it is useful to review the communication pattern that ICEfaces uses in Asynchronous mode. Asynchronous updates are primed with a blocking request from the client. When a render occurs in the JSF lifecycle, a response is produced and the blocking request is satisfied. When the response is received at the client, another blocking request is generated. ICEfaces also uses non-blocking requests for user-initiated interactions via the full or partial submit mechanism. Non-blocking requests are passed to the ICEfaces application. In ICEfaces, the Blocking Servlet handles all of this communication. See Figure 1.

Figure 1 Asynchronous Mode Deployment Architecture

The Asynchronous HTTP Server handles thread-level scalability issues. It is designed to support single as well as clustered application server deployments with one or more ICEfaces applications deployed on it.

The Asynchronous HTTP Server is deployed as a separate application in the application server, and it occupies a single port on the network. Individual ICEfaces application deployments use Java Messaging Service (JMS) to communicate with the Asynchronous HTTP Server. Blocking requests are queued at the Asynchronous HTTP Server on a per client basis, and as responses become available, they are communicated to the Asynchronous HTTP Server, again via JMS. A response is matched to its associated blocking request, the request is unblocked, and the response is returned to the client. Because it is possible for a response to be generated prior to a request arriving, the Asynchronous HTTP Server also queues up responses waiting for requests that it can satisfy.

The deployment architecture is fronted with an HTTP web server that filters blocking request and directs them to the Asynchronous HTTP Server for processing. Non-blocking requests are passed directly to the ICEfaces application possibly via an application server-specific plug-in. The web server can also be configured to do user authentication and to use SSL for security. The basic ICEfaces enterprise deployment infrastructure, including Asynchronous HTTP Server and front-end web server, is illustrated in Figure 2.

Figure 2 ICEfaces Enterprise Deployment Architecture