Re: [sca-bindings] Re: BINDINGS-73

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Simon,

Please see comments on R3 inlined below

Simon Nash <oasis@cjnash.com> wrote on 15/05/2009
12:26:57:
>
> Simon,
> This scenario-based approach is very helpful.  I have some comments
> on R3 inline below.
> 
>    Simon
> 
> Simon Holdsworth wrote:
> > 
> > So here's the set of scenarios I can think of, assuming qualified
> > intents are exclusive and require support limited to a single
SOAP 
> > version, and no default.  I think all scenarios are catered
for, so I 
> > don't see any reason to change this behaviour, unless the way
that the 
> > scenarios are realized is unacceptable.
> > 
> > Overall question, given that the set of SOAP versions is open-ended,
is 
> > there a guaranteed way to be able to look at a namespace and
know "this 
> > is SOAP of some version" ?  Or do you have to have
a set of known SOAP 
> > namespaces to compare against?
> > 
> > Scenarios for a service:
> > 
> > S1) I want to expose a SOAP endpoint but I'm not immediately
fussed 
> > about the SOAP version, although that may then be specified by
the 
> > wsdlElement if present.
> > 
> > Use SOAP intent on the service binding
> > 
> > a) if I point at a SOAP binding/port of any version using the
> > wsdlElement attribute then that version of SOAP is supported
by the 
> > endpoint. I think this should be exclusive and no other versions
> > supported by the endpoint.
> > b) if I don't point at a SOAP binding/port using the wsdlElement
> > attribute, then any number of any versions of SOAP may be supported
by 
> > the endpoint.  In this case a single binding.ws could result
in multiple 
> > WSDL binding elements to describe it.  In all the other
cases I believe 
> > there is a 1-1 correspondance between WSDL and SCA bindings for
the service
> > 
> > S2) I want to expose a SOAP endpoint and it has to support a
single 
> > specific SOAP version.
> > 
> > Use a qualified SOAP intent (SOAP.1_1 or SOAP.1_2) on the service
binding
> > 
> > a) if I point at a SOAP binding/port using the wsdlElement then
it must 
> > match the specific SOAP version, if not its an error.
> > b) if I don't point at a SOAP binding/port using the wsdlElement
> > attribute, then only the specified version of SOAP is supported
by the 
> > endpoint.
> > 
> > S3) I want to expose a SOAP endpoint that must support more than
one 
> > specific SOAP version.
> > 
> > This cannot be done with a single binding.ws element.
> > Have one binding.ws for each required SOAP version following
S2) above. 
> > Runtimes may to allow each binding.ws to be exposed at the same
endpoint 
> > address, but I don't think that's necessary for all SCA runtimes.
> > 
> > S4) I want to expose a SOAP endpoint that must at least support
a 
> > specific SOAP version, but is allowed to support other SOAP versions.
> > 
> > This cannot be done with a single binding.ws element.
> > Use two binding.ws, following S1b) and S2) above.
> > 
> > S5) I want to expose a web service endpoint, and have the binding
> > details taken from what the wsdlElement points at, whatever that
is.
> > 
> > Use no SOAP intent on the service binding.
> > 
> > For a reference:
> > 
> > R1) I want to invoke a service using SOAP, with the specific
SOAP 
> > version resolved by choice of port from the wsdlElement.
> > 
> > Use SOAP intent on the reference binding.
> > 
> > When determining the set of available WSDL ports, only those
that 
> > support SOAP (of any version) and satisfy the other binding policy
> > requirements are included.
> > 
> > R2) I want to invoke a service using a specific SOAP version.
> > 
> > Use a qualified SOAP intent (SOAP.1_1 or SOAP.1_2) on the reference
binding
> > 
> > When determining the set of available WSDL ports, only those
that 
> > support SOAP of the specified version and satisfy the other binding
> > policy requirements are included.
> > 
> > R3) I want to invoke a service using any of a given set of SOAP
versions.
> > 
> > This cannot be done with a single binding.ws element.
> > Have one binding.ws for each required SOAP version following
R2) above.
> > 
> The words "any of a given set" and "required SOAP version"
don't
> seem consistent. 

The intention of this wording was to say that the
requirement is to be able to invoke the service using one of a set of specific
SOAP versions, e.g. pick one of SOAP 1.1 and SOAP 1.2.  

Having said that I don't think this is valid but not
particularly compelling scenario.

> I think the scenario is that the client wants
> to use (for example) either 1_1 or 1_2 and requires the service
> to provide at least one of these.  Using the approach you are
> suggesting, the service would need to make endpoints available for
> both 1_1 and 1_2 so that both of the <binding.ws> elements on
the
> reference are valid.  If the service only had (for example) a
> 1_1 endpoint, the client's 1_2 reference binding couldn't be
> satisfied and the client deployment would fail.

I imagined that this would be a subset of the set
of versions of SOAP provided by the service - otherwise of course this
won't work as you say.

> A further inconvenience is that the client implementation would
> need to provide a reference with multiplicity 1..n and the
> application code would receive an array of reference proxies,
> one for each available SOAP version.  The choice between these
> would need to be made by business logic instead of being left
> to the SCA runtime.

I'm not sure I follow that.  Does a reference
have to have multiplicity 1..n to have multiple valid bindings?  What
would go wrong if the multiplicity is 1..1 and there are multiple bindings
that satisfy the constraints?

>    Simon
> 
> > R4) I want to invoke a service using any port that my runtime
can support.
> > 
> > Use no SOAP intent on the reference binding.
> > 
> > When determining the set of available WSDL ports, all that satisfy
the 
> > binding policy requirements are included.
> > 
> > Regards, Simon
> > 
> > Simon Holdsworth
> > STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings
TC Chair
> > MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
> > Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
> > Internet - Simon_Holdsworth@uk.ibm.com
> > 
> > 
> > *Simon Nash <oasis@cjnash.com>*
> > 
> > 14/05/2009 20:22
> > 
> >    
> > To
> >    Eric Johnson <eric@tibco.com>
> > cc
> >    David Booz <booz@us.ibm.com>, sca-bindings@lists.oasis-open.org
> > Subject
> >    [sca-bindings] Re: BINDINGS-73 (was: Suggested wording
for POLICY-83)
> > 
> > 
> >    
> > 
> > 
> > 
> > 
> > 
> > I updated the subject line, as this is now a BINDINGS-73 discussion.
> > 
> > Eric has presented some important use cases for preserving the
current
> > rules in the WS Binding spec.  In addition, I think the
following
> > should be allowed:
> > 
> >  1. A service with the unqualified SOAP intent, exposed
using a
> >     SOAP 1.2 WSDL binding or WSDL port (specified via
@wsdlElement).
> > 
> >  2. A reference with the unqualified SOAP intent that uses
a
> >     SOAP 1.2 WSDL binding or WSDL port (specified via
@wsdlElement).
> > 
> >   Simon
> > 
> > Eric Johnson wrote:
> >  > Ugh.
> >  >
> >  > I find myself confused by the entire thread.  To
clarify, here are the
> >  > scenarios I care about:
> >  >
> >  > Here's my simple notion:  I put binding.ws on
a *service*, with a SOAP
> >  > intent - not further qualified.
> >  >
> >  > I want it to be possible for the conforming SCA runtime
to expose BOTH a
> >  > SOAP 1.1 and SOAP 1.2 endpoint at the same URI.  That
is, I want to
> >  > follow in the useful pattern of "being lenient
in what I accept, and
> >  > strict in what I produce."
> >  >
> >  > For the reference case, when putting a binding.ws
on a *reference*, with
> >  > a SOAP intent - again, not further qualified - and
then pointing at a
> >  > WSDL service element, and it contains ports with different
versions of
> >  > SOAP supported, can the conforming SCA runtime choose
any of those
> >  > ports?  There may be orthogonal concerns (security),
which will
> >  > discriminate amongst the available ports, and being
forced to use SOAP
> >  > 1.1 as the default arbitrarily over-constrains the
solution, possibly to
> >  > the point of error.
> >  >
> >  > Based on Dave's last response, neither of the above
scenarios is the
> >  > same as "resolving the intent to a binding"
based on the the default
> >  > qualifier, at least not if an SCA runtime MUST use
the default qualifier.
> >  >
> >  > -Eric.
> >  >
> >  > Simon Nash wrote:
> >  >> Dave,
> >  >> Thanks, this helps.  I understand your interpretation
of what the
> >  >> unqualified SOAP intent means now.  Let's
continue this discussion
> >  >> in the Bindings TC under BINDINGS-73.
> >  >>
> >  >>   Simon
> >  >>
> >  >> David Booz wrote:
> >  >>> ...sigh...
> >  >>>
> >  >>> "If the intent is attached in an unqualified
form then any version of
> >  >>> SOAP is acceptable."
> >  >>>
> >  >>> That statement is simply repeating the meaning
of an unqualified but
> >  >>> qualifiable intent, i.e. it can always be
further qualified by
> >  >>> another part of the composite. What does the
SOAP intent mean to an
> >  >>> assembler that finds it on a service or reference
element? It means
> >  >>> that he must find a binding that can provide
SOAP. Any version of
> >  >>> SOAP is fine because the developer did not
constrain it. The
> >  >>> assembler may have to add the 1_2 qualifier
if that's what he wants
> >  >>> to provide. If he says nothing, the FW will
handle resolving the
> >  >>> intent to a binding (or policySet) based on
the default qualifier.
> >  >>>
> >  >>> Dave Booz
> >  >>> STSM, BPM and SCA Architecture
> >  >>> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> >  >>> "Distributed objects first, then world
hunger"
> >  >>> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> >  >>> e-mail:booz@us.ibm.com
> >  >>>
> >  >>> Inactive hide details for Simon Nash ---05/14/2009
10:31:14
> >  >>> AM---Dave, Here is an extract from the Policy
spec CD02 rev1:Simon
> >  >>> Nash ---05/14/2009 10:31:14 AM---Dave, Here
is an extract from the
> >  >>> Policy spec CD02 rev1:
> >  >
> >  >
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS
TC that
> > generates this mail.  Follow this link to all your TCs in
OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > 
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > /
> > /
> > 
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales
with number 
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU/
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS
at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU