I think we should kick this over to the policy TC.
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.
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?
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.
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:
OFAC419DB3.3211F703-ON80257700.00353383-80257700.003663F3@uk.ibm.com"
type="cite">
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
|