Re: Correlation [was: Transaction IDs]

The possible objection to correlation IDs, which I believe has been 
previously raised, is that 

1) you need to figure out how transport bindings fit in.  When I send a 
request/response over http, I generally relay on HTTP itself to correlate 
the response with the request.  In that case, putting ID's in the envelope 
itself is possible excess baggage.

2) Depending on how stable your notion is of 
session/conversation/connection or the like, there is a modest concern 
about whether small devices are in a position to generate useful 
correlation IDs.   Over what period do they need to be unique?  If I've 
sent a request over SMTP, is there a risk I would get a stray response 6 
months later? (I just got some email re-delivered from a broken email 
system, 6 months late!)  I admit this 2nd concern is less well justified 
and less compelling.

I think that we will have many constructs, and correlation is one, where 
we probably want an approach that says:  "you can do this in a 
binding-specific manner;  when the binding can't do it, there is a 
standard way to do it in the envelope (possibly as a module);  we need to 
work out how a message transitions from a transport that provides its own 
ids, to one that uses the standard representation in the envelope.  In 
general, I don't thing that originators of messages can or should know 
anything other than the original transport they use for transmisison. What 
happens to the message after that should be largely opaque, I think.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Thursday, 22 March 2001 19:48:21 UTC