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: Fri, 15 May 2009 10:29:15 +0100
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]