Re: comments on 30/3/2001 AM draft

Ray,

Yes, I think that this is precisely what is missing. There's
a bit more to it, though. From an application POV, the boundary
between the application/handler and the XMLP AM layer needs to
be able to indicate that it is blocking for a response. This could be
achieved with the same response-required property. Depending
upon the protocol used, the XMLP layer will of necessity need to 
(somehow) correlate the response received with the request
so that it can return the response to the application. That is
all well and good.

On the receiving end of things it gets a little more complicated.
Let's just take the binding of HTTP into consideration, since as I
understand that is all that will be formally addressed.

XMLP bound to HTTP can be effected in at least two ways:
	- messages travel on the HTTP POST and the response
	code is indicative of the status of the processing of the
	request. A 200 means okeydokey, anything else would
	likely be accompanied by a SOAP Fault message (although
	this is by no means a guaranteed association)
	- messages that are being sent in response to a previous
	message are sent on an HTTP POST in a similar manner
	to an endpoint URL that the responding application
	knows of by some means that the application layer employs.
	Some causality/correlary semantic extension is needed
	to enable the original sender to associate the response
	with the original request

- or -
	- messages travel on the HTTP POST and response messages are
	returned on the HTTP 200 response. The message correlary
	is implicit in this usage model.

Thus, there needs to be some indication of the binding protocol
usage model (oneway or r/r) communicated with the HTTP POST to indicate
to the
binding layer as well as to the XMLP and application layers
how to respond. With r/r layered over oneway messaging, a response could
be processed
in due course. When the other end is blocking for a response, the
receiving end hasn't the same luxury. From the receiving application's 
point of view, either use case could be handled by the very same code,
but the XMLP layer, responsible for dispatching the messages
for processing will need to do things differently as will the
binding layer.

Cheers,

Chris

Ray Denenberg wrote:
> 
<snip/>
> 
> 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
>