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, 21 May 2003 13:16:53 UTC