RE: [TBTF] Binding Context

Hi Paul,

Some comments in-line.

Regards

Stuart

> -----Original Message-----
> From: Paul Denning [mailto:pauld@mitre.org]
> Sent: 31 July 2001 21:24
> To: xml-dist-app@w3.org
> Subject: [TBTF] Binding Context
> 
> 
> The abstract model discusses the concept of a binding context.
> 
> Has the TBTF made a conscious decision to avoid using this 
> concept in the TB framework?
> 
> The way RPC is defined now in Section 7 needs to be recast in 
> terms of a TB framework, rather than make explicit mention of the HTTP
binding.
> 
> "In the case of using HTTP as the protocol binding, an RPC 
> invocation maps naturally to an HTTP request and an RPC response maps to
an 
> HTTP response."
> 
> I suggest the TBTF try to reword this sentence from Section 7.  I think 
> this would help you validate the TB framework.

As an exercise this might be good idea, however the section 7 of the
document seems to fall more in the scope of the RPCTF than the TBTF for
developing spec. wording.

The presence of the sentence you reference and the one that follows it, ie.
"However, using SOAP for RPC is not limited to the HTTP protocol binding."
IMO both undermine the assertion at the start of the paragraph that "Using
SOAP for RPC is orthogonal to the SOAP protocol binding."

My initial inclination would be to delete both of these sentences and then
try to deal with what then seems to be missing... which seems to be any
narrative in relation to request/response correlation.

The question of rewording then hinges on whether the view is: a) that in all
cases (regardless of particular binding) the core of SOAP provides a message
correlation capability (may go unused) to the things that use SOAP, or b)
the means to provide message correlation is present in some bindings and not
in others, in which case the RPC conventions will have to take on
responsibility for the provision of a message corelation facility to cover
those cases where the binding does not.

Personally I favour a) ie. that core SOAP should always provide a means to
correlate messages (for those circumstances where corelation is required)
regardless of the natural capabilities of a specific underlying protocol and
binding.

Given that preference a tentative rewording might be:

"Using SOAP for RPC is orthogonal to the SOAP protocol binding (see section
6). SOAP and its binding to underlying protocols provides the means to
correlate RPC response messages with the corresponding RPC request message."

As the TBTF work forward it should be possible to be more specific about
such "means to correlate" messages.

Of course if the other view, b) above, is more prevalent then I think that
the RPCTF can really only work under the assumption of the absense of any
means of message corelation in the core of SOAP.

> For example, Applications sending an RPC request or response must indicate

> this fact in the binding context.

Given that binding context at present is an AM concept at present and we
could either return to the earlier notion of DATA and UNITDATA operations
(for request/response and one-way respectively) or stick with the current
notion of one-way plus causality/corelation then, request/response-ness is
signified either through use of the DATA operation and its attendant
primitives in the former case, or through the use of the 'Corelation'
parameter with the UNITDATA operation in the latter case.

Of course a different construction could collect operation primitives and
parameters into a binding context so that there is (conceptually) a single
structure carrying all the necessary message data and metadata to support
the exchange of a message (including particular phase within some enumerated
set of MEPs).

> Then, the binding can look at the binding context (bc) to help decide how 
> it should encapsulate the message.
> Binding specifications should describe what information it reads and
writes 
> from/to the binding context, and what decisions it makes based on the 
> binding context.

Agreed... at least that's a POV supported in the AM.


> Recall that the "ultimate SOAP receiver" is defined as "the SOAP receiver 
> that the initial sender specifies as the final destination of the SOAP 
> message within a SOAP message path".
> 
> Also (section 4.2.2) states "Both intermediaries as well as the ultimate 
> SOAP receiver are identified by a URI."
> 
> The bc would hold the URI of the ultimate SOAP receiver.  The binding
would 
> determine, based on other information in the bc, whether it uses this URI 
> for the next hop, or if the URI of an intermediary is used (and the
binding 
> inserts a SOAP header block to carry the URI of the ultimate 
> SOAP receiver).
> 
> Note that the bc is conceptual and SOAP implementations may provide their 
> own ways of passing the bc information.  I think the bc should be 
> formalized in the spec to provide a binding-independent way to describe a 
> processing model.

I think this is very close to the thinking a number of TBTF participants.

> The bc MUST be extensible so it can be used by extensions (e.g., to read 
> the capabilities of a binding, or to write information for consumption by 
> bindings, other extensions, or SOAP applications).

Again, at least as conceived within the AM, that indeed is the case.

> We need to allow a SOAP node to have multiple binding (e.g., HTTP, BEEP, 
> and SMTP).  Some information in the binding context would be used by the 
> SOAP node to select which binding to use (probably the URI).

Yep...


> If the URI of the ultimate SOAP receiver is a URN, e.g., 
> urn:least-latency-stock-quote, then another lookup would be needed to map 
> that URN to a specific URL.  Is this lookup function part of the 
> binding?  Is another "extension" needed to handle this scenario?

Personnally, I think that the selection of a particular binding for some
instance of communication is something that happens 'above' the bindings and
is based on local configuration/policy, the reachability of an immediate
destination and support for required QoS/MEPs offered by the locally
available bindings.

Conceptually, a function to resolve immediate destination URI to either
'unreachable' or 'transport endpoint address' for that particular binding is
something that binding may provide - although I could envisage some sort of
plug-in mechanism that allowed for multiple resolvers cf. gethostbyname().
Conceptually such a function could be invoked as part of the process of
determining which binding to make use of.

I don't think that this is an "extension".

> 
> Paul
>

Received on Wednesday, 1 August 2001 08:34:38 UTC