Re: CSF's and choreography - at least it alludes to some.....

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