RE: Straw-man Proposal for our mission statement

David:

I think that you are pointing in the right direction. A key success
factor to the ws-chor is the ability to reuse the choreography
definition in different contexts.

It usually takes a lot of time to define a choreography that say an
industry would agree to use, or even worse, a "horizontal" choreography
that could be used across industries. Consequently, I would view it as a
requirement that the choreography definition can be bound to different
physical message formats, or even different technologies. 

Ultimately, I think that people will publish choreographies like they
publish APIs today. Libraries will be available that one can download
and start using in its own context. The more context we provide
up-front, the less re-usable they will be. If we move the context into a
binding framework and provide an extensible binding framework, then the
same people can take advantage of the choreography definition and link
it to their systems. 

Now if we take the other extreme, we can think that for "internal"
choreographies it is even more critical to allow binding to various
technologies and data formats. Who would dare to assume that every IT
department will be 100% web service enabled by the time ws-chor ships?

Lastly it is also important to sufficiently decouple the choreography
from the binding such that when you change the binding only, you are
guaranteed that the choreography will execute the same way it did.

Jean-Jacques 
 
 

>>-----Original Message-----
>>From: Burdett, David [mailto:david.burdett@commerceone.com]
>>Sent: Dienstag, 13. Mai 2003 13:07
>>To: 'Assaf Arkin'; Steve Ross-Talbot
>>Cc: Jean-Jacques Dubray; Burdett, David; Daniel_Austin@grainger.com;
>>public-ws-chor@w3.org
>>Subject: RE: Straw-man Proposal for our mission statement
>>
>>I actually think that we should try and use WSDL interfaces, but we
need
>>to
>>check that it does what we need it to do. The specific problem is the
>>requirement for the WSDL interface to accept abstract message types,
for
>>example an order, without specifying exactly which format of an order
it
>>will accept as they can vary.
>>
>>I suppose that really I need to do more work myself looking at the
latest
>>WSDL specs on this.
>>
>>David
>>
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Tuesday, May 13, 2003 2:52 AM
>>To: Steve Ross-Talbot
>>Cc: Jean-Jacques Dubray; 'Burdett, David'; Daniel_Austin@grainger.com;
>>public-ws-chor@w3.org
>>Subject: Re: Straw-man Proposal for our mission statement
>>
>>
>>
>>Steve Ross-Talbot wrote:
>>
>>>
>>> I have made this WSDL non-WSDL a topic for discussion at the call
>>> later  today.
>>> I'd like to get a summary of the views expressed so far ... any
>>> volunteers?
>>>
>>> Cheers
>>>
>>> Steve T
>>
>>Here's a list of what I've heard so far. I've tried my best to express
>>the view as briefly and broadly as possible, so people who support one
>>or more views can elaborate more. Listed from least to most likely to
>>focuse solely on WSDL:
>>
>>1. We need to define choreographies in abstract terms. Use of WSDL is
an
>>implementation detail.
>>
>>2. We need to define abstract choreographies with bindings to multiple
>>technologies, including but not limited to WSDL.
>>
>>3. Using WSDL prevents us from supporting other specifications that
>>address RM, security, transactions, etc.
>>
>>4. You can't write a good choreography language using WSDL, but you
can
>>bind a good choreography to WSDL.
>>
>>5. The interesting capabilities are already supported by WSDL and
>>specifications that extend WSDL.
>>
>>6. Being a W3C WG implies ...
>>
>>Feel free to add, remove, expand, donate 2 cents, etc ...
>>
>>
>>I want to add one request for clarification. I did that a few times
>>before, I hope a few people would be willing to take on it this time.
>>
>>WSDL encapsulates two layers within the same specification that
>>personally I would have liked to see written as two different parts of
>>the same specification for better clarity (similar to the two parts in
>>XSDL and SOAP).
>>
>>One layer deals with abstract service types as defined by their
>>interface implying what the service looks like but not any particular
>>service. The other layer deals with actual services as defined by
their
>>end-points, protocol binding and the interface they support.
>>
>>Someone may say "I don't like the specification to refer to WSDL
>>services" and someone else may say "I like the specification to refer
to
>>WSDL interfaces". These two points of view are not contradictory in
any
>>way. However they do become contradictory if we don't specify what
part
>>of WSDL we refer to.
>>
>>So if anyone has an opinion for or against WSDL, can you please
clarify
>>whether you refer to the WSDL services, WSDL interfaces or WSDL whole.
I
>>think that alone would bring a bit more agreement into the discussion.
>>
>>arkin

Received on Tuesday, 13 May 2003 13:33:10 UTC