Kishanthan and I chatted over the possible designs of the Clustering SPI implementations and how to make it easy to plug in new clustering implementations using the provided SPI.
Carbon clustering module allows its consumers (Component developers) to work with a cluster of products. I.e sending messages to cluster, to get notified about new member additions or removals etc. Clustering module uses a cluster communication engine underneath to support all these features. By default it uses Hazelcast [1], but we have designed this module such that any cluster communication engine can be plugged in. According to the existing design, whenever you are plugging in a new cluster communication engine you have to read the cluster.xml and initialize the ClusterConfiguration and register yourself as a ClusteringAgent. This means that every implementation has to write boiler-plate code perform above actions and alsoCarbon Clustering module has no control over selecting and initializing the correct implementation. To overcome this problem we change existing design. Now Carbon clustering module is responsible for discovering the correct implementation. Clustering implementations just need to register themselves as OSGi services. During the server startup, Carbon clustering engine will populate the ClusterConfiguration and the ClusterContext and initialize the correct clustering implementation by passing the ClusterContext. *ClusterConfiguration* - Holds all the static properties defined in the cluster.xml *ClusterContext* - Holds all the dynamic information such as members in the cluster, membership listeners implementations etc. ClusterContext has a reference to the ClusterConfiguration as well. Thanks, Sameera. [1] http://www.hazelcast.org On Sun, Jan 19, 2014 at 11:40 AM, Kishanthan Thangarajah < [email protected]> wrote: > Clustering SPI provides the ability to plug-in different clustering > implementation to carbon. By default, carbon will ship hazel-cast based > clustering impl. There will be a separate file (cluster.xml) for cluster > configuration. > > The SPI will contain the following main interfaces. > > *ClusteringAgent* - is responsible for initializing and managing this > node in the cluster. > *MembershipScheme* - a representation of a membership scheme such as > "multicast" or "well-known address (wka) used in the cluster. > > A high-level view can be as follows > > [image: Inline image 1] > > When the cluster agent is successfully initialized, it will also register > the Cluster Service (being discussed at "[C5] Clustering API"). The > Cluster Service will use the clustering agent underneath at implementation > level for its required operations. Based on previous experiences, we have > defined the following methods for clustering agent and membership scheme > for now. Based on the final outcome of this discussion, they may get > changed. > > *ClusteringAgent* > > /** > * Initialize the agent which will initialize this node, and join the > cluster > */ > void *init*() throws ClusteringFault; > > /** > * Shutdown the agent which will remove this node from cluster > */ > void *shutdown*() throws ClusteringFault; > > /** > * Set carbon configuration context to this agent to be used in the > clustering impl > */ > void *setConfigurationContext*(CarbonConfigurationContext > configurationContext); > > /** > * Get the list of static members > */ > List<ClusterMember> *getStaticMembers*(); > > /** > * Get the number of members alive. > */ > int *getAliveMemberCount*(); > > /** > * Send a message to all members in the cluster > */ > List<ClusteringCommand> *sendMessage*(ClusterMessage msg, boolean > isSync) > throws ClusteringFault; > > /** > * Send a message to a set of specific members in the cluster > */ > List<ClusteringCommand> *sendMessage*(ClusterMessage msg, > List<ClusterMember> members, boolean isSync) > throws ClusteringFault; > > > *MembershipScheme* > > void *init*() throws ClusteringFault; > > void *joinGroup*() throws ClusteringFault; > > > Thoughts? > > Thanks, > Kishanthan. > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > -- Sameera Jayasoma, Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
<<C5 - Clustering.png>>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
