RE: Straw-man Proposal for our mission statement

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
781-472-6317
jjd@eigner.com
www.eigner.com 
 
 

>>-----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-
>>chor@w3.org
>>Subject: Re: Straw-man Proposal for our mission statement
>>
>>My take on this:
>>
>>In reviewing other specifications in this space including security
(the
>>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,
etc,
>>they all seem to be recommend that we write choreographies using WSDL
>>operations.
>>
>>These specification will either add additional dimensions by
referencing
>>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
becomes,
>>are there other specifications we want to support that work in
different
>>ways indicating that we need to keep our options open?
>>
>>arkin
>>
>>
>>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
>>evolve,
>>>which they surely will to support security, reliability etc, then
only
>>our
>>>binding will need to change, the main spec, hopefull, should not need
to
>>>change.
>>>
>>>My $0.02c
>>>
>>>David
>>>
>>>-----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
>>>>>
>>>>>
>>>about
>>>
>>>
>>>>>the interactions between one WSDL-ized object and another. WSDL is
>>>>>
>>>>>
>>>just
>>>
>>>
>>>>>one
>>>>>
>>>>>
>>
>>
>>--
>>"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