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



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.

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








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