Re: Correlation [was: Transaction IDs]

Please see my comments below.

Cheers,

Chris

Noah_Mendelsohn@lotus.com wrote:
> 
> 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.

Only if the "request" and "response" are directly related and tightly
bound to the transport (e.g. in an RPC-style exchange over a synchronous
channel such as HTTP that is not multiplexed for performance optimization) 
and only if there will not be some subsequent message(s) that relate.

For instance, I could send a message that is being acknowledged but
whose response will be sent separately, either via another exchange,
such as in a "polling" model, or as a separate asynchronous message
sent from the original recipient (or possibly elsewhere).

Consider the use case of ordering books or CDs from Amazon.com or some other
site. You get a response to the transaction via HTTP (on the response)
as well as an email confirming the order. Certainly, the messages are
related. If I've only one order outstanding, it is pretty straightforward
to relate the messages. If I have multiple orders, this becomes a little
more challenging

Consider also that the original message is responded with a confirmation,
but that the shipping service provider (e.g. FedEx) sends a message
indicating that the shipment has been confirmed as well.

> 
> 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.

Peter Deutsch's "8 falacies of distributed computing" come to mind,
the first of which is: 
	"the network is reliable"

Note that small devices are more likely than not to involve less reliable
networks (who among us has not had our cellphone drop its connection
between cells?) and would probably benefit from some manner of correlation
identification scheme. The services they target would more 
often than not need to have properties of idempotency.

Hence the need for some reliability features built into the protocol
of processing a block with a CorrelationId (or MessageId as in ebXML).

> 
> 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.

Binding to the transport is certainly possible in some cases, but 
not in all. IMHO, it should be carefully considered before use.

I agree with David that there needs to be a standardization of a correlation
block so that we don't wind up with a proliferation of semantically
equivalent solutions that might possibly result in interference
and redundancy (e.g. when because of the usage a message needs to 
incorporate more than one).

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

Received on Friday, 23 March 2001 12:26:48 UTC