| QUESTION & ANSWER |
Dancing with Web services: W3C chair talks choreography |
 |
By Nitin Bharti, News Editor
09 Mar 2005 | SearchWebServices.com |
|
|
As companies embrace service-oriented architecture, the Business Process Execution Language (BPEL) continues to gain traction as a means to weave Web services into meaningful business processes. While BPEL allows existing services to be orchestrated into composite services, the Web Services Choreography Description Language (WS-CDL) goes a step further and describes the relationships between services in a peer-to-peer scenario.
In this interview, Steve Ross-Talbot, co-chair of the W3C Web Services Choreography Working Group, describes choreography and how it differs from orchestration in the context of Web services. He compares the WS-CDL and BPEL specifications, looks at how the two can work together and describes four tools that will be needed to work with WS-CDL.Could you tell us a little bit about yourself and what you do at the World Wide Web Consortium (W3C)?
Steve Ross-Talbot: I'm both the co-chair of the Web Services Choreography working group and I'm also the chair of Web Services Coordination. As co-chair, it's my job to ensure that the group can reach consensus. As a member of the working group, I also do technical work. I'm one of the authors for the requirements specification for WS-CDL.
What is the Web Services Coordination specification?
Ross-Talbot: This specification coordinates all the Web services standards within the W3C. So you've got a description that is the WSDL [Web Services Description Language] protocol, messaging which is SOAP, you've got choreography, you've got addressing, and there's also a link to the semantic Web domain and a link to the XML Core domain. All of these are reported to the WS-Coordination group and, all the chairs of those groups attend.
How does the W3C compare to other organizations like OASIS and the WS-I?
Ross-Talbot: Well firstly, the WS-I isn't a standards body; it never created a standard. What it does is take a bunch of standards, or in some cases proprietary specifications, such as WSDL 1.1 and SOAP 1.1 (which are really de facto and not official standards); so WS-I's job is to take de facto and actual standards, put them in a bag and give that bag a name. We call that Basic Profile.
OASIS is a very different kind of organization. By contrast, it's much more vendor-led than the W3C. The W3C is responsible for all the core building blocks of the Web, for Web services and for the semantic Web. All the ancillary things you need to make Web services happen, such as management and orchestration, are in OASIS.
What is WS-CDL and what problems does it address?
Ross-Talbot: The principal motivation behind WS-CDL is to ensure interoperability between a set of peer services. What Choreography says is 'I have a bunch of services. How do I write down what those services should do to engage with each other?' So I don't want to take a buyer's perspective, or a seller's perspective or a shipper's perspective. What I want to do is write down, from a high level, what's the exchange of messages that occur to buy a widget.
How do WS-CDL and WS-BPEL differ?
Ross-Talbot: Any real business transaction isn't just one function call, it's a sequence of function calls and it may be lots of things in parallel between different services that occur. BPEL is about 'how do I construct Web services out of existing Web services.' In other words, BPEL is about the orchestration of existing services to yield another service.
Choreography is completely complementary to that. WS-CDL is an unambiguous way of describing the relationships between the services in a peer-to-peer collaboration without necessitating any orchestration at all. That's very important because if my business and your business are talking together, I can guarantee you that neither of us would accept orchestrating the other's services.
On the orchestration side of it, which is what BPEL does, that comes in on your side of the firewall and my side of the firewall in order for me to reuse my services. Now I might include in my orchestration, one of your services but then present it as my service; however, I'm really calling out to your service. So with BPEL I'm the conductor in the pit.
In any dance, however, you never see somebody on stage telling the dancers what to do. The dancers have a choreography description. I know this because my daughter's a dancer. They learn their dance and they learn the 'touch points' where they interact with others, the same way you do in a choreography description.
Can both Web services choreography and Web services orchestration be specified using a common language?
Ross-Talbot: No, because orchestration has more to do with the recursive composition of services so that it will yield another service. Orchestration gets realized as an executable, so you can identify the conductor in the pit and realize that he's as much an actor as the violinist.
Choreography, on the other hand, is a description. The choreographer writes the descriptions down and gives it to the dancers and works with them to make sure they learn their parts, but he's not there as an 'executable actor' when it's happening. So choreography is purely a description, but it's a description that can be used to generate the behavior of the dancers. You can use it to generate, but it is not executable.
Does WS-CDL assume the existence of a BPEL engine by both collaborating business partners?
Ross-Talbot: WS-CDL doesn't require BPEL. It can work with BPEL, but it doesn't require it. It requires any endpoint language such as BPEL, Java, C#; it's anything that is executable. It doesn't even require WSDL, but we left the hooks in just in case BPEL wanted to bind it to something like RosettaNet.
Will exclusive tooling need to be developed around WS-CDL or will vendors extend current BPEL tools be extended to support this spec?
Ross-Talbot: I regard it as an impossibility to extend BPEL. BPEL was never targeted at solving this problem, and equally, CDL is not targeted at solving recursive composition. So I think that there will be [exclusive] tooling required.
Can you describe some of the tools developers will need to work with WS-CDL?
Ross-Talbot: Firstly, you need an editor to create choreography, to validate the CDL, the same way you have editors for BPEL. Secondly, you need to have an endpoint monitor. This monitor sits in front of say, the buyer, and looks at the messages and validates at runtime the behavior of the service against the CDL contract.
You also need an endpoint code generator, for whatever platform you're using such as J2EE [Java 2 Enterprise Edition], .NET, using BPEL or not using BPEL, which is creating a service itself with all the behavior described in the choreography.
Additionally, you would also need an auto-test generator, which is a program that gets generated from the CDL specification automatically, that fires messages into a service based on the description in the choreography. It tests the choreography at the service endpoint.
|
|
|
|
