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 16:12:50 UTC