Axis2 Clustering Support

Axis2 1.3 release has experimental clustering support enabling you to deploy your services in a cluster for Scalability, Failover support and HA. In simple terms, we provide replication for Service Context, Service Group Context and ConfigurationContext. This enables you to deploy your services in a cluster and share state. Please give it a spin and provide feedback via the mailing lists.
Please check the Axis2 Clustering Guide for a good introduction.



In Summary, here are a few points worth remembering

• For Stateful Web Services it is recommended to deploy in pairs using the primary/secondary model. i.e Each Node will replicate to one or more backups (secondary nodes) for failover.
  
• There will be only one active node at any given time. This is to avoid conflicts as we don't have a distributed locking mechanism.
  
• To achieve Scalability, you need to deploy several of these pairs. In other words your cluster will consist of multiple pairs with one active node in each - and your pairs are isolated sub groups with no replication between them.
  
• If your cluster consists of more than one pair, you need to use some sort of partitioning to avoid a user being serviced by more than one pair within a given session in order to avoid potential conflicts. You could use session affinity to achieve this.
  
• There is no such restriction for Stateless Web Services.
  
• If your Services read shared state more frequently and update very rarely, you could experiment with more than one active node. However conflicts are still possible.
  

Sanjiva asked me to help over a year ago and it got postponed month after month due to other commitments until I was finally able to produce a prototype. Many thanks to Afkam Azeez, Chamikara, Snajay and Sanjiva for the support they provided. Azeez and Chamikara was primarily responsible for bringing the clustering support to it's current state after I contributed an initial implementation. If not for those two it would have been next to impossible to get it included in the release. Special thanks to Philip Hanik for answering questions on Apache Tribes even while on vacation.

SCA vs Spring (A reply to Dan's post)

In Dans blog entry, he compares SCA vs Spring with an excellent example which highlights the similarities.

I do not view them as competing technologies rather complementing as I see some synergy between these technologies.

Clearly SCA and Spring share several design principles and it is no surprise that the SCA spec group views Spring as an implementation technology for components and composites. In fact the SCA spec group has gone as far as formalizing this approach with SCA Spring Component Implementation Specification

So Ke Jin's comment on InfoQ was right on the money when he said,

"As the matter of fact, the so-called SCA assembly model is merely a DSL (domain specific language) that can easily be realized on top of Spring or any decent POJO IoC containers, with few hundreds lines of code and half day of work"

On his InfoQ comment, Dan asks?

But why wouldn't I just use Spring to begin with?

The simple answer is that SCA could become a standard and the ability to deploy my composites in any SCA runtime. The other SCA runtime could be using Spring or the next great thing under the covers.

Mike Edwards points out on the same InfoQ thread

What the SCA Assembly model then brings to the party is a organized and standard way of describing how the different components in your (distributed) system are linked together to build a particular application.

This will only add value if and when SCA becomes a standard through OASIS and is adopted across different languages by the masses. Spring is great and I really like it. However distributed systems are not built only using java. It would be nice if we have a standard way of expressing how different components are linked together to build your application.

Also unlike the EJB's if SCA composites can be truly portable across different runtimes (Ex Tuscany java runtime to ABC java runtime) with zero code changes it can be a very good selling point. Vendors shouldn't spoil the party with vendor specific addons in their runtime which can lock-in unsuspecting users.

Dan asked

Someone show me where Ke Jin is wrong and where SCA expands on Spring capabilties.

Technically the capabilities are more or less the same, albeit spring being a more simple model. The standardization and portability of SCA (if achieved) is where it can exapnd or add value on top of Spring. I am not advocating to replace Spring with SCA. You can continue to use Spring to realize SCA. They are certainly complementary. This white paper explains how SCA can be used with OSGi and Spring.

P.S I conveniently ignored the complexity issue. IMHO it is a red herring.
Distributed systems are complex in nature. Thinking we can provide simple solutions is the biggest misconception.
EJB, WS-*, REST, SCA they all prove this one after the other. That's a good topic for my next blog entry :)