JBoss AS ships with built-in clustering support, located in the "all" server configuration. To be part of a cluster, JBoss instance nodes have to be grouped together in partitions. The members of a cluster can be located either on the same machine or on different machines. What actually required is that they are assigned different IP address for each node.
In the following figure, you can see (on the left side) a cluster composed of two nodes running in the same partition (DefaultPartition), each one with its assigned IP address.
You can also have multiple cluster partitions running on the same network. In order to differentiate them, each cluster must have an individual name and multicast address/port. If you look at the right portion of the picture, we have a slightly more complex scenario with two partitions, namely Partition1 and Partition2, each one with two cluster members and a distinct multicast address.
Tip
Multicast is a protocol where data is transmitted simultaneously to a group of hosts that have joined the appropriate multicast group. You can think about multicast as radio or television streaming where only those tuned to a particular frequency receive the streaming.
However, JBoss cluster does not deal with such low-level schemas directly; rather the communication between cluster nodes is handled by a library called JGroups that is a toolkit for reliable multicast communication. The basic building block of JGroups is the Channel, which is quite similar to a standard socket. Essentially Channels are the means by which applications connect to a cluster and send messages to each other.
At server startup, the JGroups library launches a set of Channels that have the ability to discover each other dynamically through the exchange of multicast packets. Nodes that join the cluster at a later time have their state automatically initialized and synchronized by the rest of the group.
All messages sent and received over the Channel have to pass through the protocol stack, which is the second main element of the JGroups framework.
The protocol stack is made up of a list of protocol layers in a bi-directional list. Outgoing requests go down the JGroups stack, and incoming requests climb up in the stack. For example, you might have in your protocol stack a fragmentation layer that might break up a message into several smaller messages, adding a header with an ID to each fragment, and re-assembling the fragments on the receiver's side.
Knowledge of the protocol stack is not required anyway, unless you need to tweak the default values and configure you own protocol stack.
In the previous section, we have introduced some basic administrative concepts about JBoss AS clustering; as a developer, you are probably more interested to know the interaction between your client and the clustered application.
Basically, JBoss AS cluster solutions fall between two kinds of architectures—Smart Proxy Architecture and External Load Balancer. To summarize the boundary between the two architectures, we can state that the external load balancer is used by clustered web applications, while smart proxies are used for all other clusterable components.
When using JBoss AS services such as JNDI, EJB, RMI, and JBoss remoting, the communication between the client and the server component is not a peer-to-peer communication. For example, when a client invokes an EJB, an object named smart proxy is looked up and downloaded locally. In a single node environment, the smart proxy must only pursue the job of routing the call from the client to the server, taking care of marshalling parameters and unmarshalling the return value of the EJB.
In a clustered environment, the smart proxy object includes an interceptor that understands how to route calls to multiple nodes in the cluster. The smart proxy is constantly aware of the clustering topology—for example, if one node of the cluster fails, the proxy stub is updated to reflect the latest changes in the cluster.
The following screenshot depicts (left side) how dynamic proxies enable switching from one node to another in case of failure.
The HTTP service does not require downloading any component to run in a cluster. As a matter of fact, clustering the HTTP application needs configuring an external component that contains the logic to route the requests to the nodes hosting the web application. This component can either be hardware or software; however, they perform conceptually the same function—spreading the requests across the nodes, taking care of cluster configuration as well as failover policies. The section Clustering web applications contains the necessary information for setting up a software load balancer, namely Apache Tomcat Connection (mod_jk).