RE: Body vs Header Correlation - which is best?

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 ...
>
>HEADER ONLY CORRELATION
>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.
>
>BODY ONLY CORRELATION
>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
>
>BODY WITH HEADER REFERENCES
>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
>
>BODY WITH HEADER COPY
>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
>
>BODY AND HEADER SEPARATE
>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>mailto:david.burdett@commerceone.com>; 
>Web: <<http://www.commerceone.com/>http://www.commerceone.com>
>