- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 06 May 2003 12:40:16 -0700
- To: jdart@tibco.com
- CC: Steve Ross-Talbot <steve@enigmatec.net>, public-ws-chor@w3.org
I think this and similar articles raise a very interesting point. One that is generally captured in a single sentence but is in fact the whole point of the article: so which language would it be? Look at it from the perspective of the customer for a second, a point of view that is not married to any particular specification. As a customer you see the need for a specification and products that support it and you don't really care what it's called. You just need something that meets your requirements. You get reassured by the fact that so many vendors are working to address that need by proposing specifications and providing their innovation to be incorporated by future products. But it does become confusing if you need to define an architecture based on one of these specifications which can only accomodate products using that one specification. Now that all these languages are out there and available on a roylaty free basis we have a pool of IP that we can leverage as we work to create standards in this space. But we need to start focusing on solving problems, not creating more problems. For me, one CSF is achieved if the customer no longer have to ask "so which language is it?", but instead "so how do I solve my business problem using my arsenal of tools?" As for as orchestration goes - and let me use the informal definition of the term - that's an easy decision to make. There's an ongoing track at OASIS to provide a solution and if we put our resources there we get one requirement and a lot of confusion out of the way. We have a short list of CSF for what a choreography language should support in one way or another. Most of them focus on the ability to describe how services interact with each other as part of the choreography and the way in which services can be discovered and existing definitions can be reused to compose new choreographies. Whether you define these interactions directly, derive them from some other definition, reference them, glue them on, etc is all good as long as you can use these definitions. To make it absolutely clear, in my opinion the choreography should at the minimum be able to express the WS interactions with the same capabilities presented in WSBPEL. Call them choreography-level MEPs if you like. It's not a fact, just my gut feeling, that a choreography language that lacks that ability is not going to be of much use. When I say that the choreography language must incorporate these capabilities, I'm talking about the what and not prescribing the how. We can create new and interesting languages for writing choreographies that can do the same thing. I'm not convienced that's doable considering the effort required and the narrow time frame. It's much better to start with something we already have, for example WSCI: refactor it to meet the minimum list of CSFs and to leverage WSDL 1.2 and then extend it with the other features we deem necessary. Or we may decide to focus on those other features we deem necessary and use WSBPEL as the language that describes choreography-level MEPs. Since I'm not in favor of duplication I would be more inclined to pursue a track that focuses on the additional capabilities required in choreography and reuses existing specifications for handling the three-level MEPs (protocol, operation and choreography). These additional capabilities should not be B2B specific but should be B2B supportive and cover the part of the choreography that is not related to the actual WS interaction. I'm curious to know if other vendors here share these feelings. arkin Jon Dart wrote: > > It is slightly garbled in places (refers to "WS-Transaction BPEL") but > makes some interesting points. > > --Jon > > Steve Ross-Talbot wrote: > >> >> http://www.webservices.org/index.php/article/articleview/920/1/3/ >> >> This email is confidential and may be protected by legal privilege. >> If you are not the intended recipient, please do not copy or >> disclose its content but delete the email and contact the sender >> immediately. Whilst we run antivirus software on all internet emails >> we are not liable for any loss or damage. The recipient is advised to >> run their own antivirus software. >> >> >> > >
Received on Tuesday, 6 May 2003 15:42:34 UTC