- From: Carol McDonald <carol.mcdonald@sun.com>
- Date: Thu, 29 May 2003 15:10:06 -0400
- To: Steve Ross-Talbot <steve@enigmatec.net>
- CC: Jean-Jacques Dubray <jjd@eigner.com>, "'Yaron Y. Goland'" <ygoland@bea.com>, "'Assaf Arkin'" <arkin@intalio.com>, "'Burdett, David'" <david.burdett@commerceone.com>, Daniel_Austin@grainger.com, public-ws-chor@w3.org
+1 Steve Ross-Talbot wrote: > > +1 from me too. > > Steve T > > On Wednesday, May 28, 2003, at 07:27 am, Jean-Jacques Dubray wrote: > >> >> +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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >> >> This email is confidential and may be protected by legal privilege. >> If you are not the intended recipient, please do not copy or >> disclose its content but delete the email and contact the sender >> immediately. Whilst we run antivirus software on all internet emails >> we are not liable for any loss or damage. The recipient is advised to >> run their own antivirus software. >> > > This email is confidential and may be protected by legal privilege. If > you are not the intended recipient, please do not copy or disclose > its content but delete the email and contact the sender immediately. > Whilst we run antivirus software on all internet emails we are not > liable for any loss or damage. The recipient is advised to run their > own antivirus software. >
Received on Thursday, 29 May 2003 15:07:48 UTC