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 01:51:42 UTC