[axis2] Clustering impl using tribes

[Rajith Attapattu]

Hi All,

I have built a clustering prototype for axis2 using tribes. However here are my observations which really concerns me.
I slighlty modified the interface proposed by chamikara (modifications are just addition of parameters to the methods) to get this working.

The interface is actually a very good abstraction, how ever the existing axis2 architecture falls short of expectation in making it a good fit.
Ideas are welcome to improve on this (given that the axis2 architecture is static)
I have broken them down to practical issues and architectural issues.

Architectural concerns which reduce the usability of the proposed Interface
--------------------------------------------------------------------------------------------------------------
A) The Context heirachy has no common interface, therefore we cannot treat both ServiceContext and ServiceGroupContext as the same due to the following reasons
     1.) There is no context id associated with ServiceContext, therefore just having the context id as a parameter is not good enough

     2.)  We cannot use the ReplicatedHashMap provided by Tribes without introducing a dependency to kernal module on Tribes.
           If we had an interface we could have created a ReplicatedServiceContext and ReplicatedServiceGroupContext implementing the interface.

B) Even if we had an interface, the creation of Contexts are done all over the place, instead through a Factory class, therefore limiting the possibility of supplying a Replicated context without introducing a hard dependency on tribes to kernal module.

We have 2 possible solutions to avoid a dependency.
1.) Delegate the setProperty(k,v) & setProperties(map) method to the impl via the interface and then use low level tribes API to do the replication.
     This is a pain in the ass as we have to manage synchronization manually across the cluster. Reinventing wheel...not in a mood to do so :)

2.) Manage a set of Maps at the implementation level which are wrapped with ReplicatedMap, and then we only need to sync with the maps in the context.
    This is ugly, but it works with minimal effort.
    
 
Practical issues
-----------------------
1.) The context id for service groups are not set at creation time, so we cannot replicate the creation of a service group context until a context id is set.

2.) A Service context cannot exist without a Service Group context, however before we have a id for service group context a service context is created for the service.
     So we have to hold on to the service context, until we have a id for service group context, then replicated the group ctx and then the service ctx.

Any solutions to this problem?

Regards,

Rajith