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

Re: simultaneous execution (was: Web Services Choreography Requirements 1.0 draft uploaded)

From: Jon Dart <jdart@tibco.com>
Date: Thu, 31 Jul 2003 11:23:28 -0700
Message-ID: <3F295EA0.1080901@tibco.com>
To: "Burdett David" <david.burdett@commerceone.com>
CC: public-ws-chor@w3.org

This was discussed a bit at the F2F.

IMO it is not desirable to have to add data to Web service messages in 
order for those messages to be part of a choreography. There are simple 
cases where you don't need to do this explicitly. E.g. if you are using 
HTTP and the reply goes back over the same socket as the request, then 
you have an implicit correlation across request and reply. But you don't 
have this implicit correlation if there's an exchange of multiple 
communications that don't share the same session. Also if you're using 
an asynchronous protocol, then correlation will have to be part of the 
message content, as you note.

The proposed WS-MessageData spec from BEA might be used as a basis for 
this kind of correlation information.

--Jon

Burdett, David wrote:
> Jon
> 
> What you are stating as a requirement is that it should be possible to for
> two choreographies "executed" at the same time.
> 
> To fully define this requirement you actually need some extra statements,
> more specifically the requirement should be ... "It should be possible for
> two (or more) instances of the execution of choreographies of the same type
> to occur between the same service instances".
> 
> A simple example of this is a single buyer placing two (or more) orders
> *simultaneously* with the same seller where the buyer and seller send and
> receive using the same instances of their order placement and order receipt
> software.
> 
> If you accept this requirement, it implies a further requirement which is
> ... "A role in a choreography must be able to identify the instance of a
> choreography to which any message in a choreography belongs".
> 
> I think the only practical way of meeting this requirement is by carrying in
> the message metadata that allows the two following information items to be
> identified:
> 1. Choreography Type - which identifies which choreography is being followed
> 2. Choreography Instance Id - which identifies which particular instance of
> a choreography the message relates to. This item was called a "Conversation
> Id" in ebXML messaging.
> 
> David
> 
> -----Original Message-----
> From: Jon Dart [mailto:jdart@tibco.com]
> Sent: Thursday, July 24, 2003 1:02 PM
> To: public-ws-chor@w3.org
> Subject: Re: Web Services Choreography Requirements 1.0 draft uploaded
> 
> 
> 
> Kudos and thanks to the editors for getting this out.
> 
> A few comments:
> 
> re: 4.3 Scalability. One of the requirements I have mentioned is 
> re-entrancy: execution of a choreography flow should not block execution 
> of another instance of the same flow (e.g. two orders coming in from 
> customers should be able to be processed in parallel). (This is in the 
> F2F minutes, I believe). This may be purely an implementation issue, but 
> we shouldn't preclude it at the spec level, or assume serialized execution.
> 
> (This is different from D-CR-040 or D-CR-041 because I'm not talking 
> about parallel flows within a choreography, but parallel execution of 
> choreography instances).
> 
> D-CR-009 is a special case of D-CR-061, I think. Maybe they should be 
> grouped together.
> 
> Re D-CR-049 (design-time validation): it isn't really clear to me what 
> this means. What does "correct behavior" mean at design time? Absence of 
> deadlock, or ?
> 
> The doc needs a spell check.
> 
> --Jon
> 
> Daniel_Austin@grainger.com wrote:
> 
>>Greetings,
>>
>>        The most recent draft of the requirements document has been 
>>uploaded to the archive list (still having problems uploading to W3C). 
>>It's here:
>>
>>http://lists.w3.org/Archives/Public/www-archive/2003Jul/0024.html
>>
>>        This version is labeled 1.0, and is dated for July 30th, next 
>>Wednesday, for publication after our next call, based on the group's 
>>approval.
>>
>>        Please review this document carefully. Much has changed since 
>>the last version. Here's a summary:
>>* requirements (some 60+) have been added to the document.
>>* the use cases have been largely rewritten
>>* references are now available (though not yet footnoted)
>>* many other changes
>>
>>        I'd like to ask that the entire group carefully review this 
>>document with a view to publication on July 30th. The document is not 
>>entirely ready to be published, there is still some minor publication 
>>clean up to be done. Otherwise, it's not a bad first working draft of 
>>the group's requirements.
>>
>>On behalf of my fellow editors,
>>
>>D-
>>
>>
>>*************************************************
>>Dr. Daniel Austin
>>Sr. Technical Architect
>>daniel_austin@grainger.com
>>847 793 5044
>>Visit http://www.grainger.com
>>
>>"If I get a little money, I buy books. If there is anything left over, I 
>>buy clothing and food."
>>-Erasmus
> 
> 
> 
> 
> 
Received on Thursday, 31 July 2003 14:23:53 GMT

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