OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Simon Holdsworth wrote:
> 
> 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).
> 
If the reference multiplicity is 1..1, this is correct.

> 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.
> 
This doesn't completely invalidate scenario R3.  It just requires
the client to use a 1..n reference instead of a 1..1 reference, and
define multiple <binding.ws> elements for the different SOAP versions
it is willing to use.  If the service provides endpoints for more than
one of these SOAP versions, the client will have more than one proxy
injected and it can choose between the proxies in any way that it likes.
In Java, it might choose the first proxy in the array or collection.

However, this scenario has made me think we have a problem with the
the current proposal for BINDINGS-23.  This says that the SCA runtime
MUST raise an error if it does not support the reference binding's
WSDL port or WSDL binding.  This does not seem correct if the reference
has multiplicity 1..n.  For example, the reference might have
multiplicity 1..n with two bindings: B1 with a SOAP.1_1 intent and
B2 with a SOAP.1_2 intent.  If the SCA runtime only supports SOAP 1.1,
I think this should not cause an error but result in a single proxy
for B1 being injected into the reference.

There's another similar scenario where the right answer is less clear.
The current proposal for BINDINGS-23 says that the binding MUST satisfy
all the policy constraints of the SCA reference.  I think this is correct
as far as it goes, but it does not cover the case of the binding element
having policy constraints that go beyond the policy constraints of the
reference.  For example, the reference might specify a SOAP intent and
have multiplicity 1..n with two bindings: B1 with a SOAP.1_1 intent and
B2 with a SOAP.1_2 intent.  If B2's WSDL port or WSDL binding can't
satisfy the SOAP.1_2 intent, and B1 is fine, we need to decide whether
  a) this should raise an error, or
  b) B2 should be ignored, with a single proxy for B1 injected into
     the reference

   Simon

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