W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

[TBTF] Binding Context

From: Paul Denning <pauld@mitre.org>
Date: Tue, 31 Jul 2001 16:24:03 -0400
Message-Id: <5.1.0.14.0.20010731130309.00a04790@mailsrv1.mitre.org>
To: xml-dist-app@w3.org
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.

For example,  Applications sending an RPC request or response must indicate 
this fact in the binding context.

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.

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.

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

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

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?

Paul
Received on Tuesday, 31 July 2001 16:25:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT