Deployment

Some organizations require 24/7 availability. A good part of this is the ability to deploy new applications and new versions, and to apply patches, without bringing down the application server for maintenance. Most application servers have the concept of hot-deployment at runtime for EJBs. JBoss 3.0 takes this concept to a much higher level.

With its JMX-based Microkernel architecture, JBoss 3.0 has the innate ability to hot-deploy, undeploy, and redeploy any type of component at runtime simply by copying the component to a deploy directory. This includes EJBs, EARs, WARs, JAR libraries, data sources, database pools, and new JMS topics or queues; basically anything. In fact, you could cycle an entire new version of the whole application server and all of its applications at runtime if you really wanted to.

JBoss farming takes this hot-deployment feature cluster-wide. Copying a deployable component to just one node's deployment directory causes it to be deployed (or re-deployed) across the entire cluster. Removing a component from just one node's deployment directory causes it to be undeployed across the entire cluster. This is a great way to easily patch your entire cluster with a new version.

Architectural Overview

This section provides a brief architectural overview on clustering in JBoss 3.0.

Proxies

JBoss clustering leverages smart proxies to implement load-balancing and fail-over for EJB remote clients. These proxies manage a list of available RMI connections to the EJB containers that implement the proxy's EJB within the cluster. Depending on the configured load-balance policy, the proxy picks what RMI connection it will use to service an invocation. The proxy will also fail over to one of these standby RMI connections on a communication failure. If the JBoss cluster detects an addition to itself, or a node failure, the list of available RMI connections for an EJB is updated. This list is piggybacked onto the invocation response to the client if a membership change has occurred.

Layered Architecture

JBoss clustering has a layered architecture. The lowest layer of the architecture is a communication layer that provides group membership and communication protocols. An abstraction framework has been written on top of the layer to facilitate a plug-in architecture for other possible third-party distribution methods. Two clustering services, the Replicant Manager and Distributed State Service, use the abstraction framework to implement some basic functionality that is core to EJB proxies, clusterable RMI servers, JNDI and state replication.

JavaGroups

JavaGroups is currently the communication layer for JBoss clustering. JavaGroups is a toolkit for reliable group communication and management. It provides some of these core feature that were invaluable in making clustering work:

Group membership protocols. Notification when a member of a cluster joins or leaves a group.

Lossless transmission of messages through multicast.

Guaranteed message ordering.

Lightweight group RPC mechanism.

Clustering Framework

JBoss uses an abstraction framework to isolate communication layers like JavaGroups. This was done so that other third-party group communication frameworks could be incorporated into JBoss seamlessly and easily. This framework also provides the tools and interfaces for you to write your own clusterable services and components to plug into the JBoss JMX backbone.

Clustering Services

Two services use the Clustering Framework to implement some core functionality that is used by other clusterable components (EJB, JNDI, RMI, etc.). The first is the Distributed State Service. This service manages data that is uniform across the cluster. An example is the replicated state of a Stateful Session Bean. Another service is the Replicant Manager. The Replicant Manager's job is to manage data that is possibly different across the cluster. An example is the list of RMI connections used by clustered EJB smart proxies.

Along with the abstraction framework, you can use these services to build more advanced clusterable components that fit your needs. Any type of serializable object can be registered to be replicated by these services. Custom management objects can also listen for change events for each of these individual replicated objects. This gives you very granular control of the state replicated in your cluster.

JMX Bus

Finally, all of these components are configurable and accessible through JMX.

Getting Started

Now that you've read about some of the nice clustering features of JBoss 3.0, let's take a look at how easy it is to use them.

Using Clustered EJBs

Since nodes in a JBoss cluster automatically discover the existence of one another, it is very easy to set up your EJBs to be cluster-enabled. Simply setting a clustering flag in the JBoss-specific bean deployment descriptor, jboss.xml, is enough to enable load-balancing, fail-over, and state replication for your beans.

After deploying farm-service.xml, you are ready to rumble. With the above configuration, just copy your farmed components into the $JBOSS_HOME/server/all/farm directory, and they will be hot-deployed across the cluster.

Starting JBoss

JBoss 3.0 comes with three different ready-to-use server configurations: minimal, default, and all. Clustering is only enabled in the all configuration. To run this configuration, you must execute JBoss as follows:

$ run.sh ñc all

Conclusion

JBoss clustering is designed to be simple to configure and simple to extend. It is one of the final pieces of the puzzle that makes JBoss a viable open source competitor to other enterprise J2EE offerings.

For more information on advanced JBoss clustering configurations and design, we offer for-pay documentation at the JBoss Web site.

Bill Burke, Sacha Labourey
is a Fellow at the JBoss division of REd Hat Inc. A long time JBoss contributor and architect, his current project is RESTEasy, RESTful Web Services for Java.