Re: simultaneous execution

Jon Dart wrote:

>
> 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.

+1

Then there's always the possibilty to use the extended addressing 
mechanism of WS-Addressing, or the message sequencing of WS-RM.

arkin

>
> 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
>>
>>
>>
>>
>>
>>
>
>


-- 
"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 Thursday, 31 July 2003 14:42:13 UTC