sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Comments on proposed resolution to BINDINGS-126
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
- Date: Thu, 15 Apr 2010 10:13:56 +0100
Eric,
I'm not sure that there is a problem
here.
For a service or a reference using binding.ws,
we can require support for policySets that use the WS-Policy language.
Once we have such a requirement, then
it seems natural to also say that if a particular policySet is attached
to a given
binding.ws element, then the WS-Policy
statements in that policySet must be applied to the service or reference
concerned.
In the case of both services and references
which also reference an existing WSDL, then there is the possibility that
the
WSDL also contains WS-Policy assertions
and we need to describe how the two sets of WS-Policy assertions are
handled. For the merge process
we can say one of the following:
a) the assertions are simply added
b) assertions from the policySets override
any from the WSDL
a) gives the possibility of having conflicting
assertions (eg use encryption type A vs use encryption type B)
b) potentially gives more control to
the Assembler/Deployer (ie, use the WSDL with its policy assertions, but
if these turn
out not to be appropriate, then override
them with new assertions supplied from a policySet)
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| Eric Johnson <eric@tibco.com>
|
To:
| Mike Edwards/UK/IBM@IBMGB
|
Cc:
| OASIS Bindings <sca-bindings@lists.oasis-open.org>
|
Date:
| 15/04/2010 00:50
|
Subject:
| Re: [sca-bindings] Comments on proposed
resolution to BINDINGS-126 |
Hi Mike,
You get at precisely one of the points that worries me. You indicate
that you wouldn't put policy information into the WSDL - except in the
use case of a fully adorned WSDL. Which strikes me that you would
treat services and references differently.
I agree, for a reference deployer would use policy statements in the WSDL.
For a service, I see the exact reverse possibility, where the deployer
would need to discard the statements in the WSDL in preference to the policy
intents and policy sets defined for the SCA domain (perhaps they got the
WSDL from an existing service that they're moving into SCA, for example).
There are three places I can see us mandating support of WS-Policy:
- In generated WSDL
- In WSDL elements referenced by wsdlElement - for bindings
on a service
- In WSDL elements referenced by wsdlElement - for bindings
on a reference
I can live with mandating support
for WS-Policy when it appears in WSDLs used by references. For services,
I don't know what it means to mandate it, because I can imagine all sorts
of reasons to trump it/ignore it. In the generated WSDL, you could
"require" it, but if we don't have any particular mapping of
intents or policy sets, all you can test for is the existence of a policy
wrapper element. If it is empty, because of the specific configuration
of a particular service, then do we require that the policy wrapper element
be there?
At least as far as the generated WSDL, we could add a "SHOULD"
statement suggesting that WS-Policy statements be included, but I don't
see how you go further than that.
-Eric.
On 04/12/2010 01:48 AM, Mike Edwards wrote:
Folks,
Comments inline.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
I think we should kick this over to the policy TC.
<mje>
I disagree. It is not the place of the policy TC to mandate use of
WS-Policy, since that
may well not be appropriate for specific bindings. Meanwhile WS-Policy
is certainly
relevant to binding.ws
</mje>
Assembly says that you must support policy and binding.ws, and it doesn't
make sense to me that the binding.ws spec should be dictating that WS-Policy
is supported, since anyone reading the SCA-Policy spec would expect to
find that mandate in that spec. If the Policy TC hasn't mandated
this up until now, it doesn't make sense to me that the bindings TC should
jump in - and I'd sure like to know why the Policy TC hasn't mandated it,
if that question has come up.
<mje>
See above paragraph
</mje>
Feels to me like the policy TC should be dealing with some of the issues
we identified on the call, and that Simon notes below:
- If we don't require support for any specific WS-Policy
assertion, how do we test?
- How do we reconcile WS-Policy statements that we do find,
and potential conflict with stated intents?
- (and one I've just thought of) Are the requirements different
depending on whether the binding is on a service or a reference?
<mje>
The testing question is a good one. We can certainly test that an
SCA runtime handles WS-Policy constructs
without causing errors. Specific Policy assertions are a different
issue - we dont mandate support for any specific
assertions and so as a result, I don't see how we can test for them.
Regarding intents, there is no conflict. All that intents do are
to make statements of requirements. Intents get satisfied
in one of 2 ways: a) by the binding type inherently understanding
them (the SOAP intents are probably of this kind for
binding.ws b) by one or more policySet attached to the relevant
SCA element (either directly or via external attach).
In the first case, it is entirely up to the binding implementation to decide
how it is satisfying the intent - but that IF there is
some WS-Policy statement from some other source (eg in a WSDL) the implementation
must determine if there is a conflict
and if so, it must raise an error. For the second case, the policySet
may make have some policy assertions that conflict
with other policy assertions that come from another source such as a supplied
WSDL. Again, if there is a conflict (eg
"use encryption type X" versus "use encryption type
Y") then the SCA runtime must raise an error.
As to whether requirements are different for a reference versus for a service,
I think the answer is "no"
</mje>
The problem seems different depending on whether you're defining a binding
on a service or a reference.
- On a reference, a human has to verify that the relevant
intents match the details of the specific binding.
- On a service, mostly these details will be discarded,
won't they? If not, what does it mean to have policy information
in three places - intents, policySets, and in the WSDL? Who wins?
Is it even a contest?
Although I've not thought
about it too hard, I can't see that anything except the intervention of
a human can resolve the potential discrepancies between policy intents
and actual WS-Policy statements found in a WSDL. At that point, some
poor administrator/deployer has to look at the WSDL component pointed at
by wsdlElement, look at the policy intents, and look at any policySets
that have been applied to satisfy that intent, and then that admin will
typically(?) discard the WS-Policy information in the WSDL component.
So then what's the point of having WS-Policy statements in the referenced
WSDL? I'd actually go the other direction, if we were to state anything
normative, and suggest that an SCA Runtime MAY discard any WS-Policy statements
found in the WSDL pointed at by wsdlElement. That would make more
sense to the deployer.
<mje>
Well, I can agree that having policy statements in multiple places is not
a good plan.
Personally, I would not put such statements into the WSDL.
However, there is one clear use case I can think of - the use of a "fully
adorned" WSDL on a reference, where the WSDL
has simply been picked up from the (external) service targeted by the reference.
Discarding any WS-Policy statements
in there would not be very helpful since then the deployer would have to
tweak the policySet(s) applied to the reference
to produce the same overall policy configuration.
</mje>
All of the above circles around a question for me - do we collectively
have enough understanding of implementation considerations to know what
should be normatively asserted?
I should add, I'm not trying to play the role of wet blanket. I suspect
most, or even all implementations, if/when they support any sort of policy
on the wsdlElement target, or expose policy in generated WSDL, will use
WS-Policy, because there aren't really any alternatives. I just don't
know the details of how they'll support it. Normative requirements
here remind me of a tar pit.
-Eric.
On 04/09/2010 03:00 AM, Simon Holdsworth wrote:
Mike,
Here's my comments on the proposal that's in JIRA:
> A binding.ws implementation MUST support the WS-Policy specification
and MUST:
"MUST support the WS-Policy specification" seems a bit vague
to me - isn't that what the following list defines in more detail?
Also, I don't think we've used "binding.ws implementation" anywhere
in normative statements, to be consistent this would be "SCA runtime"
> a) accept WS-Policy statement in any supplied WSDLs
Basically I believe what we are saying here is that an SCA runtime MUST
not reject a WSDL simply because it includes WS-Policy statements, which
is perhaps somewhat different to "accept"ing WS-Policy statements.
> b) advertise any policies applied to a service using the WS-Policy
language
Would the default WSDL generation rules be impacted by this? Are
we saying that all policies that are applied to be a service MUST be represented
as WS-Policy statements in the WSDL, or are we saying that IF there are
any policy statements in the WSDL, they must at least be expressed using
WS-Policy? I'm not sure how we could check that any WSDL extensibility
elements present in other namespaces are policy-related rather than anything
else.
> c) accept WS-Policy statements in SCA policySets
As above
> d) use the WS-Policy policy intersection rules when matching
policies between a reference and a service
[BWS20038]
I think more discussion is needed around what happens with the combination
of WS-Policy statements in the WSDL referred to by a binding.ws and the
SCA policy sets. From the Web Service binding spec:
"If the binding is for an SCA reference, the set of available ports
for the reference consists of the ports in the WSDL service that have portTypes
which are compatible supersets of the SCA reference as defined in the SCA
Assembly Model specification [SCA-Assembly] and satisfy all the policy
constraints of the binding."
Does this issue affect the definition of the "set of available ports"?
Would they need to satisfy all the policy constraints of the binding
as well as all the policy constraints described in the WSDL?
Regards, Simon
Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
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
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
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
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]