Cloud Comedy, Cloud Tragedy

I already explained that I agree with Paco’s view that EPRs are not identifiers. Pankaj also provided a concrete example of why confusing references and identifiers causes problems. Paco just sent a new, better explanation of his earlier point, in the format of a formal proposal to the WS-Addressing WG. His proposal and its justification are a must read. He starts with a “what is required from an identifier” paragraph, which reads:

An identifier to be useful must allow meaningful comparison for identity or “sameness”. This requires them to overall unique and unambiguous, otherwise no meaningful comparison is possible. Moreover one could argue that to be really useful identifiers should not be reused once they’ve been made invalid.

Compare this with the specification for the ResourceId property defined in MUWS Part 1 (note: this is a link to the current working draft as a Word document, not yet a committee draft). Some highlights that match very well with Paco’s expectations for a *real* identifier:

• Globally unique: A manageability endpoint MUST create the ResourceId URI in a way that ensures that the ResourceId is unique to the resource managed through the manageability endpoint and globally unique.
• Uniqueness in time: A ResourceId MUST NOT be reused by the implementation of a manageability endpoint for another resource, even after the original resource no longer exists.
• Consistency across endpoints: An implementation of a manageability endpoint SHOULD use a ResourceId that is suggested by the characteristics of a resource.

And the spec goes on to define in more details why/how implementers should ensure that difference manageability endpoints for the same resource return the same ResourceId, persistence of the ResourceId in time and how to establish “sameness” when for some reason different manageability endpoints for the same resource are unable to return the same ResourceId (correlatable properties). Go ahead and read it or wait a couple of weeks if you want to see a committee draft as a clean PDF rather than a Word document with change tracking turned on.

Greg recently posted an interesting article on what’s ahead of us in terms of really using policies in conjunction with Web services. I agree with him that the interesting question is not in “features and properties” versus WS-Policy. Whether you use one, the other, or a combination of the two you’ve still barely scratched the surface. I also agree that policies should not be tied with WSDL descriptions (a problem of F&P). But a key thing I would add to Greg’s list of what people need to be able to do with policies is define more precisely what “components” of the architecture policies are attached to. Yes, the “service” component is not sufficient as policies can be attached to more granular or less granular levels. But what are these levels? Who defines them? How do we come to agreement on them?

WSDM MUWS 1.0 Part 1 (coming in December) will define such basic components as “property”, “operation” and “event” that can have policies attached to them. These are components that are more granular than a “service” or an “endpoint”. Then you have relationships (defined in MUWS Part 2) that can also have attached policies. And you can have policies applied at a higher granularity level than the service, for example at the level of a business process made up of several services. Who will define these components?

Once we have these policy-capable components defined, we can go back to Greg’s question about attaching policies to them. “Multiple methods of association”, as he suggests, is one possible approach. Another way is to make more daring (shall we say) usage of existing addressing methods. For example the way WS-Management does it in its section 3. But this comes at the cost of throwing down the drain the benefits associated with opaque reference properties in WS-Addressing. Is it worth it? Any other alternative?

After an email exchange with Anish about my previous blog entry I would like to clarify what I wrote on Sunday. I agree that EPRs can be used as identifiers. Just like phone numbers. For example, a specification could require that the Reference Properties be constituted of the element, in effect making the EPR an identity representation by virtue of containing one. And this is fine.

My point is not that this should not be done, it is that the WS-Addressing working group does not need to concern itself with, or even acknowledge this usage of EPRs. The Ws-Addressing working group should concentrate on producing an XML element to package the information necessary to invoke a Web service endpoint. This is what is asked of it. Considering whether and how this can be used for identity consideration is at best a waste of time and at worst a source of unneeded complexity and formalism. Keep it simple.

Note: the most alert readers will have noticed that the prefix of the namespace for the MUWS ResourceId element has changed between my entry on Sunday and this entry from “muws-xs” to “muws-xs-1”. Looks like a detail but this is a sign of an important and very cool improvement that was decided by the WSDM TC today. I am implementing this change in the MUWS spec right now (this blog entry is my little “pause” from the editing work, scary as it sounds). Stay tuned for more. WSDM 1.0 is coming soon to a printer (and a JVM) near you.

I haven’t yet decided whether to join the WS-Addressing working group at W3C and I must say that the deluge of emails going on over there doesn’t do anything to alleviate my main fear about joining the group, i.e. that it will suck a lot of time. Just as I am trying to free more time to work internally on architectural issues related to the MAE (Management for the Adpative Enterprise) effort rather than externally, in standards bodies. But I am monitoring the mailing list of the WS-Addressing working group as what happens to the EPR concept is important to many specifications I am involved with, such as WSDM, WS-Notification and the WSRF patchwork. And it’s always interesting to read what the smart people involved in this discussion have to say. It feels like the Web services communitty has been waiting for an opportunity to have this discussion for a long long time.

One thing that is clear to me after using EPRs for a while is that they are not meant to be identifiers, just references. Their only goal is to tell you how to talk to an endpoint. Francisco Curbera hits the nail on the head in this email message. Identifying endpoints and whatever it is that they represent is a different thing altogether and not in scope for WS-Addressing. It is in scope for management applications of Web services and this is exaclty what WSDM MUWS (Management Using Web Services) provides through the muws-xs:ResourceId property, along with (optionally) the “correletable properties” capability.

Other issues that the WS-Addressing group now has to deal with include usage of Reference Properties (and especially how they get mapped to SOAP headers) and what Reference Parameters are good for. Those got slipped into the version of the spec submitted to W3C and were not available to us when designing WSDM, WSN and WSRF. Not that we would necessarily have used them anyway. Another issue that hasn’t yet showed up on the WS-Addressing mailing list is whether it is appropriate for someone to modify EPRs it receives if there is some “out of band” understanding of how they are built. My guess is that the group will punt on that one (which is reasonable) but I am looking forward to the discussion and will raise this question if no group member does. I might write more on some of the topics in this last paragraph in later entries.