RE: [TBTF] Binding Context

Hi Paul:

Just a quick note to say your text below feels right on.  And while I agree
very much with your direction here, and the goals of the "binding context"
in the AM, I would actually argue against using that term for the "abstract
data collection" we've been talking about in the TBTF, since it is as
possible to use these data items in any other extension as it is in a
binding in particular.  In fact you mention this directly below.

I'd suggest something like "message context" instead.  Other than that, I
think we're on the same page.

--Glen

> -----Original Message-----
> From: Paul Denning [mailto:pauld@mitre.org]
> Sent: Tuesday, July 31, 2001 4:24 PM
> 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.
> 
> 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 Wednesday, 1 August 2001 15:55:28 UTC