I have blogged previously on the new JBoss Clustering roadmap and how it has been re-architected. To give more details, JBoss Clustering mainly consists of 3 main parts:

•  

  EJB client-side cluster interceptor that has intelligence of cluster toplogy and load balance policy. One of the strength of JBoss cluster interceptor is its transparency to the client. That is, configuration is done on the server side and downloaded to the client at runtime. As a result, client is not even aware of it is using clustered service!

   

  For the existing EJB2.1, we have HA-RMI that runs top of the RMI layer. But for EJB3.0, Bill Burke has implemented HA-Remoting that runs on top of JBoss Remoting. It further provides flexibility on the selection of transport layer mechanism.

• State replication. Previoulsy we have different state replication mechansim to deal with http session and sfsb, for example. Now, we will use JBossCache for everything that is involved with state replication. Modules that currently have been/are transitioning to using JBossCache are:
  • Http session (including SSO). This has been introduced since AS 3.2.6 that is bundled with the Tomcat module.
  • EJB3.0 SFSB. This has been introduced in EJB3 Beta release.
  • EJB3.0 Entity. This has been introduced in EJB3 Beta release.
  • DistributedState. This is an internal component that is currently implemented by Scott Marlow (from Novell) in AS 5.0
  • HA-JNDI. This is the JBoss clustered jndi server (that can be released separately in the future.) It is currently implemented by Jerry Gauthier (from Novell) in AS 5.0
• Distributed RPC. There are times when a moudle needs to execute distributed RPC call. For example, in JBoss HA-JNDI, sometimes we will need to ask the other local jndi servers to see if they hold a specific EJBHome stub. Currently, HAPartition is the distributed RPC layer.

 

To sum up all these relationship, below is a figure illustrating the new layered component architecture of JBoss Clustering. You can see that the clustering stack from the bottom up that starts with JGroups, then with JBossCache and HAServices, and so on.

 

 

So what are the advantages of this layered approach, you ask? Well, for one, since stack modules can be independently released, it is much easier to maintain. For example, a bug fix in JBossCache only involves with a patch of jboss-cache.jar.

 

In the same token, when JBossCache implements buddy replication feature, that means JBoss Clustering will be able to support sub-paritioning of cluster group and thus promote large number scalability. In another example, Hany Mesha (also from Novell) has recently implemented the cache overflowing feature in the upcoming JBossCache 1.2.4 release. It will be used for http session and ejb clustering passivation/activation features next.

 

Finally, the figure below shows the mutual release dependency of JBoss Clustering components and their main features.

 

 

Here are highlights of some of the key features in different components:

• JGroups 2.3
  • Channel multiplexing. This enables different users of JGroups to share a single JChannel. As a result, it can simplify and consolidate all the JGroups configuration used by various components.
  • Partial state transfer. Needed to guarantee state integrity.
• JBossCache 1.2.5 & 1.3
  • Optimistic locking. Potentially can increase concurrency during short transaction span.
  • Buddy replication. Only replicated on a configurable sub-group.
• AS 4.04 & 5.0
  • HA-JNDI. Clustered jndi server using JBossCache.
  • Fine-grained replication for SFSB and http session.