- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Thu, 7 Aug 2003 11:23:03 -0700
- To: "'Burdett, David'" <david.burdett@commerceone.com>, "'Monica Martin'" <monica.martin@sun.com>, "'Yves Lafon'" <ylafon@w3.org>
- Cc: <jdart@tibco.com>, "'Ugo Corda'" <UCorda@SeeBeyond.com>, "'Cummins Fred A'" <fred.cummins@eds.com>, <public-ws-chor@w3.org>
This is of course assuming a certain solution. We should discus whether we would like a specific solution (e.g. message ids) or a generic correlation mechanism e.g like that found in BPEL, where any parts of a message header or body can be defined as the correlation "keys" for a particular choreography instance. Lets discuss the relative merits and requirements and then we can work out the appropriate actions and group(s) to talk to. Martin. > -----Original Message----- > From: public-ws-chor-request@w3.org > [mailto:public-ws-chor-request@w3.org] On Behalf Of Burdett, David > Sent: Thursday, August 07, 2003 8:47 AM > To: 'Monica Martin'; Yves Lafon; Burdett, David > Cc: 'jdart@tibco.com'; 'Ugo Corda'; Cummins Fred A; > public-ws-chor@w3.org > Subject: RE: Off topic but relevant > > > > Monica > > Perhaps this is something that should be done by XMLP - I > don't have a problem with that. However I think that the > implementation of a solution that is using the choreography > definition specification that this group will produce NEEDS > information in the SOAP header such as Conversation Id, > Message Id, etc. > > This, in turn, makes our spec dependent on the existence of > such specs that we can reference in our own work. > > So I think this IS an issue for us which means that perhaps > we should make it a formal liaison point/request with XMLP. > > Does this make sense? > > David > > -----Original Message----- > From: Monica Martin [mailto:monica.martin@sun.com] > Sent: Thursday, August 07, 2003 6:51 AM > To: Yves Lafon; Burdett, David > Cc: 'jdart@tibco.com'; 'Ugo Corda'; Cummins Fred A; > public-ws-chor@w3.org > Subject: Re: Off topic but relevant > > > > >>Burdett: There's a whole bunch of things like "identification of > choreography > >>instance" that can usefully be defined just once and then used by > everybody. > >>I'd include in this the following additional information > that needs to > >>go > in > >>a (SOAP) message (there are probably more): > >>1. Message Id - a unique id for a message > >>2. RefToMessage Id - a way of identifying an earlier > message to which > >>this message relates - useful for identifying messages in error 3. > >>Conversation Id - which is really a choreography instance id as it > >>identifies a set of related messages 4. Creation Time - the time a > >>message was initially created 5. Expiry Time - the time after which > >>the recipient of a SOAP message > should > >>no longer process it. > >> > >> > > > >Lafon: Message Ids, and time information, although very > useful may not > >be > easy to > >define in an absolute manner. A requirement to have globally unique > >MsgIds is too restrictive to be acceptable, as some devices won't be > >able to generate them (and it puts restriction on > choreographies using > >such Ids). > > > > > >>Burdett: I've actually got a couple of specs that define > the above as > >>SOAP > headers. > >>Is anyone interested in taking them further ... to OASIS > perhaps ... > >>on a royalty free basis of course? > >> > >> > > > >Lafon: I would be interested to see them, why not involve > XMLP as well? > > > > > mm1: I believe, if only informally, this discussion has occurred in > XMLP. Dave, can you please re-address this with XMLP and let us > concentrate on what is our primary objective? Thanks. > > > > > > > > >
Received on Thursday, 7 August 2003 14:22:21 UTC