RE: The requirements on message 'correllation'

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