- From: Assaf Arkin <arkin@intalio.com>
- Date: Fri, 11 Apr 2003 10:14:23 -0700
- To: 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
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:16:46 UTC