Application Services Tier
Design strategies for increased availability for the Application Services tier can become complex because of the different entities with varying availability requirements. Some entities require failover mechanisms and some do not. This section presents a survey of various availability strategies implemented by various vendors and then discusses examples of the various Sun ONE Application Server architectures and associated availability strategies.
At the Application Server tier, you are working with the following entities:
HttpSession – This is the client session object that the Web container creates and manages for each client HTTP request. Session failover mechanisms were described in the previous section.
Stateless Session Bean – This type of EJB does not require any session failover services. If a client request requires logic to be executed in a stateless session bean, and the server where that bean is deployed fails, an alternative server can redo the operation correctly without any knowledge of the failed bean. Failure detection by the client plug-in or application login must detect when the operation has failed and reinitiate the same operation on a secondary server with the appropriately deployed EJB component.
Stateful Session Bean – This type of EJB component requires sophisticated mechanisms to maintain state between the primary and backup—in addition to the required failover mechanisms described in the Stateless Session Bean case.
Entity Bean – There are two types of Entity Beans: Container Managed Persistence (CMP) and Bean Managed Persistence (BMP). These essentially differ in whether the container or the user code is responsible for ensuring persistence. In either case, session failover mechanisms other than those already provided in the EJB 2.0 specification are not required because Entity Beans represent a row in a database and the notion of session is replaced by transaction. Clients usually access Entity Beans at the start of transactions. If a failure occurs, the entire transaction is rolled back. An alternative server can redo the transaction, resulting in correct operation.
The degree of transparency of the failover requires some consideration. In some cases, the client is completely unaware that a failure occurred and an automatic failover action took place. In other situations, the client times out and must reinitiate a transaction.
FIGURE 2-5 shows an abstract logical overview of the various transactions that can transpire among a client, a Web server instance, and an Application server instance. Note that the firewall is not shown to simplify our discussion. FIGURE 2-5 illustrates three scenarios: Points 1 through 7 depict one scenario, Point 8 depicts the second scenario, and Point 9 depicts the third scenario. The numbered arrows in the figure correspond to the following:
Scenario 1
A client makes an HTTP request, which may contain some cookie state information to preserve state between that individual's HTTP requests to a particular server.
The load balancer switch ensures that the client's request is forwarded to the appropriate server.
The JSP software or servlet retrieves a handle to a remote EJB object residing in the application server instance.
The client must first find the home object using a naming service such as Java Naming and Directory Interface (JNDI). The returned object is cast to the home interface type.
The client uses this home interface reference to create instances.
The client continues to create instances.
The application server provides replication services. When an EJB object is updated on the active application server instance, the standby server updates the corresponding backup EJB object's state information. These replication services are provided by the application server systems services.
Scenario 2
A JNDI tree cluster that manages replication of the EJB state updates and keeps track of the primary and replicated objects. This scenario occurs when vendor implementations use a modified JNDI as a clustering mechanism. In the standard JNDI implementation, multiple objects cannot bind to a single name, but using added logic, each member of a cluster can have a local and shared global JNDI tree. If the primary object fails, the JNDI will return the backup object bound to a particular name. If a failure occurs after a client has performed a JNDI lookup, the client will hang or time out and try again. The subsequent request will be directed to a secondary server, which will have the correct state of the failed node of a particular entity.
Scenario 3
This scenario simply forwards the HTTP request to the Application server using a plug-in. The HTTP request would be received by the Application server's HTTP server. The HTTP request would recursively arrive at point 2 in FIGURE 2-5.
Another mechanism includes adding a replica-aware or cluster-aware stub to the EJB objects and system services including a cluster module that runs on the appserver, which is loaded in the deployment descriptor, if specified. The cluster module might consist of various subsystems that provide data synchronization services, keep the state of the backup EJB object synchronized with the primary, manage cluster failovers, and monitor the health of the appserver instances. If the primary appserver instance fails, the cluster failover manager can redirect client-side EJB method invocations to the backup node.
Another approach involves the primary and secondary cluster nodes inserting and altering a cookie on the client's HTTP request, which would apply in the case where the Web server and app server reside on the same server. If the primary node of the cluster fails, the load-balancing switch must be configured to redirect the request to the backup node of the cluster. The backup node must look at the client's cookie and retrieve state information.
However, most of these solutions suffer one drawback: Idempotent transactions are not handled transparently or properly in the event that a failure occurs after a method invocation has commenced.
At the time of this writing, the Sun ONE Application Server 7 Enterprise Edition is expected to provide a highly available and scalable EJB clustering solution that allows enterprise customers to create solutions with minimal downtime.