RE: comments on 30/3/2001 AM draft

Chris, Ray,

Apologies that this thread has layen fallow for a while... I've been away...

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 03 April 2001 21:01
> To: rden@loc.gov
> Cc: xml-dist-app@w3.org
> Subject: 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.

By "receiving end" I take you to be refering to the end that receives a
'request' and generates a 'response'.

> XMLP bound to HTTP can be effected in at least two ways:
> 	- messages travel on the HTTP POST and the response
       ^^^request messages
> 	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

Certainly plausible and i think would require the existence of some
syntactic artifact within the message or message wrapping (eg. some
extension header to http) to enable the neccessary correlation. However,
this does not appear to be the way that a typical (application) 'request'
and (application) 'response' messages are corellated 

[(application) because some regard the request-ness or response-ness of a
SOAP message to be application semantic and not intrinsic to SOAP - from [1]
"SOAP messages are fundamentally one-way transmissions from a sender to a
receiver, but as illustrated above, SOAP messages are often combined to
implement patterns such as request/response."]


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

This does seem to be the typical way in which (application) 'request' and
'response' messages are correlated in SOAP today. It is this that motivated
the DATA operation in the earlier AM drafts. Indeed I would almost take the
view that this is the primitive mode of exchange that SOAP provides and that
(single-direction) one-way messaging can be derived by the sending of an
empty 'response'. However, there seems (to me) to be a contradiction between
the apparent behaviour of SOAP when bound to HTTP and the sentence quoted
above at [1].

The request-response DATA operation was introduced to cover what seems (to
me) to be the intrinsic behaviour of SOAP as it is today; The one-way
UNITDATA operation was introduced to cover what seems (to me) to be the
'aspirational' behaviour of SOAP expressed in the sentence at [1].

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

There seems to me to be at least two philosophical points-of-view that you
can take:

1) The request-ness and response-ness (or other exchange pattern-ness) of
message are an application (or XMLP layer service user) semantic. The
'application' making the request knows implitly that it is making a request
and that it expects a response. Likewise the 'application' receiving the
request implicitly knows that a response is required. The XMLP layer itself
knows nothing of the 'request-ness' or 'response-ness' of the messages. This
tends toward a one-way message view of the world which then leaves two
options: either the 'application' needs to look after matching requests and
responses for itself by means of artifacts placed in the message; or there
may be some means where the 'causality' of messages may be abstracted at the
interface to the XMLP layer so that knowledge that a message received is a
direct consequence of a message send may be presented to the 'application'
to aid in correlation internally re-create a DATA abstraction from the
UNITDATA (with causality/corelation) operation along the following lines:

At request sender:

  DATA.request(To=responder, Message=req) -> 

    UNITDATA.send(To=responder, Msg=reqSent, Causality=null);

    When UNITDATA.receive(From=from, Msg=respRcvd, Causality.MsgRef=msgRef) 
       && (msgRef == &reqSent) Do
       DATA.confirm(From=from, Msg=resp);

At request receiver:

  UNITDATA.receive(From=requestor, Msg=reqRcvd, Causality=null) ->

    DATA.indication(From=requestor, Msg=reqRcvd)

    When DATA.response(Msg=respSent) Do
      UNITDATA.send(To=requestor, Msg=respSent, Casuality.MsgRef=&reqRcvd)

Here 'When' is intended as a one-shot. Also, at the receiver, determining
whether a received message requires a response may require more
sophisticated delving into the message content.

2) The XMLP layer itself needs to be made aware of the request-ness,
response-ness or one-way-ness of the messages it carries. This was the view
supported in eariler AM docs that presented DATA and UNITDATA operations.
The distinction between needing or not needing a response is made at the
originating 'applcation' through the choice of operation. This carries
'knowledge' of the exchange-pattern into the XMLP layer. In the case of the
XMLP/HTTP the difference between UNITDATA and DATA operations could be
through the use of distinct HTTP operations eg. PUT and POST respectively.

In the long run adding new MEPs means adding new operations (abstractions of
the service interface for these MEPs). This would implicitly inform the XMLP
layer and potentially the bindings of the MEP required for a given exchange.

Here both the 'application' and the 'XMLP layer' are explictly aware of the
MEP being used and act accordingly.

In response to Ray's point:

> > 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 you are right and I would be happy to think about how we work this
in.

> > 
> > (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.)
         ^^^^^it's Stuart... our Exchange Server insists on sending out our
names backward!

Should be we return to calling this causality to avoid confusion with other
potential uses of the term corelation? 

> Cheers,
> 
> Chris

Best Regards

Stuart
[1] http://www.w3.org/TR/SOAP/#_Toc478383491

<NoMoreFromMeBelow/>

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

Received on Wednesday, 25 April 2001 07:36:31 UTC