[ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'

[Savas Parastatidis]

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