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] Comments on proposed resolution to BINDINGS-126


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








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