Web Services Tier

Design strategies for the Web Services tier are directly influenced by the characteristics of the software components that run on the Web server. These components include static Web pages, Java Server Pages (JSP), and servlets. In this section we describe the important characteristics, how they work, and how they impact the design of the network architecture.

The Sun ONE Web server will be used to illustrate the concepts presented in this chapter. It is important to note that the Sun ONE Web server can be deployed as a standalone product or as an integrated component within the Sun ONE Application server. This has implications on the design strategies detailed in this chapter.

FIGURE 2-4 provides an overview of a high-level model of the Presentation, Web, Application, and Data-tier components and interfacing elements. The following describes the sequence of interaction between the client and the multi-tier architecture:

1. Client initiates a Web request; HTTP request reaches Web server.

2. Web server processes client request and passes request to backend Application server, containing another Web server with a servlet engine.

3. Servlet processes a portion of the request and requests spurring service from an Enterprise Java Bean™ (EJB) running on Application server containing an EJB container.

4. EJB retrieves data from database.

Figure 2-4. Model of Presentation/Web Tier Components and Interfacing Elements

The Sun ONE Application server comes with a bundled Web server container. However, reasons for deploying a separate Web tier include security, load distribution, and functional distribution. There are two availability strategies that depend on the type of operations that are executed between the client and Web server processes:

• Stateless and Idempotent If the nature of transactions is idempotent (where the order of transactions is not dependent on each other), then the availability strategy at the Web tier is trivial. Both availability and scalability are achieved by replication. Web servers are added behind a load-balancer switch. This class of transactions includes static Web pages and simple servlets that perform a single computation.

• Stateful If the transactions between the client and server require that state be maintained between individual client HTTP requests and server HTTP responses, then the problem of availability is more complicated and discussed in this section. Examples of this class of applications include shopping carts, banking transactions, and the like.

The Sun ONE Web servers provide various services including SSL, a Web container that serves static content, JSP software, and a servlet engine. Availability strategies include a front-end multilayer switch with load balancing capabilities and the ability to switch based on SSL session IDs and cookies. If the Web servers are only serving static pages, then the load balancer will provide sufficient availability; if any Web server fails, subsequent client requests will be forwarded to the remaining surviving servers. However, if the Web servers are running JSP software or servlets that require session persistence, the availability strategy is more complex.

Implementing session failover capabilities can be accomplished by coding, Web container support, or a combination of both. There are actually several complications, including the fact that even if the transparent session failover problem is solved for failures that occur at the beginning of transactions, idempotent transactions still pose a problem for transactions that have started and then failed because the client is unaware of the server state. A programmatic session failover solution can involve leveraging the javax.servlet.http.HttpSession object, storing and retrieving user session state to or from an LDAP directory or database using cookies in the client's HTTP request. Some Web containers provide the ability to cluster HttpSession objects using elaborate schemes, but they still have flaws such as failures in the middle of a transaction. These clustering schemes involve memory-based session persistence or database-based persistence and a replicated HttpSession object on a backup server. If the primary server fails, the replica takes over. The Sun ONE Web server availability strategy for HttpSession persistence offers extending the IWSSessionManager, which in multiprocess mode can share session information across multiple processes running on multiple Web servers. This means that a client request has an associated session ID, which identifies the specific client. This information can be saved and subsequently retrieved either in a file that resides on a Network File System (NFS) mounted directory or by having the database IWSSessionManager create an IWSHttpSession object for each client session. The IWSSessionManager will require some coding efforts to support distributed sessions so that if the primary server that maintained a particular session fails, the standby server running another IWSSessionManager should retrieve the persistent session information from persistent store based on the session ID. Logic is also required to ensure the load balancer would redirect the client's HTTP request to the backup Web server based on additional cookie information.

Currently there is no support for SSL session failover in Sun ONE Web Server 6.0.

HttpSession failover can be implemented by extending IWSSessionManager using a shared NFS file or database session persistence strategies, providing user control and flexibility.