RE: Straw-man Proposal for our mission statement

If failing to understand what is wrong with the wsdl message construct!.

Martin.

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques Dubray
> Sent: Wednesday, May 21, 2003 10:16 AM
> 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 Thursday, 22 May 2003 11:31:26 UTC