RE: Web Services Choreography Requirements 1.0 draft uploaded

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 13:52:09 UTC