W3C home > Mailing lists > Public > public-ws-chor@w3.org > September 2003

Re: Body vs Header Correlation - which is best?

From: Andrew Berry <andyb@whyanbeel.net>
Date: Tue, 9 Sep 2003 00:03:30 +1000
Cc: "Burdett, David" <david.burdett@commerceone.com>, "'Ugo Corda'" <UCorda@SeeBeyond.com>, "WS Choreography (E-mail)" <public-ws-chor@w3.org>
To: Ricky Ho <riho@cisco.com>
Message-Id: <39B76F45-E205-11D7-9356-0003936786BC@whyanbeel.net>

Perhaps we can ground this discussion by thinking about how a 
choreography would
be implemented.  As I see it, we have three possible approaches to

1. Have choreography-aware services.  If you're building on top of 
    standards, then I believe this means that correlation information 
belongs in
    the message body and is interpreted by the services.  This approach 
    that only choreography-aware applications can participate but does 
    building on top of existing standards.

2. Use a choreography-aware "proxy" that interprets choreography 
information and
    invokes appropriate choreography-oblivious services to realise the
    choreography semantics.  This proxy could use either header (assuming
    extensible headers) or body information, although body information 
would need
    to be stripped before passing onwards.  I suspect this is where the 
    of David's thoughts lie.

3. Use a choreography-aware infrastructure with services built/generated
    explicitly for that infrastructure.  In this case, correlation 
belongs in the
    message header and would typically be interpreted by an engine/proxy 
    behalf of the services (this is the approach I use in my work).

The second and possibly the first are required for compatibility with 
service infrastructures.  I believe the latter is our future.  I don't 
think we
should be excluding any.  Given this and other discussion, I don't 
think that
the CDL should specify how correlation is achieved: it belongs in the 



On Sunday, September 7, 2003, at 02:34  PM, Ricky Ho wrote:

> In BPEL, there is no where in the incoming message indicating where to 
> locate the correlation information.  If the process instance 
> specifying the <correlation> in its <receive> activity, then the BPEL 
> engine will be able to know where to look for the correlation 
> information according to the <correlationSet> definition in the 
> containing <scope>.
> Rgds, Ricky
> At 11:54 AM 9/4/2003 -0700, Burdett, David wrote:
> Ugo
> Thanks for the clarification. What you are saying is that BPEL allows 
> correlation to be done in multiple different ways. This in turn means 
> that in each BPEL definition you need to specify how it is going to be 
> done. You could also have multiple different ways being used in the 
> same BPEL definition or between partners.
> Is this right?
> I will also include this in a later version of my note once we have 
> more feedback.
> Finally, do you think there is any benefit in having a standard way of 
> doing the "header only correlation" if you want to do it.
> David
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Wednesday, September 03, 2003 8:23 PM
> To: Burdett, David; WS Choreography (E-mail)
> Subject: RE: Body vs Header Correlation - which is best?
> David,
> I don't think the BPEL correlation mechanism corresponds to your "body 
> with header references" case.
> Assuming a SOAP binding is used, and depending on the particular SOAP 
> binding chosen, BPEL correlation sets could correspond to "header only 
> correlation", or "body only correlation", or a combination of the two. 
> This is because a BPEL correlation set is a collection of Properties 
> (globally unique names) which are individually mapped to WSDL message 
> parts. In the case of SOAP binding, each one of those WSDL parts could 
> end up either in the SOAP header or in the SOAP body, depending on how 
> the binding is defined.
> Ugo
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Wednesday, September 03, 2003 5:18 PM
> To: WS Choreography (E-mail)
> Subject: Body vs Header Correlation - which is best?
> We've been talking about whether or not we should specify how to do 
> correlation, so I thought it would be a good idea to suggest some 
> alternative ways of doing correlation together with their "pros and 
> cons" so that we can, hopefully, make some type of objective decision 
> on what, if anything, to do.
> Note that this problem does not apply just to correllation, but also 
> how you identify the choreography type being performed, and the 
> specific message (interaction) within a choreography type that a 
> message represents - although I don't always mention this specifically 
> in the descriptions below.
> So here are the five options I've thought of ...
> Put the correlation, choreography type, etc, in a header on the 
> message (e.g. a SOAP header)
> Advantages:
> 1. Independent of the payload - works with any message format
> 2. Works with message payloads that do not contain any data that can 
> be used for correlation, etc
> 3. Independent of the application that is processing the payload
> 4. Simple correlation mechanism
> Disadvantages:
> 1. If there is data in the payload that can also be used, then it 
> might be inconsistent
> 2. Correlations might not be simple if there are many overlapping 
> threads.
> Use information for correlation, choreography type, etc. contained in 
> the body of a message, e.g. an order Id in an order document.
> Advantages:
> 1. Re-uses "real" often, business derived, data.
> 2. No duplication or inconsistency possible
> Disadvantages:
> 1. Requires that the content and structure of the payload is 
> understood before correlation, etc. can be done or checked
> 2. Ties correlation to a particular message format - means generalized 
> correlation mechanisms can't be used
> 3. Requires the application does the correlation, choreography type 
> checking etc, instead of payload-independent middleware doing instead
> Use information in the body (as in Body Only Correlation) but also 
> provide "pointers" of some kind in a header (e.g. a SOAP header) which 
> points to the where within the body the correlation information is 
> contained. This is, I believe, the BPEL suggested approach.
> Advantages:
> 1. Potential for a generalized approach - payload-independent software 
> can follow the references to find the data being referenced
> 2. Removes the need for the application to do correlation
> Disadvantages:
> 1. The different types and formats of the data being referenced and 
> the payloads being used will significantly adds to the complexity of 
> following message paths.
> 2. Probably restricted to XML payloads. For example if the payload was 
> a PDF file then this would not work (no flames please for not 
> requiring use of XML ! )
> 3. Possible performance problems - especially if the message payloads 
> are large.
> 4. Only works if the message is not encrypted. If the payload is 
> encrypted then it might not be possible to resolve the reference
> Use information in the body (as in Body Only Correlation) but this 
> time *copy* the information from the body into a SOAP header.
> Advantages:
> 1. Independent of the message format
> 2. Removes the need for the application to do the correlation
> 3. No performance problems as payload does not need to be examined
> 4. The payload can be encrypted and only the data required for 
> correlation copied to the header.
> Disadvantage:
> 1. Probably need to map the payload data (e.g. integer) to a standard 
> external one in the header (e.g. string)
> 2. Duplicate data with potential for inconsistencies between the body 
> and header versions of the correlation data
> Use information in the body, but with separate, independently created, 
> correlation, etc id's in the header
> Advantages:
> 1. Independent of the message format
> 2. No need for the application to do the correlation
> 3. No need to map between body and header formats
> 4. Same approach whether or not the body contains data that can be 
> used for correlation
> 5. Header correlation information need bear no resemblance to the 
> payload equivalent which may be encrypted
> 6. No performance problems as payload does not need to be examined
> Disadvantages:
> 1. Potential for inconsistencies between the header and body 
> mechanisms for correlation
> 2. Does correlation twice in two different ways - in the header AND in 
> the body.
> I hope I've thought of all the options - are there any more?
> I also hope I've covered all the advantages/disadvantages fairly - any 
> comments?
> Now which is aprpoach is "best"? One of them? Some of them? All of 
> them !!!
> Thoughts anyone ... I'll save mine for later ...
> David
> PS Should I copy this to the BPEL list?
> Director, Standards Strategy
> Commerce One
> 4440 Rosewood Drive, Pleasanton, CA 94588, USA
> Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> <mailto:david.burdett@commerceone.com>; Web: 
> <http://www.commerceone.com>
Received on Monday, 8 September 2003 10:06:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:12 UTC