RE: Correlation Requirements

Frank

I agree that not all existing servics will be "choreography aware" and that
we should still be able to use them.

However I think this really comes down to what is the basic difference
between a (business) process and a choreography.

If you are invoking an existing web service as part of a business process
(e.g. defined using BPEL) then identifying the choreography is not needed as
the business process is in complete control and knows what messages can come
back and take the appropriate action.

On the other hand, if there is no single process in control, then you need
to have some agreed definition - the CDL - which both processes agree to
follow.

So in the latter case you either:
1. Need to always use the same choreography - in which identifying it
becomes unnecessary, or
2. Recognize that there are multiple choreographies that can be used
therefore identifying which one becomes essential.

I reckon that existing services will either be invoked by a single process,
or are always used in the same way in which case working with them is not, I
think, a problem.

Hope this helps.

David

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
Sent: Tuesday, August 26, 2003 7:15 PM
To: Burdett, David
Cc: 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com;
'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
Subject: Re: Correlation Requirements



This message may be moot, but please bear with me:)

RE: Requirement 1

I think that there may well be cases where a service agent is 
participating in a choreography without it knowing! Consider legacy 
systems (and yes, even tomorrow's fully choreographed systems will 
legacy the day after) that are built today without the benefit of a 
CDL. We will want to be able to hook in such a service in with other 
services that *do* support our CDL; but a requirement that every 
message be decorated with a means of identifying the choreography 
instance will *not* be possible for a service that does not know about 
choreographies (it is just doing its thing)

Frank

On Friday, August 8, 2003, at 07:15  AM, Burdett, David wrote:

> 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 Wednesday, 3 September 2003 20:34:21 UTC