Re: The requirements on message 'correllation'

Let's say that we do not standardize which header is used to contain the 
instance identifier, but let the choreography specify it (we don't even 
specify what the content type is). Choreography A says it's header X, 
choreography B says it's header Y.

A service that participates in choreography A knows that the instance is 
contained in header X. It can put the instance there, it can read the 
instance from there. Whatever role that service plays in the 
choreography, it knows exactly what is required to maintain the 
conversation. So all the roles in choreography A would be able to 
interoperate with each other.

(Some restrictions would be required, e.g. on the size of the instance)

Similarly, all the services used in choreography B could interoperate 
with each other, even though they use a different header.

Of course, specifying one or more headers would be helpful as a 
guidance. We can recommend a standard header and call it <chor:instance> 
and say that the content is a UUID. That would provide a default option 
for many choreography specifications, but also allow other uses.

Since I don't see the interoperability problem, and I can imagine other 
uses of the instance identifier, I lean towards the more generic, 
flexible model, as seen for example in BPEL and WSCI. So my vote would 
be to look at similar mechanisms, possibly a combination of addressing 
and correlation sets to meet current and future requirements.

arkin


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 Thursday, 4 September 2003 22:40:24 UTC