sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Re: BINDINGS-73
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Mon, 18 May 2009 10:02:43 +0100
Simon,
Adding my comments at the top....
I'm concerned about the scenario where
there are multiple bindings with a reference with 1..1 multiplicity. My
assumption had been that in this case the bindings were considered equal
alternatives and one would be chosen by the runtime - this is obviously
not true.
My understanding of what you're saying
is that having one reference binding.ws which points at a WSDL service
with multiple available ports (all can be valid, one gets picked) is NOT
the same has having multiple binding.ws which point at each individual
port in the same service (only one is allowed to be valid).
For references to non-SCA services,
there's no wiring to subset the bindings, so it seems that in this case
you can't have multiple binding elements that can satisfy the policies
on a 1..1 reference, which invalidates scenario R3. In that case
with the current rules for defaults and exclusivity, R3 is not permitted.
I don't personally see that as sufficiently important to want to
change the rules for the intent.
Simon Nash <oasis@cjnash.com> wrote on 15/05/2009
16:52:10:
> Simon,
> See responses inline below.
>
> Simon
>
> Simon Holdsworth wrote:
> >
> > 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.
> >
> OK, I understand this now.
>
> > > 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?
> >
> This is defined by the Assembly spec in sections 4.3.1 and 4.3.1.1.
>
> Section 4.3.1 gives various ways of defining target services for
> a reference. Points 2 and 3 in the numbered list relate to
> specifying targets using binding elements in the reference.
> My reading of this is that there will be one target service for
> each binding element that satisfies either point 2 or point 3.
>
> Section 4.3.1.1 gives the rules for matching target services
> (as defined in section 4.3.1) to reference multiplicity. If
there
> are two bindings that produce target services and the reference
> has multiplicity 1..1, this is an error.
>
> Simon
>
> > > 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/
> >
> >
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]