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, 28 May 2003 02:27:07 -0400
To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>, "'Assaf Arkin'" <arkin@intalio.com>
Cc: "'Burdett, David'" <david.burdett@commerceone.com>, <Daniel_Austin@grainger.com>, <public-ws-chor@w3.org>
Message-ID: <005101c324e2$3c131c00$1a6e100a@JJD>

+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
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>>
>>>
Received on Wednesday, 28 May 2003 04:38:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:17 GMT