- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Wed, 28 May 2003 02:27:07 -0400
- To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>, "'Assaf Arkin'" <arkin@intalio.com>
- Cc: "'Burdett, David'" <david.burdett@commerceone.com>, <Daniel_Austin@grainger.com>, <public-ws-chor@w3.org>
+1 Jean-Jacques >>-----Original Message----- >>From: Yaron Y. Goland [mailto:ygoland@bea.com] >>Sent: Dienstag, 27. Mai 2003 21:12 >>To: Jean-Jacques Dubray; 'Assaf Arkin' >>Cc: 'Burdett, David'; Daniel_Austin@grainger.com; public-ws-chor@w3.org >>Subject: RE: Straw-man Proposal for our mission statement >> >>Based on this thread I would like to put forward a proposal to the group >>for >>a set of requirements that I hope can bring this thread to a successful >>conclusion: >> >>"The WS-Chor specification MUST NOT adopt a design that prevents it from >>taking full advantage of all features in WSDL 1.2. The WS-Chor >>specification >>MAY adopt a design that enables the use of alternative message description >>than WSDL 1.2 where and when the working group decides this is appropriate >>and does not conflict with any other requirements." >> >>I would then propose that we table this issue until we finish with the >>requirements and start doing design so we can look at exactly what an >>abstract design would require and then decide if we want to try it. >> >> Yaron >> >>> -----Original Message----- >>> From: Jean-Jacques Dubray [mailto:jjd@eigner.com] >>> Sent: Wednesday, May 21, 2003 1:16 PM >>> To: 'Yaron Y. Goland'; 'Assaf Arkin'; 'Jean-Jacques Dubray' >>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com; public-ws-chor@w3.org >>> Subject: RE: Straw-man Proposal for our mission statement >>> >>> >>> The cost of abstraction is way overestimated here. The abstraction is >>> already built, it is called a message and a message exchange pattern. >>> Now we have the choice to directly use the WSDL message definition or >>> rather define something like: >>> >>> <message name="ProcessPO"> >>> <message name="AckPO> >>> <mep name="ProcessPO"> >>> >>> <binding message="ProcessPO" type="WSDL" version="1.2"> >>> <portType=""> >>> </binding> >>> <binding MEP="ProcessPO" type="ebXML" version="2.0> >>> <BPSS >>> URI=http://oasis.org/bunchOfStandardsCollabs/aPOCollaboration"> >>> <businessTransactionActivity name="ProcessPO> >>> </binding> >>> <binding message="AckPO" type="PlainOldFax" > >>> <fax number="555-1234"/> >>> </binding> >>> >>> so please, let's reasonable on our assertions. >>> >>> I am currently on travel in beautiful Berlin, with limited email and web >>> access. So I will respond more thoroughly to the emails this week-end. >>> >>> Cheers, >>> >>> JJ- >>> >>> >>> >>-----Original Message----- >>> >>From: Yaron Y. Goland [mailto:ygoland@bea.com] >>> >>Sent: Montag, 19. Mai 2003 18:50 >>> >>To: Assaf Arkin; Jean-Jacques Dubray >>> >>Cc: 'Burdett, David'; Daniel_Austin@grainger.com; >>> public-ws-chor@w3.org >>> >>Subject: RE: Straw-man Proposal for our mission statement >>> >> >>> >>+1 on tying to WSDL and +1 on Asaf's point that there is a cost to >>> >>abstraction. The only way to 'abstract' away dependency on something >>> is to >>> >>completely re-invent the thing being depended on and then define how >>> your >>> >>re-invention maps to the original. This is an extremely expensive >>> process >>> >>that causes significant harm to interoperability and should only be >>> >>undertaken when there is no other choice. The 'abstractions' >>> introduced >>> >>between WSDL and SOAP have caused so much interoperability pain that >>> two >>> >>different organizations had to be formed to sort out the resulting >>> mess. >>> >>What we need is a little less abstraction and a lot more >>> interoperability. >>> >> >>> >> Yaron >>> >> >>> >>> -----Original Message----- >>> >>> From: public-ws-chor-request@w3.org >>> >>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Assaf Arkin >>> >>> Sent: Monday, May 12, 2003 9:30 PM >>> >>> To: Jean-Jacques Dubray >>> >>> Cc: 'Burdett, David'; Daniel_Austin@grainger.com; >>> public-ws-chor@w3.org >>> >>> Subject: Re: Straw-man Proposal for our mission statement >>> >>> >>> >>> >>> >>> >>> >>> Jean-Jacques Dubray wrote: >>> >>> >>> >>> >I don't understand your argument, why won't you get everything for >>> free >>> >>> >as long as you have a binding to WSDL whether it is direct or let's >>> say >>> >>> >indirect for the lack of a better word. The advantage of the later >>> is >>> >>> >that in addition of getting everything the ws-arch has to offer, >>> you >>> >>can >>> >>> >also re-use the formalism of ws-chor for other technologies. >>> >>> > >>> >>> > >>> >>> I just don't see those other technologies as being interesting >>> that's >>> >>> all. My personal opinion. In a W3C working group I would prefer to >>> pick >>> >>> all the relevant technologies that the W3C maps out as interesting >>> as >>> >>> part of the WSA. So far I've only heard of WSDL. If it boils down to >>> one >>> >>> technology and that makes my life easier, all the better. What other >>> >>> technologies do you suggest we look into? >>> >>> >>> >>> >Having a "binding" framework that relates ws-chor to WSDL garanties >>> >>that >>> >>> >the design of ws-chor is now decoupled from the evolution of WSDL, >>> we >>> >>> >would only change the binding not the core choreography language. >>> >>> > >>> >>> >We can clearly see the limitations of a tight coupling between BPML >>> or >>> >>> >BPEL and web services, now that WSDL is shifting from operations to >>> >>> >MEPs, one has to adjust the corresponding specs. >>> >>> > >>> >>> Here is how I understand it. Correct me if I'm wrong. >>> >>> >>> >>> Option 1: based on WSDL >>> >>> >>> >>> Can't use other technologies. Need to be updated when WSDL gets >>> updated. >>> >>> >>> >>> Option 2: abstacted with binding to WSDL >>> >>> >>> >>> Can use other technologies. Needs to be updated when WSDL gets >>> updated. >>> >>> Extra level of indirection. >>> >>> >>> >>> I think it's obvious why I would prefer no#1, but just for the sake >>> of >>> >>> being verbose. >>> >>> >>> >>> Either way if I use some normative specification and that >>> specification >>> >>> evolves I would want to use the new version, be it WSDL, XSDL, >>> XPath, >>> >>> whatever. So either way we need to update the specification. It may >>> >>> affect language section 4 or it may affect binding appendix A, but >>> >>> that's all the same. I don't see a real big differentiaor between 1 >>> and >>> >>> 2 to suggest one is better than the other. And as you guess I've >>> already >>> >>> planned for it so I know what it entails and it doesn't seem like a >>> big >>> >>> issue to me. >>> >>> >>> >>> Option 2 is simply more complicated to support and require invention >>> of >>> >>> an abstract layer and invention of a binding layer which makes the >>> >>> specification, implementations, interoperability, RI, etc more >>> >>> complicated. That's good if it actually buys you anything. What does >>> it >>> >>> buy you? >>> >>> >>> >>> I've heard before the argument that if we only wrote the spec to not >>> so >>> >>> directly rely on WSDL we could also use IDL. Well, by the time we go >>> to >>> >>> finish the spec the problem was already taken care of and you have >>> >>> IDL-WSDL mapping that's well defined and readily available. It was >>> in my >>> >>> opinion - then and now - a waste of time to consider anything other >>> than >>> >>> WSDL. >>> >>> >>> >>> We've talked about simplifying the language which as I read it means >>> do >>> >>> less features now, do the rest later on. I'm going to buy a hat. If >>> >>> we're going to have to change the specification because using WSDL >>> is no >>> >>> longer the only interesting option before we get around to writing a >>> new >>> >>> version of the specification anyway, I'm going to eat it. Wish me >>> >>luck ;-) >>> >>> >>> >>> arkin >>> >>> >>> >>> > >>> >>> >Jean-Jacques Dubray____________________ >>> >>> >Chief Architect >>> >>> >Eigner Precision Lifecycle Management >>> >>> >200 Fifth Avenue >>> >>> >Waltham, MA 02451 >>> >>> >781-472-6317 >>> >>> >jjd@eigner.com >>> >>> >www.eigner.com >>> >>> > >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>>
Received on Wednesday, 28 May 2003 04:38:31 UTC