W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

RE: Straw-man Proposal for our mission statement

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Wed, 21 May 2003 13:16:00 -0400
To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'Assaf Arkin'" <arkin@intalio.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>
Cc: "'Burdett, David'" <david.burdett@commerceone.com>, <Daniel_Austin@grainger.com>, <public-ws-chor@w3.org>
Message-ID: <005e01c31fbc$b8de6080$ca01a8c0@JJD>

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">
<binding MEP="ProcessPO" type="ebXML" version="2.0>
	<businessTransactionActivity name="ProcessPO>
<binding message="AckPO" type="PlainOldFax" >
	<fax number="555-1234"/>

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.


>>-----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;
>>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
>>re-invention maps to the original. This is an extremely expensive
>>that causes significant harm to interoperability and should only be
>>undertaken when there is no other choice. The 'abstractions'
>>between WSDL and SOAP have caused so much interoperability pain that
>>different organizations had to be formed to sort out the resulting
>>What we need is a little less abstraction and a lot more
>>		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;
>>> 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
>>> >as long as you have a binding to WSDL whether it is direct or let's
>>> >indirect for the lack of a better word. The advantage of the later
>>> >that in addition of getting everything the ws-arch has to offer,
>>> >also re-use the formalism of ws-chor for other technologies.
>>> >
>>> >
>>> I just don't see those other technologies as being interesting
>>> all. My personal opinion. In a W3C working group I would prefer to
>>> all the relevant technologies that the W3C maps out as interesting
>>> part of the WSA. So far I've only heard of WSDL. If it boils down to
>>> 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
>>> >the design of ws-chor is now decoupled from the evolution of WSDL,
>>> >would only change the binding not the core choreography language.
>>> >
>>> >We can clearly see the limitations of a tight coupling between BPML
>>> >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
>>> Option 2: abstacted with binding to WSDL
>>> Can use other technologies. Needs to be updated when WSDL gets
>>> Extra level of indirection.
>>> I think it's obvious why I would prefer no#1, but just for the sake
>>> being verbose.
>>> Either way if I use some normative specification and that
>>> evolves I would want to use the new version, be it WSDL, XSDL,
>>> 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
>>> 2 to suggest one is better than the other. And as you guess I've
>>> planned for it so I know what it entails and it doesn't seem like a
>>> issue to me.
>>> Option 2 is simply more complicated to support and require invention
>>> 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
>>> buy you?
>>> I've heard before the argument that if we only wrote the spec to not
>>> directly rely on WSDL we could also use IDL. Well, by the time we go
>>> 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
>>> WSDL.
>>> We've talked about simplifying the language which as I read it means
>>> 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
>>> 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, 21 May 2003 13:16:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:05 UTC