Re: The requirements on message 'correllation'

David,

 From reading this thread my understanding is that we're referring to 
the language level.  I would argue that a CDL with appropriate 
semantics need not specify the control-related content of messages.  In 
most cases, if you have this situation then you have an ambiguous 
program and you should fix it using simple language constructs rather 
than introducing an explict notion of correlation.  To use your 
example, the "original order" and "replacement order" should have 
distinguished names in the program, even if they transmit the same 
information, because they have significantly different semantics.  This 
unambiguously defines the semantics without constraining the binding to 
particular technologies.  Note that doing it at this level also makes 
it relatively easy for a compiler/verifier to detect and flag 
ambiguities.  This rule applies for any number of participants (not 
just a binary choreography) provided those participants are 
distinguished in the choreography definition: if they're not then you 
also have a problem with ambiguity in your program.

The only semantics I've struck that sometimes break this rule are 
quality-of-service constraints (e.g. acceptable packet loss on 
video/audio streams).  I haven't yet seen anything on this list 
suggesting these are being dealt with at a language level.

Ciao,

AndyB

On Thursday, September 4, 2003, at 09:34  AM, Burdett, David wrote:

>
> Here's my $0.02c ... I'll respond to all three emails in one ...
>
> TONY's ORIGINAL EMAIL
> Tony said that there are three basics (I'm simplyfing slightly)
> 1. Each message must identify it's target program/service, etc
> 2. Each message may identify the choreography type and choreography 
> instance
> 3. If a message specifies a choreography type is being followed, then 
> you
> must be able to identify a message as being part of an instance of that
> choreography type.
>
> Basically I agree but would clarify the third point to say that you 
> must be
> able to identify on a message *the individual interaction* within a
> choreography instance that the message represents. The point is that 
> you
> could have two messages which appear to be the same being sent within a
> choreography, however they have different purposes. For example you 
> might
> have an original order and a replacement order. If the payload in both
> instances is an order, then it might not be obvious which is which. If 
> you
> identify this at the message level then the problem goes away.
>
> JON'S REPLY
> The points Jon made were (again I'm simplifying so I hope I get the 
> jist of
> it right)
> 1. The CDL may not be used directly and only used, in effect, at 
> design time
> when the BPEL or other program definition was being developed.
> 2. In this case, identifying the choreography being followed is of no
> relevance.
> 3. Instead, the BPEL instances (or programs) must directly target their
> corresponding BPEL processes.
> 4. BPEL, through it's "correlation set" mechanism suggests an approach 
> to
> recording the choreography instance in a message
> 5. Given that approaches such as the one defined by BPEL exist, does 
> the
> choreography grup need to define one
>
> Firstly, I agree that if the CDL has been used at design time then 
> **if the
> BPEL process can only behave in one single deterministic way** then
> identifying the choreography being followed is not relevant. However 
> if the
> process can be involved in multiple different choreographies, which I
> believe will often be the case, then I think identifying the 
> choreography
> being followed becomes essential to avoid confusion.
>
> As an example you could have two separate choreographies:
> 1. Request a quote
> 2. Place an order
>
> You could then have a third choreography that combined these where you 
> are
> placing an order as a result of receiving a quote. In this case an 
> "Order"
> message might appear to be the same where you are just directly 
> "placing an
> order" but it actually isn't as really you are accepting a quote.
>
> So our choices are, I think:
> 1. Require that the choreography type is always identified in a message
> somehow
> 2. Make the choreography type conditional on whether or not the service
> which is receiving the message can take part in multiple 
> choreographies.
>
> Note that you might be able to determine the choreography type in 
> several
> different ways such as: an identifier for the choreography type in a 
> SOAP
> header, or by, in the example above, the existence of a "QuoteID" 
> field in
> the order document.
>
> THE LARGER QUESTION
> So I suppose the larger question in all of this is which of the 
> following
> options should we follow:
> 1. Allow multiple different ways on how to do correlation, specify
> choreography types, identify choreograpy instances, and identify 
> messages
> (interactions) within a choreography without specifying any of them, or
> 2. Specify one definitive way of doing some or all of these, or
> 3. Specify "a" definitive way but allow that approach to evolve over 
> time as
> standards are developed and improved, or
> 4. Specifying a "recommended" way of doing each of these, but a) not 
> require
> that they are used, and b) providing guidelines on when and where they
> should be used.
>
> As anyone on the call earlier today will realize, I don't like the 
> first
> option as it means you don't get a CDL that is usable and 
> interoperable. As
> a result WS-I will probably, at some point down the road, solve the 
> problem.
>
> I also don't think that the second option works as how correlation and
> choreography types etc, are done will probably evolve over time.
>
> To handle the third option effectively you would need to specify the
> definitive way in a separate section (or spec) so that it can be 
> separately
> evolved over time which is probably a good idea anyway.
>
> This leaves the last option, which specifies a recommended way 
> together with
> guidelines (I'd prefer rules) on when it has to be used.
>
> INTERNAL VS EXTERNAL CORRELATION
> The BPEL spec that Jon refers to, also describes the idea of a 
> correlation
> set and also a mechanism for pointing into a the body of a document 
> (e.g. an
> order) to identify the correlation information.
>
> I don't think that this is so simple ... I'll send a separate email to 
> the
> list on the topic.
>
> And finally FRED's EMAIL
> Fred said ... correlation does not matter as long as the exchange is 
> between
> two participants.
>
> Not sure about this. I think this is only true if: a) the two 
> participants
> have only one way of interacting, and b) their interactions are single
> threaded. If you have two different ways of interaction, then you need 
> to
> identify the choreography type otherwise the recipient of a message 
> will not
> know how to respond, and if you have two choreography instances going 
> on at
> the same time, then you need to know which instance any given message
> belongs to otherwise you might route a messge internally to the wrong 
> place.
>
> ... my $0.02c
>
> David
>
>
>
> -----Original Message-----
> From: Cummins, Fred A [mailto:fred.cummins@eds.com]
> Sent: Wednesday, September 03, 2003 1:30 PM
> To: jdart@tibco.com; Fletcher, Tony
> Cc: public-ws-chor@w3.org
> Subject: RE: The requirements on message 'correllation'
>
>
>
> I believe that specification of correlation in the
> choreography does not matter as long as the exchange is
> between two participants--the choreography describes
> a single thread of exchanges.  I think it may matter when
> the choreography is a composite of concurrent
> exchanges between multiple participants and there
> must be a definition of correlation between the binary
> exchanges.  This correlation, however, may only be
> required to link the specifications and might be
> independent of the correlation mechanism in the
> run-time messages.
>
> Fred
>
>> -----Original Message-----
>> From: Jon Dart [mailto:jdart@tibco.com]
>> Sent: Wednesday, September 03, 2003 1:43 PM
>> To: Fletcher, Tony
>> Cc: public-ws-chor@w3.org
>> Subject: Re: The requirements on message 'correllation'
>>
>>
>>
>> Fletcher, Tony wrote:
>>> But picking up an argument that I think it was Frank made,
>> it may often be the case that the systems are not
>> programmatically aware that they are following a choreography
>> instance.  Suppose that a description of choreography is
>> agreed amongst some cooperating parties using our CDL.  Each
>> party then implements using BPEL as an intermediate step (or
>> directly using a programming language).  When this
>> choreography is followed the systems are in fact following an
>> unfolding instance of the choreography, but they are also
>> following an unfolding instance of interacting BPEL instances
>> (or programme instances) and it is these that the messages
>> will need to directly identify and target.
>>
>> A point briefly made in the conf call was that what we are
>> building (the
>> CDL) possibly isn't really describing the implementation
>> layer through
>> which messages are actually interchanged. If it's at a sufficiently
>> abstract level, then it doesn't matter how correlation is
>> accomplished.
>>
>> Now, I understand that it is also envisioned to have a binding
>> technology through which the choreography can be associated with
>> specific message formats. But again, the question is, do you need to
>> specify how correlation is accomplished at the CDL level. Or is the
>> binding still abstract in this sense?
>>
>> If the participants are using BPEL as their implementation, then they
>> have a correlation mechanism available
>> (http://www-106.ibm.com/developerworks/library/ws-bpel/#messag
> ecorrelation).
>
> If they're using something else, then they likely need a corresponding
> standard.
>
> However, the issue then is, do we need to specify what that is? Or in
> fact, as Yaron was saying, do we actively not want to specify the
> correlation mechanism, to avoid precluding use of existing/emerging
> standards?
>
> I understand the concern about interop but if we are not going to the
> level of laying out the full semantics of the implemenation (as BPEL
> does) then interop isn't really an issue, it seems to me.
>
> Btw. I am not sure punting this issue to WSA is going to really help.
> The WSA doc says right at the start that "The architecture does not
> attempt to specify how Web services are implemented, and imposes no
> restriction on how services might be combined". Which is not to say 
> they
> can't discuss the issue, but specifying an implementation is not in
> scope for them (IMO).
>
> --Jon
>

Received on Monday, 8 September 2003 09:18:46 UTC