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

RE: BurdettML comments

From: Burdett, David <david.burdett@commerceone.com>
Date: Thu, 26 Jun 2003 20:44:24 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC08391BDB@C1plenaexm07.commerceone.com>
To: jdart@tibco.com, Burdett David <david.burdett@commerceone.com>
Cc: "'public-ws-chor@w3.org '" <public-ws-chor@w3.org>

Jon

See comments in line below.

David

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Wednesday, June 25, 2003 9:56 AM
To: Burdett David
Cc: 'public-ws-chor@w3.org '
Subject: Re: BurdettML comments


Burdett, David wrote:

> Also in my spec I assumed that an Interaction was implmented by a single
> message (ignoring signals) sent from one role to another. In your example
> for "DoLogin" to succeed, you would need two messages the LoginRequest
from
> the client to the server and the LoginResponse from the server to the
> client. The result could be either succeed or fail.

One issue here for me is how this maps into the SOAP/WSDL layer (if 
there is one). The simple way to implement login is with a request/reply 
MEP. Then there are two messages, as you suggest, but it is one 
operation, in the WSDL sense of the term. Maybe it should be possible to 
include such a MEP in the choreography without explicitly showing the 
two messages - it is a logical unit.
<DB>I like this idea in principle, however some MEPs consist of a
request/response whilst others consist of a single message. I can't easily
think of how you could easily combine these different types of MEPs into a
single choreography definition.</DB>


Generally, I am concerned about duplicating WSDL layer information into 
the choreography layer. When you have duplication you also have the 
possibility for the information to get out of sync.
<DB>I agree with this idea also, however I am not sure how you would easily
combine them as described earlier.</DB>


Also re failure: if you are using SOAP, the WSDL tells you if a fault 
condition is possible. If this fault leads to a state transition it may 
need to be handled explicitly in the choreography. 
<DB>I agee it will need separate handling.</DB>
But perhaps there 
should be a default behavior (termination of the choreography?). Also 
something like the BPEL concept of fault handlers may be necessary. 
There is no equivalent concept in BurdettML, AFAIK.
<DB>Default fault handlers are a good idea except that you would need one
for each role</DB>
--Jon
Received on Thursday, 26 June 2003 23:44:27 GMT

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