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:
OF474563F4.7948A2CD-ON80257703.002EFC85-80257703.003059EF@uk.ibm.com"
type="cite">
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
|