Friday, January 30, 2009

Web Service Orchestration without BPEL

In my project there is a requirement to call few web services in sequence and aggregate the responses and expose the functionality as a web service. There are quite many services with this required behavior. The initial solution was to use some BPEL engine, but the decision was put on hold due to various reasons and we were encouraged to whip up a light weight framework in java that suits our needs. This was indeed interesting and I was successful in designing and developing a embeddable and light weight orchestration framework in java. Following are some thoughts on the same -

Since, the framework is more or less chaining of web service calls, I decided to keep the flow of messages as XML inside the orchestration framework. Modeled the Orchestration as an XML pipeline. Chaining of web service calls needed transformation of response to that of the request of the next service and XSL has been choosen to transform the message formats. Quickly whipped up an XSLUtil based on Trax (Transformation API for XML). The next challenge was to invoke the webservices using XML data as request. I decided to go the XML way to avoid marshalling/unmarshalling of POJOs from/to XML. JAX-WS came handy here. JAX-WS comes with a nice feature called Dispatch that would allow invocation of web services using either a SOAP message or XML payload, the latter met my need. It didnt take much time to play with the Dispatch interface and to implement a generic utility. I had the core componenets ready in a very short span of time.

The next step was to abstract the execution of these utilities, so defined the classes called *Action for transformation and invocation and made them configurable using a XML file and my little orchestration framework is ready. It also has a feature that reports the invocation trace along with the profiling information. However, this is just the beginning. There was an immediate need to add the branching, looping, assignment actions. Used JEXL for expression evaluation of branching and looping functions. And now, am thinking of adding some kind of a transition governance between the stages (using AspectJ) and add some kind of a compensation handlers to each stage. I'm also playing around with XTS of JBossTM to see if I can provide transaction recovery and make the web services transaction aware.

If you have any suggestions and ideas to improve the framework, write a comment.

4 comments:

Anonymous said...

Ravi, I am not sure if it's correctly explained in the blog. Is this a point to point WS communication? Looks like xml messagaes are created and dispatched from WS to another WS. not exactly a 'bus' oriented communication. How do you make the system aware of participating web-services meaning what is the discovery mechanism? and by transaction recovery part is it ok to assume that you are considering recovery of the communication failure ( payload recovery) ?

ravisk said...

Supradeep -
1. It is more of a web service orchestration - calling a number of web services in a particular sequence where the data from one servcie is required in the request of the subsequent one. You can say it is a kind of content based routing with message enrichment.
2. What exactly you mean by 'bus' oriented communication. The same orchestration can be done using ALSB/OSB.
3. There is no runtime discovery mechanism, it is compile time. The services are identifed to prior to orchestration of the service assembly.
4. Recovery is not in the context of communication failure. It is with regards to transaction.

Thanks for the comments, will discuss more in a mail.

Prasanna said...

Hi Ravi,Looks interesting. I am also looking for something similar. have you developed any designer for orchestrating the web services as part of this project ?. you can reply back to me at clhprasanna@gmail.com

ravisk said...

@Prasanna -
This is a quick whip of a framework to orchestrate the services in my project, so did not build any designer. The configuration was built to be fairly intuitive and simple that did not necessitate the a designer. Btw, we have adopted BPEL and am planning to write few entries on my experience with BPEL. Watch the space ;)

Cheers,
Ravi