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: Mon, 12 May 2003 20:46:50 -0400
To: "'Assaf Arkin'" <arkin@intalio.com>, "'Burdett, David'" <david.burdett@commerceone.com>
Cc: "'Jean-Jacques Dubray'" <jjd@eigner.com>, <Daniel_Austin@grainger.com>, <public-ws-chor@w3.org>
Message-ID: <005e01c318e9$36c9b060$0502a8c0@JJD>

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.

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.

Jean-Jacques Dubray____________________
Chief Architect
Eigner  Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451

>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Montag, 12. Mai 2003 19:07
>>To: Burdett, David
>>Cc: 'Jean-Jacques Dubray'; Daniel_Austin@grainger.com; public-ws-
>>Subject: Re: Straw-man Proposal for our mission statement
>>My take on this:
>>In reviewing other specifications in this space including security
>>WS-Security stack, SAML, etc), coordination (WS-TX and BTP), reliable
>>messaging (WS-RM(1) and WS-RM(2)) and even not yet discussed
>>specifications such as WS-Policy, WS-Addressing, management specs,
>>they all seem to be recommend that we write choreographies using WSDL
>>These specification will either add additional dimensions by
>>the same WSDL operation we reference, or by being part of the protocol
>>binding used by that WSDL operation (in effect also referencing them)
>>when it comes time to actually exchange messages.
>>So clearly the way to go is to write a choroegraphy definition by
>>referencing WSDL operations. Then you get everything else that works
>>with WSDL for free, including stuff that's available now and specs we
>>anticipate will be standardized in the near future.
>>Of course this only works with that list of specifications and relates
>>specifications that are part of the WS stack. The question then
>>are there other specifications we want to support that work in
>>ways indicating that we need to keep our options open?
>>Burdett, David wrote:
>>>I find myself agreeing with JJ again when he says ...
>>>[JJ] yes, one of the value of the spec could be to offer a binding to
>>>WSDL but remain open to other bindings.
>>>I think this is an important principle if only because, as bindings
>>>which they surely will to support security, reliability etc, then
>>>binding will need to change, the main spec, hopefull, should not need
>>>My $0.02c
>>>-----Original Message-----
>>>From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>>Sent: Friday, May 09, 2003 1:09 PM
>>>To: Daniel_Austin@grainger.com; jjd@eigner.com
>>>Cc: public-ws-chor@w3.org
>>>Subject: RE: Straw-man Proposal for our mission statement
>>>>>     I don't necessarily buy the argument that we are only talking
>>>>>the interactions between one WSDL-ized object and another. WSDL is
>>"Those who can, do; those who can't, make screenshots"
>>Assaf Arkin                                          arkin@intalio.com
>>Intalio Inc.                                           www.intalio.com
>>The Business Process Management Company                 (650) 577 4700
>>This message is intended only for the use of the Addressee and
>>may contain information that is PRIVILEGED and CONFIDENTIAL.
>>If you are not the intended recipient, dissemination of this
>>communication is prohibited. If you have received this communication
>>in error, please erase all copies of the message and its attachments
>>and notify us immediately.
Received on Monday, 12 May 2003 20:49:11 UTC

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