Choreography and Orchestration

As I have been involved into such research area, I think it is time for me to share something relate to my area.

 

My Research area is web service oriented, mainly focus on service composition (such as currently well developed Orchestration, always done by BPEL) and the coordination of such two kinds of composition architectures. Let me start from the basic concept of Service composition- What is service composition.

 

SOA has been presented for a few years, and web services are highly concerned by a lot of companies.Most of them (as I know, youtube, flicker, yahoo, google, etc.) have provide their services as web services to the public, to ease programmers to use them. As services have been developed more and more complicated,  as well as the business goal is geting more and more difficult to obtain, a proper composition of exsiting web services is necessary. Therefore, basic composition comes out, which is currently called Orchestration. Orchestration involves a workflow, and a workflow engine to execute it. Each web service involved in works with one another, however, this communication is based on the workflow, or the coordinator. Every message income or outcome from a web service needs to be passed through the coordinator, so that the coordinator will pass this message to the next service. In this way of communication, each service has no idea of whom it communicate with and when it will be involved(invoked). finally plz let me draw a pic for  service Orchestration, service Orchestration is a kind of Service Composition that a central process (workflow or coordinator) controls everything, the involved web services are passive, unaware of any details of service coordination.

BTW, from netbeans 6.0(might be :(), Orchestration has been integrated with IDE. It works like magic!:)

 

Although service Orchestration works fine these years, a lot of researchers (u can get as many as u can from ieee) doubted that Orchestration may consume too much resources and require too much capability of data transferring through the network (many papers from ieee can prove this point). Therefore, a peer-to-peer service composition was proposed, which is named Choreography. Choreography is absolutely an opposite way to coordinate services together. No workflow involved in Choreography, and unlike Orchestration, every service in Choreography should be aware of, at least a part of the overall composition, so that once it receives messages, it knows what to do next (pass the message directly to others, or processes the message to get the new message and reply to the requester or etc.). Choreography, as I think, is a kind of MAS (multiagent system), agents in choreography, are web serivces. Hundreds of researches were done to prove that Choreography require less resources and network capacity, but few can claim that choreography engine has been implemented. Actually previously a W3C team has worked on choreography description language (WS-CDL) for year, but end up with a recommended candidates, not a real implementation. Drawbacks of WS-CDL are well presented in a paper "A critical overview of web service choreography description language, by Alistair Barros, Marlon Dumas and Phillipa Oaks". This is mainly because Choreography lacks of vendor support.

 

Luckily, some good solutions have been proposed, such as openKnowledge and WS-CDL+. Next time, i will focus on the implementation of Choreography.