Chapter 3 Asynchronous HTTP Server

Chapter 3 Asynchronous HTTP Server

The Asynchronous HTTP Server, which is available only in the ICEfaces Enterprise Edition (ICEfaces EE), 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, but an empty response is returned immediately. Presentation changes resulting from the request will ultimately be delivered using the blocking request mechanism. In the ICEfaces Community Edition (CE), the Blocking Servlet handles all of this communication. See Figure 1.

Figure 1 Asynchronous Mode CE Deployment Architecture

ICEfaces EE introduces the Asynchronous HTTP Server, which handles thread-level scalability issues. It is designed to support clustered application deployments, but for the sake of this discussion we examine the deployment architecture for a single application server with one or more ICEfaces applications deployed to it.

Note: Clustered deployments are discussed in Chapter 4.

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 via an application server-specific plugin. The Web server can also be configured to do user authentication, and use SSL for security. The basic ICEfaces EE deployment infrastructure, including Asynchronous HTTP Server and front-end Web Server, is illustrated in Figure 2 below.

Figure 2 Enterprise Edition Deployment Architecture

The remainder of this chapter describes the deployment configuration that must occur to support enterprise deployments of ICEfaces applications. The basic steps include:

1. Configuring the application server to provide necessary JMS support.

2. Configuring and deploying the Asynchronous HTTP server.

3. Configuring the ICEfaces application to use Asynchronous HTTP server.

4. Configuring the front-end HTTP web server to support required message paths.

An example of the configuration described in the section can be found in the ICEfaces EE release in the tutorials/timezone-enterprise directory. This example takes the Timezone 5 tutorial found in the ICEfaces Getting Started Guide, and converts it into an ICEfaces enterprise deployment using the Asynchronous HTTP Server, and an Apache web server front end.