Correlation Requirements

A very good point Martin - I was presuming "a" solution which is perhaps
premature.

So let's do this the "right" way and think about it in terms of requirements
so here's my $0.02c on what they might be ...

Requirement 1
If a message is being sent between roles as part of the "performance" of a
choreography, then that message MUST identify the "choreography instance" to
which it belongs

Requirement 2
A choreography instance MAY be identified by specifying a unique identifier
in "metadata" (e.g. a SOAP header) associated with the message.

Requirement 3
A choreography instance MAY be identified by referencing a combination of
one or items of data in the "payload(s)" (e.g. the SOAP body and/or
attachments) of the message.

To make these complete, we should also define, roles, performance,
choreography instance, metadata and payload, but that can come later!

Thoughts?

David


-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Thursday, August 07, 2003 11:23 AM
To: 'Burdett, David'; 'Monica Martin'; 'Yves Lafon'
Cc: jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A';
public-ws-chor@w3.org
Subject: RE: Off topic but relevant


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