Across the BEA product family, the principle mechanism for meeting the twin requirements of scalability and availability for business-critical applications is clustering WebLogic application servers. So clustering WebLogic application servers plays a foundational role across all BEA products and provides the underpinnings for the AquaLogic Service Bus that provides a services infrastructure for Service Oriented Architecture (SOA).

WebLogic clustering does a competent job of meeting the principal twin goals of scalability and availability, but injects some new problems into the mix, which have negative implications for the business objectives that demanded clustering in the first place. In other words, WebLogic clustering keeps the lights on, but introduces cost inefficiencies in managing the services infrastructure, especially in the context of SOA. So, how does basic clustering work? What are its benefits? How does it introduce inefficiencies, specifically in the context of SOA? How are these WebLogic clustering inefficiencies overcome through virtualization? These questions are addressed in this article.

Let's start with a quick overview of basic WebLogic clustering - touching on the key features and benefits - followed by a discussion about how basic WebLogic clustering introduces cost inefficiencies into the mix, and how these inefficiencies are exacerbated by SOA. Finally, we'll introduce the key features and benefits of virtualized WebLogic clustering, and offer some conclusions related to virtualized WebLogic clustering.

Basic WebLogic Clustering
Basic WebLogic clustering is comprised of identically configured managed WebLogic server instances that can be managed as a unit from an administration server. All the managed servers, in a cluster, belong to the same WebLogic domain, whereby each domain defines a set of interrelated resources. Each domain can, of course, define multiple clusters. A cluster, however, can only be associated with a single domain and a single administration server.

Key Features
Basic WebLogic clustering offers following key features:

• The core capability of clustering is the replication of critical application components and their state across clustered managed servers, thereby creating the possibility for auto-matic application failover from one managed server instance to another.
• This replication capability is bolstered through two related capabilities:
  - Replication of the Java Naming Directory Interface (JNDI) tree that contains references to these objects. Remote clients use the JNDI tree to discover these objects.
  - Clients that need to interact with these replicated objects use replica-aware stubs that are aware of all the replicas in the cluster.
  
• The ability to migrate a complete managed server automatically to another machine selected from a predefined set of available machines is important for migrating singleton services that can't be replicated.
• WebLogic clustering provides plug-ins for Web servers, which add load-balancing capability for balancing HTTP requests across managed server instances. These Web server plug-ins support HTTP session replication and can automatically detect changes in clusters' managed server set.
• Basic WebLogic clustering uses multicast and socket-to-socket network communications to implement the features discussed above.

Key Benefits
As we alluded to at the outset, basic WebLogic clustering offers two key benefits:

• The first benefit is scalability. The overall capacity of a cluster to meet demand can be increased by adding more managed server instances to it. However, in basic WebLogic clustering, the process of adding new managed server instances to a cluster in response to increased demand is largely manual in nature.
• The second benefit is increased availability. The application failover capability based on the replication of state and critical application components across clusters' managed server set and the ability to migrate complete managed server instances automatically to a different machine offer higher availability for applications deployed on a WebLogic cluster.

These capabilities and benefits are impressive and work fairly well in practice. But, didn't we say something about cost inefficiencies?

Cost Inefficiencies
Basic WebLogic clustering offers some solid benefits, but introduces the following cost inefficiencies:

• Each application deployed to a cluster needs to be sized for the cluster. This involves estimating peak demand for the application and provisioning enough managed server instances in the cluster so peak demand can be met. This process is repeated for each application. Provisioning for peak demand creates large pockets of underutilized hardware infrastructure capacity. This underutilized capacity creates cost inefficiencies, because each hardware resource has capital, operational, and administrative costs.
• The second issue is that each managed server instance needs to be provisioned with WebLogic software and administered to be brought online as part of a WebLogic cluster. This basically creates inflexible cluster silos that consume significant administrative costs and are largely inflexible in terms of their configurability into different application clusters.

This brings us to the issue of how cost inefficiencies get exacerbated in the context of SOA.

Exacerbation of Cost Inefficiencies Under SOA
SOA is about creating standards-based, interoperable, reusable services that can be loosely coupled to orchestrate complex business processes. In the BEA product family, the AquaLogic Service Bus provides a reliable hub-and-spoke integration system so that arbitrary services can be loosely coupled though two key mechanisms - proxy services and configurable message flows.

Naturally, AquaLogic promotes service reuse, but its execution environment is based on basic WebLogic clustering. This means that the cost inefficiencies introduced earlier are exacerbated in the context of AquaLogic, because the more you adopt SOA in your organization, the harder it is to predict the demand profile on a specific service. This is because a given service can be configured into arbitrary business processes. What all this means is that the problem of overprovisioning is exacerbated in the context of AquaLogic. In fact, perhaps anticipating this, AquaLogic provides a dashboard that provides alerts related to the service levels configured in AquaLogic. However somebody has to react to these alerts manually, which brings us to the topic of virtualized Weblogic clustering and how it helps overcome cost inefficiencies.

Virtualized WebLogic Clustering
Virtualized WebLogic clustering, as the name implies, virtualizes the cluster's managed server set, both in terms of size and membership. The members of this set are the machines on which the managed server instances are run.

Key Features
The key features of virtualized WebLogic clustering are as follows:

• Virtualized WebLogic clustering adds a control plane on top of basic WebLogic clustering. This control plane is managed by a centralized broker and consists of distributed agents installed on a predefined set of machines.
• The predefined set of machines, with distributed agents, becomes the universe from which the managed server set for a given cluster is mapped at any given time. Each machine with a distributed agent is capable of running one or more instances of a managed server.
• A virtualized WebLogic cluster's managed server set is automatically expanded or contracted based on configurable policies, which dictate how the cluster should adapt and respond to its managed server set in response to varying demand.
• The broker, through its distributed agents, effects changes in the managed server set.
• Varying demand is characterized in terms of configurable JMX-based statistics, such as WebLogic Throughput, WebLogic Queue Size, and Active Thread User Count, among others, that are supported by WebLogic application servers and are constantly probed and measured at each managed server instance by the distributed agent and aggregated at the centralized broker.
• HTTP clients access the cluster in the same way they would in a basic clustering scenario. The virtualized WebLogic clustering doesn't introduce any new issues in terms of the load balancing of HTTP requests.
• For non-HTTP clients, such as EJB clients, it's imperative that the clients can create an initial JNDI context based on a JNDI Provider URL. The broker provides a Web Service that helps in the discovery of the virtualized managed server set and thus the construction of the JNDI Provider URL for creating an initial JNDI context.
• The broker is responsible for provisioning all required software to the distributed agents, including WebLogic application server software components and Java software development toolkit software.

The basic architecture for virtualized WebLogic clustering is summarized in Figure 1.

Key Benefits
The key benefits of virtualized WebLogic clustering are as follows:

• Virtualized WebLogic clustering can dynamically change the managed server set in response to configurable policies - clusters don't need to be provisioned for peak demand, which addresses the concerns of cost inefficiencies.
• The general benefits of virtualization are now well understood. It improves infrastructure utilization at all levels of the IT stack. From the adoption of virtualization at the operating system level to the application server level, virtualization can provide direct benefits holistically or independently.
• Through a centralized dashboard, software is automatically monitored, controlled, and provisioned to agents making cluster management and administration simpler and more cost-effective.

Conclusion
Basic WebLogic clustering is critical for scalability and availability and required for business critical applications. However, basic clustering requires provisioning the cluster for peak demand, which leads to a number of cost inefficiencies that have a multiplicative effect across the application set and can quickly add up, consuming significant chunks of any IT budget. The virtualization of WebLogic clusters presents enterprises with an opportunity to help overcome cost inefficiencies by developing an environment that can dynamically adapt a cluster to its demand profile per predefined configured policies.