Re: Body vs Header Correlation - which is best?

 From the outside, but with my SOAP 1.2 hat on, I'd say go for a 
feature, i.e. SOAP header block, if this is at all possible. There is 
potential that your correlation header gets reused by other 
applications/specifications, and the only real way to achieve this is to 
use a SOAP header. This would also give you two extra advantages:

1) Ability to later delegate correlation processing to a separate 
intermediary (if that makes sense).

2) Ability to easily upgrade the correlation header in the future (new 
namespace, mustUnderstand).

Burdett, David wrote:

> 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>; Web: <http://www.commerceone.com 
> <http://www.commerceone.com/>>
> 
>

Received on Thursday, 4 September 2003 05:44:10 UTC