RE: [TBTF] Binding Context

Hi Chris,

A few comments below.

BR

Stuart

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 01 August 2001 16:15
> To: xml-dist-app@w3.org
> Subject: Re: [TBTF] Binding Context
> 
> 
> Stuart,
> 
> Please see my comments below.
> 
> Cheers,
> 
> Chris
> 
> "Williams, Stuart" wrote:
> <snip/>
> > 
> > > -----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
> > >
> > >

<snip/>

> > >
> > > I suggest the TBTF try to reword this sentence from Section 7.  I
think
> > > this would help you validate the TB framework.

<snip/>

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

Certainly.

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

Firstly I'm cool with an extension such a [1]  that may well meet a large
proportion of the 'corelation' needs of a range of applications/usage
scenarios (I need to read [1] through properly). I'd be concerned if across
a bunch of application domains we found ourselves redefining essentially the
same mechanisms, but RPC has to take on the defn of corelation because it
cannot be confident that the core of SOAP will provide it; ditto for
Transactions; ditto for Conversations;... I'd hope that some common
functionality could be factored out.

If these is some base level functionality that folks can be assured of as
being present (however provided), then that base may be sufficient for many
usages and could be augmented in those cases that need more functionality.

<snip/>

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

I don't think we disagree.

<snip/>

> > >
> > > Paul
> > >
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0260.html
> [2] http://ebxml.org/specs/ebMS.pdf
> [3] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
>

Received on Friday, 3 August 2001 06:56:07 UTC