Re: Correlation Requirements

Struggling to keep up with the volume of email in this group, but ...

I wanted to bring in comments from previous threads about a choreography
defining a graph of events (message sends/receives).  Assuming this is 
the case,
I'd make a few observations:

1. A choreography definition implicitly defines the relationships 
between those
    events, both direct and "chained"

2. A "performance" of a choreography is required to implement those
    relationships

3. While performances require correlation information in messages, the
    specification should not need explicit correlation information 
*unless* there
    is ambiguity in the graph definition

Hence, my inclination would be to make the requirement(s) something 
like:

1. It must be possible to infer correlation between events from a 
choreography
    definition

2. If the choreography definition language permits ambiguity in 
identifying a
    "causing" event, the language should also permit the use of event 
identifiers
    to resolve ambiguity

In other words, if/when there is ambiguity, the correlation identifiers 
can be
explicitly specified.  Please replace "event" with an alternate term if
I've missed an important glossary term.

With reference to the discussion about composition and referencing other
choreographies, I would say that composition at the choreography 
definition
level results in a new choreography, hence the above applies equally 
well.

I'm not yet convinced that composition of choreographies at a 
performance
(execution) level is valid although I am happy to hear arguments.  I 
think the
coordination of multiple "sessions" by a service participating in 
multiple
concurrent choreographies is the responsibility of the service and its
underlying service-provision protocols.

Ciao,

AndyB

On Monday, August 11, 2003, at 03:46  PM, Keith Swenson wrote:

> I would like to understand why it is important to leave so many 
> different ways of carrying correlation information.  Our job is to 
> produce a specification that will ensure interoperability.  If there 
> are an infinite number of ways to communicate correlation information, 
> then we haven't really specified anything, have we? 
>  
> The reason I am probing this is because I want to understand what is 
> the underlying "requirement" that we avoid being prescriptive.  It 
> clearly would be a benefit to the entire industry if we could stick 
> with your requirements 1 & 2, except change 2 to specify exactly which 
> header field MUST contain the choreography instance id.  Why is it 
> that "you don't want to have to be forced to use an identifier in the 
> header."?  Seems to me that the effort and cost to put this in a 
> consistent place would be far less effort and cost that would be 
> incurred by coding all the various point-to-point variations due to 
> each implementation using a different way of coding correlation 
> information.
>  
> -Keith Swenson
>
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Thursday, August 07, 2003 3:15 PM
> To: 'Monica Martin'; Burdett, David
> Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; 
> 'Cummins Fred A'; public-ws-chor@w3.org
> Subject: RE: Correlation Requirements
>
> Monica
>
> The reason I included requirements 2 and 3 is that they reflect two 
> use cases ...
>
> If we assume that there has to be some data in the message that can be 
> used for correlation when the message is taking part in a choreography 
> then requirement 2 arises becaus it is possible that there is no data 
> in the payload (or anywhere else) that can be used for correlation 
> purposes.
>
> Requirement 3 arises because there maybe data that can be used in the 
> payload and therefore you don't want to have to be forced to use an 
> identifier in the header.
>
> However, I can also see your point that the existing requirement 
> definitions could be a bit too presrcriptive, so how about these as 
> alternatives, I've added a fourth requirement which hopefully makes it 
> clearer. The complete set is as follows ...
>
> Requirement 1 (not changed)
> 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 (changed)
> A choreography instance MUST be identified by specifying a separate 
> identifier associated with the payloads in the message where there is 
> no combination of data in the "payload(s)" that can be used to 
> uniquely identify the choreography instance that is being performed.
>
> Requirement 3 (changed)
> A choreography instance MAY be identified by referencing a combination 
> of one or more items of data in the "payload(s)" of the message where 
> that combination of data can be used to uniquely identify the 
> choreography instance that is being performed.
>
> Requirement 4 (new)
> A choreography  instance MAY be identified by specifying a separate 
> identifier associated with payload(s) in the message even if there is 
> a combination of data in the "payload(s)" that can be used to uniquely 
> identify the choreography instance that is being performed.
>
> David
> -----Original Message-----
> From: Monica Martin [mailto:monica.martin@sun.com]
> Sent: Thursday, August 07, 2003 3:03 PM
> To: Burdett, David
> Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda';
> 'Cummins Fred A'; public-ws-chor@w3.org
> Subject: Re: Correlation Requirements
>
>
> Burdett, David wrote:
>
> > 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.
> >
> mm1: I would suggest on Reqt 2 and 3 that we specify the requirement 
> not
> the solution, of which these requirements appear to do both. 
> Particularly, a choreography instance may be referenced, - do we 
> specify
> how?
>
> > To make these complete, we should also define, roles, performance,
> > choreography instance, metadata and payload, but that can come later!
> >
> > Thoughts?
> >
> > David
> >
>

Received on Sunday, 17 August 2003 08:48:39 UTC