- From: Burdett, David <david.burdett@commerceone.com>
- Date: Thu, 31 Jul 2003 13:12:29 -0700
- To: "'Assaf Arkin'" <arkin@intalio.com>, jdart@tibco.com
- Cc: "Burdett, David" <david.burdett@commerceone.com>, public-ws-chor@w3.org
If all you have is a request response over the same channel, then I agree it is not necessary unless that request response is part of a larger and longer interaction. But if you do need to do this, it is hardly rocket science and has also been done in other specs such as ebXML messaging. What we really want to do is have one *definitive* way of providing this functionality. Now identifying which choreography you are following is definitely, IMO, part of our scope. However identifying that a set of messages are related is broader as you could have some sort of "correlation identifier" without specifing the choreography which being followed. David -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Thursday, July 31, 2003 11:41 AM To: jdart@tibco.com Cc: Burdett David; public-ws-chor@w3.org Subject: 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 16:12:40 UTC