Re: Body vs Header Correlation - which is best?

David,

I would cc the bepl list just yet. They are not the only ones looking 
at correlation. I think we need to get a bit further down the track and 
then decide how best to handle the issue.

We might decide we can do it all.
We might decide to be more abstract and pass requirements down to 
another W3C group.
We might find that W3C has no group looking at the problem in the way 
that we require it to
be looked at.

It's too much in the air just yet. I think a concise requirement of set 
of them on this topic, with use cases in support, would do much to help 
focus us on the issues at hand and from there to the solutions.

I think what you have written is a good start on the solutions space 
and I can certainly imagine some use cases in support of the various 
options.

Just my hasty (on the train comments) ;-)

Cheers

Steve t

On Thursday, September 4, 2003, at 01:18  am, 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
> <mailto:david.burdett@commerceone.com> >; Web: < 
> http://www.commerceone.com
> <http://www.commerceone.com/> >
>
>
>

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.

Received on Thursday, 4 September 2003 07:26:33 UTC