W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

RE: Internal processes and/or external choreographies (was RE: Ev ents and States ...

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Fri, 11 Apr 2003 13:23:02 -0400
To: "'Assaf Arkin'" <arkin@intalio.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>
Cc: <steve@enigmatec.net>, "'Cummins, Fred A'" <fred.cummins@eds.com>, "'Burdett, David'" <david.burdett@commerceone.com>, <jdart@tibco.com>, <public-ws-chor@w3.org>
Message-ID: <001701c3004f$146f4a00$0502a8c0@JJD>



>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Friday, April 11, 2003 1:14 PM
>>To: Jean-Jacques Dubray
>>Cc: steve@enigmatec.net; 'Cummins, Fred A'; 'Burdett, David';
>>jdart@tibco.com; public-ws-chor@w3.org
>>Subject: Re: Internal processes and/or external choreographies (was
RE: Ev
>>ents and States ...
>>IMO the choreography should be defined in terms of MEPs. That gives us
>>the best bang for the money. And we should agree to use the MEPs
>>provided by WSDL 1.2, both the pre-defined and extensions that can be
>>added in the future.
>>It then becomes an issue for the implementation to support these MEPs,
>>something it has to do anyway whether or not you do that in the
>>choreography language. This may be very complicated, or it may be more
>>trivial than you think. At least in my experience. I'm sure the
>>orchestration languages would be extended to take advantage of WSDL
>>when it becomes a proposed recommendation.
>>I take it for granted that implementations and other specifications
>>be made to work with WSDL 1.2 and take advantage of the variety of
>>supported by the WSD WG framework. So if we also utilize WSDL 1.2 as
>>basis for the choreography language, our work will be cut out for us.
>>Jean-Jacques Dubray wrote:
>>>As long as the orchestration language supports the notion of message
>>>exchange (hopefully they will soon go further an also understand the
>>>notion of message exchange patterns :-), I think that the binding is
>>>possible. At the control flow level, there might be some
>>>(e.g. something specified in ws-chor cannot be reproduced exactly in
>>>orchestration language), which would mean that some ws-chor
>>>cannot be implemented in a given orchestration language. However, I
>>>don't think that this should be a requirement imposed on ws-chor.
>>>orchestration language are so primitive (e.g. they don't understand
>>>a MEP is) that it would be a mistake to force ws-chor to adapt to it.
>>>should be the other way around.
Received on Friday, 11 April 2003 13:25:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:00 UTC