In enterprise application architecture, it is naïve to assume that none of the software/hardware components will go down. In fact, most of the IT managers and architects acknowledge this. However, a well-tested and robust recovery procedure continues to take a back seat when designing and implementing software projects. In several scenarios, administrators end up performing basic failover testing by shutting down the processes and verifying that the subsequent requests succeeded.

Although this level of testing can satisfy the failover requirements for the records, more robust failover testing needs to be performed to ensure a proper recovery if failures do occur. One of the primary reasons for the lack of robust recovery and well-tested procedures can be attributed to a high degree of reliance on the application server's in-built failover capabilities. While it is true that most of the popular application servers boost their clustering and associated high-availability features, it is equally important that system architects need to go beyond those features for an end-to-end high availability of the application. This article suggests how good planning, robust scripting, and a well- thought-out application design, along with application server facilities, can provide a highly available environment for the entire application. In the first article in a series of three, I will cover the basic high-availability options available while deploying a J2EE application on WebLogic Server.

Before diving into specifics, it is important to understand some of the commonly used terms when one talks about high-availability.

High Availability - So, what does high availability really mean? From a user's point of view, it means an application that is always available to perform the user's transactions. In other words, even though one or more of the back-end system becomes unavailable, the application may be architected in such a manner that these failures are not visible to the end user. High availability is a relative term - for some applications, there is high availability only if the site is never down - or zero downtime. For some applications it should be available, without interruptions - during the normal business operations. How and when a system is called highly available is typically defined by SLA - Service Level Agreements. Each organization may have its own system level agreements for the nonavailability of the applications during certain maintenance windows.

Transparent Failover - A highly available system does not necessarily imply that failover is always transparent. In other words, when one of the components within the application fails, the subsequent requests get routed to other available servers, thereby making it highly available. However it is possible for users to lose their sessions. There may even be a loss of data during the failure and things of that nature. In these cases, even though the system is available for subsequent requests, none of the above scenarios truly represents a transparent failover within an enterprise application.

Fault Tolerance - Fault tolerance is the system's ability to keep the system available and maintain data consistency in case of failure in one or more of its software components.

Clustering - Perhaps the most common term used in conjunction with HA, clustering is essentially a service provided by application servers in which multiple servers run as a group. The clustering service is responsible for load balancing the user requests and also for rerouting the incoming traffic to available servers should one of the servers in the cluster become unavailable.

Recovery - The ability of the system to recover itself from a failure condition as well as to bring the state of the objects into their pre-failure condition.

Failure Points
In an enterprise application, there are several points of failure - both within each individual component and at integration touch points with other components and interfaces. As the number of interfaces increases, the failover and recovery procedures become increasingly complex due to interdependencies involved. Although each component within the application may have recovery procedures for itself, the problem arises when one component or a combination of components within the system fails simultaneously.

So, a first step in designing a highly available enterprise system is identifying all of the possible permutations and combinations of failure points within the system. The identification process should involve all of the components within the system - application, network, hardware, and database - each and every component involved. As one begins to create such a matrix, it becomes overly complicated as the number of components and products that are mixing increases. This article will serve to focus failover and recovery of components and applications within the WebLogic Platform.

WebLogic Platform
WebLogic Server - WebLogic Server provides a number of J2EE services that include Java Messaging Service (JMS), Transactions (JTS/JTA) and Security, Servlet Engine, EJB container, and so forth. When designing enterprise applications for high availability it is crucial that architects have a good understanding of how these services failover when one of the instances hosting them goes down. A thorough understanding of the failover and recovery procedures of these services is also critical in automating the recovery of a downed instance or a system.

Clustering Overview - Perhaps no discussion on WLS high availability is complete without touching on WebLogic Clustering. An application that is deployed homogenously in a cluster is generally highly available. When one of the server instances goes down, the request is routed to the other available server in the cluster. In fact, the concept of the cluster is not new to J2EE architects and WebLogic Server administrators. Readers of this article are encouraged to review the WebLogic Server clustering documentation (http://e-docs.bea.com/wls/docs81/cluster/index.html). Essentially, most of the services provided by WebLogic can be categorized as either clusterable (i.e., multiple instances of these run on different services on multiple servers), or nonclusterable (there may be multiple instances of these services configured, but only one is active at a given time within the cluster). More information on which services can be clustered is provided in WebLogic Server documentation. Table 1 lists the clustered and nonclustered services in WebLogic Platform 8.1.