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:
A typical example of a synchronous invocation may look as follows:
The disadvantages of this implementation are:
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.