Re: [soa-rm-ra] reading WS-Policy: first observation

I'm not sure what you mean by "transitive binary" but if it's what I think you mean, I think it is transitive in the wrong direction! I'll get to that below.

So I've read through the Primer, WS Policy - Framework, WS Policy - Attachment.

From Primer, I struck by

It is important to understand that a policy is a useful piece of metadata in machine-readable form that enables tooling, yet is not required for a successful Web service interaction. Why? Web service developers could use the documentation, talk to the service providers, or look at message traces to infer these conditions for an interaction. Developers continue to have these options, as they always had.

Well, this is true but seems like a difference in "just" WS or whether you really have what SOA-RM defined as SOA.

Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.

My initial response was this only works for service policies but not the consumer policies, i.e. there will likely be other metadata repositories for resources that may include but not be limited to services. Then I read the Attachment spec and see someone has found an inventive marketing ploy to take a service registry people don't want and make it into a policy registry too. But more on that later too.

Back to transitive binary, I am assuming you are referring to the service, endpoint, operation, and message policy subjects and how policies for each of these components flow to the others. The Attachment spec covers WSDL 1.1 and 2.0 but the 2.0 diagram (Figure 5-1) is a good summary. The problem is that policies do not flow up to the service but rather down to the different message types. So if a consumer is looking for a service that is compatible with their policies (and this obvious case is noted in the specs), the consumer has to follow all the way down to the individual messages to sort this out. What does it mean for service discovery? Note, the Introduction section of the Framework specifically says it

does not cover discovery of policy, policy scopes and subjects, or their respective attachment mechanisms

and neither does the Attachment spec's discussion for UDDI. This is particularly a mess if the process model (by which the steps/actions for a service's business function are defined) refers to actions that do not individually make sense to the consumer outside the context of the RWE the consumer wants. So it appears the consumer would have to identify the business function needed and for each possible service would have to trace all actions in the relevant process model and then come up with the effective policy. Now we hope this is automated but it is starting to look like a real mess.

So for the RA, do we define policy at the service level to be the (automated) roll up to effective policy from all the required actions? What is the interaction scenario that effectively uses such a view?

Finally, back to making UDDI into a policy registry. The Attachment process seems to provide a way to register policies but you can only attach these to the businessEntity, the businessService, and the Endpoint (i.e. bindingTemplate and tModel combination). It doesn't support a roll up similar to what is defined for WSDL. So given a service, I not only have to roll up the messages but then need to combine whatever is defined in the other UDDI layers. And while this provides a path for businesses to register as providers, can we really expect to expand UDDI to register all potential consumers? Where do the consumers register and declare their policies?

Just realized I still need to read the Guidelines for Assertion Authors, so I'll send this as the next pass for continuing discussion.

On Jul 3, 2007, at 12:43 PM, Duane Nickull wrote:

Because the Policy attachments are transitive binary relationships. You can inspect all policies associated with any aspect of a service.

In addition to the policies on the service itself, there is a growing number of companies advocating that policies should be able to be persistently attached to the data traversing the service. Adobe is one of those who believe this is a desirable architectural principle.

I think that the abstract model behind the WS-Policy Framework is ideal for the RA.

D

On 7/3/07 9:39 AM, "Ken Laskey" <klaskey@mitre.org> wrote:

A recurring phrase in the Primer is something on the order "use policy expressions to represent combinations of capabilities and requirements". Seems like policy has been expanded to describe everything we haven't described before.

Note per WS-Policy Framework,
- a "policy" is a collections of policy alternatives, where
- a "policy alternative" is a collection of policy assertions, where
- a "policy assertion" represents a requirement, capability, or other property of a behavior.

Note also,
- a "policy attachment" is a mechanism for associating policy with one or more policy scopes. where
- a "policy scope" is a collection of policy subjects to which a policy applies, where
- a "policy subject" is an entity with which a policy can be associated.

Obviously, any part of a service or service description can be a policy subject. The question, as noted in current RA text, is how do you discover something and decide to use it if critical policies can be embedded anywhere.

I read on :-)

Ken

P.S. I realize the RA does not directly "use" WS-Policy but if we decide not to be consistent, then we need to make our alternatives and our rationale very clear.

------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305 phone: 703-983-7934

7515 Colshire Drive fax: 703-983-1379

McLean VA 22102-7508

--
************************************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.                         *
Chair - OASIS SOA Reference Model Technical Committee                  *
Blog: http://technoracle.blogspot.com                                  *
My Music: http://www.mix2r.com/audio/by/artist/22ndcentury             *
My Band: http://www.myspace.com/22ndcentury                            *
(if (rains)(exists (x)(and (falls x mainlyOnPlain)(rains x inSpain)))) *
************************************************************************

------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305 phone: 703-983-7934

7515 Colshire Drive fax: 703-983-1379

McLean VA 22102-7508

soa-rm-ra message