8.8. How Service Replication Works

What happens if you take a service like the helloworld.esb and deploy it to Node2 as well as on Node1? Assume you are using jUDDI for your registry and that you have configured all our nodes to access one central jUDDI database. Node2 will find that the FirstServiceESB - SimpleListener Service is already registered. Therefore, it will add a second ServiceBinding to this service so there are now two ServiceBindings for this service. Hence, if Node1 goes down, Node2 will keep on working.

Note that you will have load balancing as both service instances will be listening to the same queue.

This type of replication can be used to increase the availability of a service or to provide load balancing. Consider an application service comprised of four individual services, each of which provides the same capabilities and conforms to the same service contract. They differ only in that they do not need to share the same transport protocol. However, as far as the users of application service are concerned they see only a single service, which is identified by the service name and category. The ServiceInvoker hides the fact that the application service is actually composed of four other services from the clients. It masks failures of the individual services and will allow clients to make forward progress as long as at least one instance of the replicated service group remains available.

Replication of services may be defined by service providers outside of the control of service consumers. As such, there may be times when the sender of a message does not want to silently fail-over to using an alternative service if one is mentioned within the Registry. If you set the org.jboss.soa.esb.exceptionOnDeliverFailure message property to true then no retry attempt will be made by the ServiceInvoker and the MessageDeliverException will be thrown. If you want to specify this approach for all messages then define the same property in the Core section of the JBossESB property file.