One of the major advantages of an ESB is the ability to define composite services, in other words taking existing services and combining them to create new services which can take advantage of existing functionality. This is possible because of the loose coupling and reusability encouraged in an SOA environment.
Service Chaining is a topology whereby a service can be implemented through the execution of two or more service implementations, in sequence, with each service within the composite, providing specific, reusable functionality.
Each service in the chain, with the possible exception of the last in the sequence, will be declared with a service mep attribute value of OneWay. This will tell the framework that these service implementations will not provide a direct response to the service consumer, but rather this should be handled by the last service in the chain.
An example configuration for these services could be as follows:
<service category="composite" name="ChainedService"description="Chained Service Service A">
...
<actions mep="OneWay">
...
<action name="routeToNext"class="org.jboss.soa.esb.actions.StaticRouter">
<property name="destinations">
<route-to service-category="composite"service-name="ChainedServiceB"/>
</property>
</action>
</actions>
</service>
<service category="composite" name="ChainedServiceB"description="Chained Service Service B">
...
<actions mep="OneWay">
...
<action name="routeToNext"class="org.jboss.soa.esb.actions.StaticRouter">
<property name="destinations">
<route-to service-category="composite"service-name="ChainedServiceC"/>
</property>
</action>
</actions>
</service>
<service category="composite" name="ChainedServiceC"description="Chained Service Service C">
...
<actions mep="RequestResponse">
...
</actions>
</service>The example uses a StaticRouter action to forward the message from one service within the chain to the next service in the sequence. The application may choose to route the message using other actions, for example ContentBasedRouter, in order to support topology defining multiple chains which react to the contents of the message.
Based on what you learned in this section, add more services to our Chapter3 application. Experiment with some more additional action classes. Try using ServiceInvoker in your custom action instead of StaticRouter.
Service Continuations is a topology whereby a service implementation can be split into multiple parts in order to allow the synchronous invocations of services to occur in an asynchronous manner. The main benefits of executing a synchronous invocation in this manner are:
- Increased performance: Service consumers are no longer waiting to receive a response from the service provider, allowing the consuming pipeline to process the next message in its queue.
- Increased reliability: Each part can be encompassed in a transactional unit of work, allowing the processing of the service to move from one consistent state to the next.
A typical example of a synchronous invocation may look as follows:
The disadvantages of this implementation are:
- The processing of Service A will be blocked while it awaits the response from Service B, preventing any resources it may hold from being reused.
- The processing of Service A cannot occur within a transactional context as the delivery of the request message to Service B will not occur until the transaction commits.
The processing involved in Service A can be split into two services, the first containing the functionality being executed up until the point where the synchronous invocation of Service B would be made, the second service (the continuation) containing the functionality which would be executed after the response is received.
Service A would now send an asynchronous request to Service B, specifying the Continuation service as the ReplyTo endpoint within the request header. This will allow the execution of Service A to be encompassed by a transactional context, providing atomic and consistent execution, and will then allow it to release any resources being held in order to process any subsequent requests in its queue.
Service B would process the request as before, completely oblivious to the changes that have been made within Service A. Once complete, the pipeline for Service B would send the response to the continuation service, which can then resume processing of the original request within a second transactional context.