Clustering Architecture

There are two fundamental building blocks to the clustering support in SwitchYard:

• Shared Runtime Registry - a shared, distributed runtime registry which allows individual instances to publish and query service endpoint details.

• Remote Communication Channels - an internal communication protocol used to allow a service client to invoke a service hosted in a remote instance.

The runtime registry is backed by a replicated Infinispan cache.  Each instance in a cluster points to the same replicated cache.  When a node joins a cluster, it immediately has access to all remote service endpoints published in the registry.  If a node leaves the cluster due to failure or shutdown, all service endpoint registrations are immediately removed for that node.  The registry is not persisted, so manually clean-up and maintenance is not required.  Note that the shared registry is a runtime registry and not a publication registry, which means the registry's lifecycle and state is tied to the current state of deployed services within a cluster.  This is in contrast to a publication registry (e.g. UDDI), where published endpoints are independent from the runtime state of the ESB.

The communications channel is a private intra-cluster protocol used by instances to invoke a remote service.  The channel is currently based on HTTP, but this may change in the future and should be considered a transparent detail of the clustering support in SwitchYard.

Configuring Clustering

Clustering support is light on configuration and should work out of the box.  The only real requirements are using a shared Infinispan cache for the runtime registry and indicating which services are clustered in your application config (switchyard.xml).  By default, SwitchYard uses the default cache in the "cluster" cache container which comes pre-defined in your standalone-ha.xml.  Unless you have specific requirements to use a different cache or separate cache configuration, just stick with the default.

Applications take advantage of clustering by explicitly identifying which services should be clustered in the application's descriptor (switchyard.xml).  You can control which services in your application will be published in the cluster's runtime registry and which references can be resolved by clustered services.  To enable a service to be published in the cluster's runtime registry, promote the service in your application and add a <binding.remote> binding to it.

<sca:service name="Goodbye" promote="GoodbyeBean/Goodbye">   
   <sca:interface.java interface="com.example.Goodbye"/>
   <remote:binding.remote/>
</sca:service>

Consuming services in a cluster follows the same configuration approach, but applies to references in your application.  To invoke a service in a cluster, promote the reference and add a remote binding.

<sca:reference name="Goodbye" multiplicity="0..1" promote="GreetingBean/Goodbye">
   <sca:interface.java interface="com.example.Goodbye"/>
   <remote:binding.remote/>
</sca:reference>

If you are using the Eclipse tooling, promoted services and references can be made cluster-eligible by clicking on the "Enable remote channel" checkbox during promotion or via an existing composite service or reference property sheet.

Using Clustering

To create a cluster of SwitchYard instances, start two or more AS 7 instances with a shared Infinispan cache.  Out-of-the-box configuration in standalone-ha.xml should be sufficient:

# start instance 1
node1> bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
# start instance 2
node2> bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=1000

Once the instances are up, you can deploy applications independently to each instance.  A homogeneous cluster would have identical applications deployed on each node.  A heterogeneous cluster will have different applications and services deployed on each instance.  For testing purposes, it's easiest to deploy a consumer application to one instance and a provider application to another.  A quickstart is coming soon, but for now you can follow the instructions in this forum thread.

Considerations and Gotchas

As an experimental feature, there are a few considerations and gotchas in 0.6:

• Clustered applications which share services must have the same targetNamespace.  You can edit this on the application property sheet in Eclipse.  This issue surfaces when you have an application (app1) which invokes a clustered service provided by another application (app2) - app1 and app2 must have the same targetNamespace.  

• Clustering currently works with standalone mode in AS 7 only.  Support for domain mode is coming soon.