- 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>
+1 JJ- >>-----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 1.2 >>when it becomes a proposed recommendation. >> >>I take it for granted that implementations and other specifications will >>be made to work with WSDL 1.2 and take advantage of the variety of MEPs >>supported by the WSD WG framework. So if we also utilize WSDL 1.2 as the >>basis for the choreography language, our work will be cut out for us. >> >>arkin >> >>Jean-Jacques Dubray wrote: >> >>>Assaf: >>> >>>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 incompatibility >>>(e.g. something specified in ws-chor cannot be reproduced exactly in the >>>orchestration language), which would mean that some ws-chor definition >>>cannot be implemented in a given orchestration language. However, I >>>don't think that this should be a requirement imposed on ws-chor. Some >>>orchestration language are so primitive (e.g. they don't understand what >>>a MEP is) that it would be a mistake to force ws-chor to adapt to it. It >>>should be the other way around. >>> >>>JJ- >>> >>> >>>
Received on Friday, 11 April 2003 13:25:04 UTC