FW: WSRF and Fujitsu

Congratulations on getting the WSRF group going. I can imagine that this is a tremendous amount of work. I have reviewed the Resource Properties, and generally feel that the spec is well written (complete) and that the functionality is very useful, and very compatible with work going on at OASIS Asynchronous Service Access Protocol.

However, there is one overwhelming problem: it references WS-Addressing which is not a ratified standard, and has not even been offered to a standards body. We have no guarantee that WS-Addressing will be offered royalty free, nor do we have any guarantee that it will not change from its current form. We can not accept this. There is a potential political play, if WSRF becomes dependent on WS-Addressing, they can avoid having to submit WS-Addressing to process of review and approval, and still retain unilateral control of it. It would be unwise to get into this position.

WS-Addressing has some problems but they are hard ones to argue in a "design-by-committee" environment. WSRF is all about "resources" and is by design "resource-oriented". In the web, a "resource" has an address, simple enough. A URI (or URL) is a sufficient way to indicate the address of a resource. But the people who designed most of the SOAP framework take an "operation-oriented" approach: the critical address is that of the operation (or method) and resources are passed as parameters to the operations. This approach, especially in a grid environment, is a real limitation on flexibility. While the URI for a particular resource might include the address of the operation, and an objectid combined together in a way that makes sense to the implementation, WS-Adressing forces the operation address (the <To> tag) and the object id (the <SomeResourceId> tag) to be explicitly identified. By forcing the service to expose this detail, it reduces the amount of flexibility that an implementation has. One must have a very good reason to limit the flexibility of an implementation, and I do not see any very good reason within WS-Addressing to make these two components of the address explicit.

For example, the caller of a resource, has no guarantee that the object ID can be pulled out and used with a different operation address -- unless someone wants to define exactly how you identify all the operation addresses that an object id is useful for, and there is no proposal, nor is anything likely to be proposed in the near future. One must ask the question why these parts of the address are being made explicit when the caller can not actually use the parts separately. A good guideline for a protocol standard that will get wide usage is specify only those things that need to be specified, and to carefully avoid specifying things that do not make a difference.

A far better approach, and one that OASIS Asynchronous Service Access Protocol is using, is simply to specify the resource with a URI. The server has complete freedom on how it encodes the object id into the URI. The internal workings of the service are less exposed, and therefor less constrained by the protocol.

asap message