Re: [TBTF] Binding Context


Please see my comments below.



"Williams, Stuart" wrote:
> > -----Original Message-----
> > From: Paul Denning []
> > Sent: 31 July 2001 21:24
> > To:
> > 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.

Here's where it gets tricky;-) We could specify a correlation mechanism
as part of the core SOAP spec, such as the one I proposed in [1]. However, 
it cannot be perceived as exclusive of other equally valid approaches/mechanisms
such as the correlation provided for in the ebXML Message Service specification [2]
or that provided in SOAP-RP [3].

We could attempt to concoct a framework for correlation, possibly building 
on [1] that could be extended for the likes of [2] and [3], but then 
one has to ask how it is that the parties to an exchange requiring correlation
can agree as to a shared understanding of its nature based solely upon
the currently specified extension capabilities of SOAP (mustUnderstand)
which only requires that the QName of the header block be "understood".

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

Hmmm... if we assume that the core SOAP specification cannot provide
an exclusive correlation mechanism, and if we characterize SOAP RPC
as an "application framework" of the core SOAP protocol, then we can place the
responsibility of providing the correlation on the RPC implementation
to provide the REQUIRED correlation, either as a natural consequence of the
SOAP protocol binding as in the case of SOAP over HTTP as described in 
section 7, or as an extension such as that described in [1].

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

Hmmm... this depends upon your perspective of a binding. I could have
a binding to a logical transfer that is in fact a peice of software that
will select a specific transport (and binding) based on information in the
BC (or as some have described it as the message infoset and more recently
the message metadata (so as mot to confuse with the XML infoset which
may only be a subset of the total metadata...)

> 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 11:14:44 UTC