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 Monday, 19 May 2003 18:49:45 UTC