Assaf:
> The question is, can we assume we're always going to use a standardized
> mechanism, and can we agree on which mechanism it is?*
This question realy relates to do we assume that web services that
participate in a web service choreography require a specific software layer.
If yes, then it probably would not be too hard to deal with correlation at
the protocol level. On the contrary, if we assume that any services could
participate in a choreography, we would then need ad hoc correlation
mechanisms.
I guess we should have a requirement around that topic as well.
JJ-
>
> arkin
>
>
> Burdett, David wrote:
>
> > JJ
> > I agree with you that correlation is not a topic we have discussed. I,
> > like you prefer a choreography instance id as it simplifies the
> > choreography definition and is indpendent of the detail of the message
> > content. However it does mean that there can then be inconsistencies
> > between the choreography instance id and some id inside the message
> > content e.g. an order no.
> > David
> >
> > -----Original Message-----
> > *From:* Jean-Jacques Dubray [mailto:jjd@eigner.com]
> > *Sent:* Monday, June 09, 2003 2:22 AM
> > *To:* 'Burdett, David'; 'Yaron Y. Goland'; 'WS Chor Public'
> > *Subject:* RE: Requirements: Decision Points Requirement Proposals
> >
> > "The WS-Chor choreography definition MUST provide mechanisms by
> > which the execution of one choreography definition is dependent on
> > the execution of the instance of some other choreography
> > definition". The use case for this is where you want to execute a
> > choreography that determines the current state of processing of
> > some earlier choreography. The "query" choreography can only
> > validly be executed if there is some earlier instance of the a
> > choreography that can be referenced.
> >
> > */[JJ] I would treat the â€œquery/adminâ€