- From: Paul Denning <pauld@mitre.org>
- Date: Tue, 31 Jul 2001 16:24:03 -0400
- 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 UTC