RE: Correlation parameter in an XMLP Block

Hi Paul,

Thanks for your comments. A few responses below.

> -----Original Message-----
> From: Paul Denning [mailto:pauld@mitre.org]
> Sent: 30 March 2001 23:43
> To: xml-dist-app@w3.org
> Subject: Correlation parameter in an XMLP Block
> 
> 
> I've been thinking about Marwan's question of why the concept 
> of causality is needed.
> 
> Its clear to me that it is needed, its just a matter of where 
> you put it.
> 
> The XMLP Layer does not need it.
> 
> If the correlation id is passed down to the XMLP as a parameter of the 
> XMLP_UnitData.send, what is the XMLP Layer supposed to do with it?
> If it goes into an XMLP Block, then it should be the XMLP Module that 
> constructs the Block (containing the correlation id).  The XMLP Layer does

> not look at or process the Block (or does it?)

Firstly, to the best of my knowledge the term 'correlation id' appears
nowhere in the AM document, nor does the AM document discuss or mandate the
use of any  XMLP Block for the purposes of deriving a correlation between
mechanisms - it remains totally silent about mechanism.

The Correlation.MessageRef parameter in the service primitives of the AM
document

.send:	The message being sent is a direct consequence 
		of the processing of the message referenced by 
		MessageRef, a locally significant and abstract
		reference to a message previously *received* by 
		the sender of the current message.

.receive	The message being received is a direct conseqence
		of the processing of the message referenced by
		MessageRef, a locally significant and abstract
		reference to a message previously *send* or *forwarded*
		by the receiver of the current message.

In a *practical* (rather than abstract) interface there would be a means to
manage the lifetime of local message references... at some point the sender
of a message would cease to be interested in correlated (or causal) messages
in response to a given message.

The means by which the XMLP layer (and below) derive the correlation is not
part of the abstract model - although there are a number of plausible
alternatives.
 
> If RPC is a module, and RPC requires causality and a correlation id, then 
> an XMLP Block seems like the logical place to put the correlation id.

The SOAP 1.1 RPC mechanism depends upon causality to match RPC response with
RPC request, can you point at a SOAP header element in the SOAP
specification that provides that functionality?

> The XMLP Layer needs to provide a conduit for the upper layer modules to 
> provide information to the lower layer bindings; otherwise, how would the 
> lower layer binding (e.g., for HTTP) know when to send an HTTP response
and 
> what should go in it?

To answer the last point first, XMLP and the lower layers would know to send
an HTTP response because the responding application would mark the message
it is currently sending as being causally dependent on the message that
arrived in the corresponding HTTP request by making a reference to the
earlier message in the Correlation.MessageRef parameter.

Another part of the 'conduit' between XMLP layer/bindings and XMLP
application is the BindingContext which is a 'rag-bag' for getting
information between the lower layers and the application such as
UserId/Password, Certificates and keys for say lower-level SSL connections
and other idiosyncracies. The BindingContext may also influence the choice
of binding used by a sender in the case where there are multiple choices.


> The "conduit" is something currently missing from the AM.  We need the 
> concept of a "Context", which can be defined as the runtime relationship 
> between the XMLP Layer, the underlying bindings, and the upper layer
modules.

Take a look at BindingContext... does it differ significantly from your
concept of a 'conduit'?

> Discussion?

Certainly!

> 
> Paul

Best regards

Stuart

Received on Monday, 2 April 2001 05:58:08 UTC