Dear Ian,
I'm not sure that the "we don't need WSRF" is the heart of the debate. If it was, then I think things are fairly clear: WSRF is just some conventions for the messages that you send to do certain things (e.g.,
getResourceProperty to get state, Terminate to destroy something, or whatever the names are) in a WS context.
I think that there are still issues being debated as to when it is appropriate to use WSRF (or something like it) in the design of services for inter-enterprise/Internet-scale/Grid computing. For example, two issues that are I think worth discussion are efficiency and whether or not WSRF is needd to capture common application semantics. To take them in turn... a) efficiency.
If you don't have those conventions, then everyone ends up defining their own, so that e.g. a job management interface might have "getJobStatus" and "destroyJob", a file transfer interface might have "getTransferStatus" and "destroyTransfer".
The WSRF way of doing things promotes a view where all 'stateful resources' are addressable and able to receive messages (i.e. they are logical recipients of messages). As a result, service designers are encouraged to think in terms of messages that are targeted towards single resources. However, sending and receiving messages has a high cost when sending them across the Internet and there are many cases where it would be more efficient to define message interactions which involve multiple resources. For example sending the following message to a service: 'getJobStatus' of job1 and job2 and job3 and job4 and... jobN Is more efficient than sending individual messages to n individual resources of the form: 'getResourceProperties' jobK (the same would be true of 'destroyJob' vs WSRF 'destroy' messages). The former approach is a general case since it allows us to get the status of one or multiple jobs in one message. Also, it is application specific since the semantics of the interaction tells us what to expect. The latter approach is specific to only one resource at a time. Multiple message exchanges are necessary to achieve the same thing as the 'getJobStatus' approach or yet another abstraction (e.g. service groups, which introduces extra complexity and message exchanges) has to be introduced. Effectively the resource-oriented view of WSRF leads designers to inefficient use of the network and the services involved in interactions. Also, current Web Services tooling will allow me to easily define the getJobStatus message in WSDL and it will automatically generate the code for me. I do not see the great advantage of having a generic getResourceProperties message when it comes to designing high-level services: it is the structure and contents of the document returned that it is important, rather than how it is accessed. A generic getResourceProperties could be of use when we require common application semantics (in the same way REST is designed) and we need document transfer. However, in such a case the more lightweight solution of WS-Transfer with its CRUD semantics could be used. 2) Does WSRF capture common application semantics?
If you don't have those conventions, then everyone ends up defining their own, so that e.g. a job management interface might have "getJobStatus" and "destroyJob", a file transfer interface might have "getTransferStatus" and "destroyTransfer". This lack of consistency just makes life difficult, without providing any benefits.
It is not clear to me how to model "kill", "cancel", "pause", "suspend" for a job using WSRF... all these messages carry different semantics that cannot be captured by a single "destroy" message. Also, is there a suggestion that the semantics of "destroy" are common across all application domains? For example, what does it mean to "destroy" a database resource? What can the sender of the message assume about the effect of the generic "destroy" message? Does it mean that the database is droped or just disconnected? If we need to create specific interactions to capture the different semantics in the case of kill/cancel/pause/suspend and drop/disconnect, what is the value of a generic 'destroy' message for all high-level services? Please note that I am not suggesting that WS-RF (and WS-Transfer for that matter) is not useful in certain cases. Indeed, in the systems management area it may make sense to use them. However, what it is being proposed in the OGSA working group (if I understand correctly) is that WS-RF be used as the foundation for all high-level services.
The debate with MS, as I understand it, seems to rather relate to the fact that they are promoting a *different* set of conventions for doing similar things, e.g., WS-Transfer instead of WS-ResourceProperties.
I won't pretend to know of Microsoft's intentions. However, a difference that I personally see between the WS-RF/WS-Notification and WS-Transfer/ /WS-Eventing/etc. camps is that the latter is much simpler and lightweight. Most importantly, the MS suite of specifications is not promoted as the uniform, underlying suite of common messaging behaviours for all high-level services as WS-RF seems to be. Instead it is some patterns that are available to be used where they are appropriate. Also, WS-Transfer is lightweight so it can be used in very-small-factor devices. So, it would be interesting to understand from the WSRF architects where they feel the WSRF approach is and is not appropriate. E.g. is it appropriate for interactions with multiple resources? Should it be used in the design of all high-level Grid services? What are the semantics of the 'destroy' messages? Best regards, -- Savas Parastatidis http://savas.parastatidis.name