Re: Correlation Requirements

David:
   The perils of examples is that they are insufficiently abstract, and 
therefore people will abstract them differently. When I quoted the book 
shipping example, I should have noted that all the operators (CC, 
Warehouse, and delivery agent) might be under different ownership and 
therefore orchestration was not feasible.
   I would say that, in a world not dominated by a single player, 
coordinating services that are owned by different people requires a 
choreography-based not an orchestration-based approach. For this v. 
simple reason: I may not trust you sufficiently to let you run my 
business, and there is no third party that we both trust sufficiently. 
(Besides, if I am responsible for a service, I want to control it too.)
Frank


On Friday, September 5, 2003, at 02:43  PM, Burdett, David wrote:

>>>> 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 Monday, 8 September 2003 15:43:38 UTC