RE: MOAP v2

In order to make progress on the MOAP proposal, I like to suggest that we open a separate issue for discussing the use of nested or operation level policies; those policy aspects could be safely peeled off from the MOAP proposal and discussed as a separate issue.

If we agree to do that, we can accept the MOAP proposal with the following changes:


*       Example 9-1. Remove line 17.

*       Remove the sentences
"The Policy Assertion on line 17 indicates that the nested policy assertions apply to the WS-Eventing operations. For example, if line 17 includes some security related assertions then the WS-Eventing operations would need to be secured using those security mechanisms.

When Feature Policy Assertions contain nested Policy Assertions (as show above in line 17), those assertions have Endpoint Policy Subject and apply to all message exchanges related to the feature."

*       Make the following change - remove the phrase shown in strikethrough:
"/mex:MetadataExchange/xs:any

This extensibility point allows for additional WS-MetadataExchange specific metadata to be included within the policy assertion - e.g. WS-MetadataExchange WSDL, or nested policy assertions related to the WS-MetadataExchange message exchanges."

*       The changes to section 12 (suggested in the attached thread).

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Ram Jeyaraman
Sent: Monday, March 01, 2010 7:19 PM
To: Doug Davis; public-ws-resource-access@w3.org
Subject: RE: MOAP v2

On the question about the use of nested policy assertions we had discussed during the previous WG call, here are my thoughts:


*       Defining nested policies using the extension point in a parent policy doesn't work because extensions are ignorable whereas nested policy assertions (and the associated semantics) are not ignorable.

*       The policy attachment point is at the endpoint level.

o   When policies are defined at the endpoint level, the policy intersection algorithm allows matching the capabilities (of the client and the endpoint) and allows the client to engage the right behavior. That is, in Example 9-1, the security policy assertion and the EventSource policy assertions can be defined as siblings; this ensures that the client will use the right intersection of these policies to engage with the endpoint. The policies apply to all the operations supported by the endpoint.

*       Operation is not an attachment point for policies

o   If the intent in Example 9-1 is to describe operation level policies, that is, application of policies scoped to a specific operation, it cannot be supported using the general policy mechanism, since it does not allow operation as an attachment point for policies.

*       If the intent is NOT to define a nested policy assertion (as Ashok described earlier), then it can be done using a policy parameter (of the parent policy) that wraps the collection of inner policies.

Thanks.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, February 23, 2010 11:45 AM
To: public-ws-resource-access@w3.org
Subject: MOAP v2


All,
  after several rounds of talks between Oracle, Microsoft and IBM, the latest version of MOAP can be found here: http://www.w3.org/2002/ws/ra/10/02/MOAPv2.zip

The zip file contains all proposed spec changes and the changes include:

WS-EVD: no changes since last time

WS-Eventing/Enum/Frag/Transfer - look for edits done by "Dugv5":
- Only minor wordsmithing/editing to the definitions of the assertions

WS-MEX:
- there are two MEX docs in the zip file.
- the v1 version is the one sent to the WG a few weeks ago - no new edits were made.
- the v6 version contains all of the edits since v1.  All v1 edits were "accepted" so it should be easy to see the diff from v1.
- the edits were done in stages so that's why you'll see several Dugv? names.  It wasn't until round 4 of edits that I remembered to change the user name.

The MEX edits include:
- lots of minor editorial tweaks
- there's a new Terminology section.  This was added because it was felt that the two roles ('service endpoint' and 'metadata resource') needed to be defined and clarified.  People should read/review this carefully.
- the assertion was modified to advertise whether GetMetadata is supported - and the Dialect/Content params are now under GetMetadataSupported.
- there's a new section 12 about Bootstrapping.  This section was added to pretty much put all of the various pieces of the puzzle together when trying to bootstrap the process of talking to an endpoint.
- updated the xsd/wsdl for GetWSDL

Note: I'm planning on moving section 5 before section 4.  This will make it so that we define the new mex:Metadata type before we use it.  I didn't move it in the doc because then it would show up as modified.

Outstanding MEX issues for the WG to discuss:
- Example 8-5 - see comments in the doc
- Example 12-1 - see comment in the doc

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.