I was recently asked to consider a scenario where a document is received by the ESB and must then be processed by a number of web services in turn. Naturally, the first reaction is to use WS-BPEL to orchestrate the calls to each of the web services. However, I did want to also consider what the alternatives would be.
I like the concept that the document travels from one service to another. Each service passes it on to the next service, perhaps with some modification. Instead of services that consume request messages, we have a document travelling through the ESB, eventually reaching its final destination.
The first step was to create some Web services with the appropriate interfaces. They need to take the document as input and return it again as output. I used document/literal style WSDL, so the request and response messages are the same format. For the final destination I have a service that accepts the document and doesn’t generate a response.
Now all that is required is a means to route the messages between the services. WS-Addressing provides the answer here. The wsa:ReplyTo header allows me to specify that the first service should send its reply to the second service. Remember, I’ve designed the WSDL so that response messages are the same format as request messages, so the second service is happy to process the message.
Routing the response from the second service on to the third one relies on the use of wsa:ReferenceProperties. WS-Addressing specifies that the contents of the ReferenceProperties in a End Point Reference will be copied into the SOAP headers of the message. Creating a nested series of wsa:ReplyTo headers within the ReferenceProperties of the original request message means that each service will route the document to the next service in the chain. Click on the image to the right to see the full request message.
This use case might stretch the original intention of WS-Addressing a little. However, it does achieve the desired message routing capability using nothing more than the existing WS-Addressing processing rules. Here’s a zip containing a set of projects that you can deploy into the Cape Clear 7 beta so you can try it for yourself. You'll find a copy of the sample request message in the TaskOne project. Just send it to the TaskOne service using the Web Service Tester.
Design Pattern or Dirty Hack? You decide.
2 comments:
The age old dichotomy of good and evil comes to mind. Is this the dichotomy of orchestration and choreography? But which is the evil and which is the good?? :-)
Interesting idea - source routing. Your example is quite restrictive using the same document for all exchanges. Of course, as long as the output document of one service matches the input of another, the document type can change along the way (having intermediate services which just do message format translations would be an option to allow more flexibility in the routing).
Although probably not something reference properties were designed for, it is quite a novel use of them. It also begs the question of what, if any, issues this raises about security. If someone can route an approapriate document through multiple servers so easily it could lead to messages being allowed to pass from public to private servers and potentially exposing sensitive services.
Post a Comment