Re: comments on 30/3/2001 AM draft

"Williams, Stuart" wrote:

> Maybe we should return the term Causality which is what I called it
> originally the concept. It's primary purpose is to denote a given message
> having arisen as a direct consequence of the processing of another message.

Well now I see that "causality" doesn't mean what I thought (my fault, since
"causality" is as good a term as any "to denote a given message having arisen as
a direct consequence of the processing of another message" ).

But I think that there is a very important property of request/response that I'm
not sure is being modeled (and which I had thought was being addressed under the
name of "causality):
the notion that a given request requires a response.    (If this is indeed
covered, my apologies, but I can't see it.)

(I think the reason I got confused is that we were talking about correlation,
then this property was briefly introduced -- by Noah -- and William appeared to
address it under the name of causality.)

I envision the abstract model to support the ability of its user (the user of
the model, that is) to define application protocols that sit on top of the XMLP
service represented by an abstract state machine where request/response patterns
are modelled something like this:
The XMLP state machine for the XMLP processor for the sender application,
initially in the open state, recieves a request from the XMLP requesting
application, sends an XMLP message to the peer XMLP state machine, goes into the
pending state, and stays there until it gets a responding XMLP message, and
issues a confirm to the XMLP requesting application (and goes into a terminal
state or back to open).

At the peer (responder) the XMLP state machine, initially in the open state,
recieves a protocol messages, issues an indication to the XMLP Responder, goes
into the pending state and stays there until it receives a response, then sends
a protocol message to the requesting XMLP processor (then goes into a terminal
or open state).

Certainly you can do this with UnitData (I've already argued that it's much
easier with request/response primitives, but apparently I'm in the minority)
but not simply with a correlation or causality parameter (and I'm not sure that
the causality parameter is particularly meaningful).  I think you need to add
something like a "response-required" parameter.


--Ray




--
Ray Denenberg
Library of Congress
rden@loc.gov
202-707-5795