RE: Correlation Requirements

>>>I believe that the final reality will be something like 95% of services 
are *not* choreography aware.

Maybe, but my guess is that if the service is part of a commerce-related
co-operation between businesses, then 95% of those services *will* have to
be choreography aware. For example we have identified 14 different ways (ie
choreographies) which are used by businesses today to just place an order.
If you don't know the choreography being followed then the parties involved
won't know what they are (or are not) allowed to do.

David

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
Sent: Friday, September 05, 2003 12:42 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


Comments inline:
On Wednesday, September 3, 2003, at 05:34  PM, Burdett, David wrote:

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

I believe that the final reality will be something like 95% of services 
are *not* choreography aware.

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

I don't see this.

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

This is a dangerous precedent. You are ceding the choreography to BPEL, 
losing before you have started.

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

Sorry, this misses the point. I think *you* seem to be perilously close 
to the business flow POV.

A given service will have its *way* of doing things. That may, or may 
not be, fully described in a choreography document. There may even be a 
set of services that you want to coordinate in a particular fashion to 
achieve a particular goal (e.g., the warehouse, credit card, delivery 
services combine to deliver a book.) Each of these (say) does its thing 
in a rich way, and *I* want to document how to use them to achieve the 
book delivery service - I should be able to do that in a CDL without 
impacting any of the existing services. A corollary of that is that 
there may be no way of determining what choreography a given message is 
part of (by looking at the messages), it is simply an interpretation of 
the CDL.

(I.e., in logic-speak, the potential message sequences represents an 
interpretation of the CDL formula, and that the CDL formula is 
satisfied by a given message sequence.)

Frank





>
> 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 Friday, 5 September 2003 17:43:57 UTC