Web Services Resource Framework
The Web Services Resource Framework, a central part of modern grid services, is definitely something we need to include for strong interoperability, but not something that will solve many of our problems. Its use is by construction constrained to a demesne mostly perpendicular to the difficult areas of implementation we will encounter.
The Problems, and Why WSRF Does Not Solve Them
Data Exchange
We want web services that operate on provided resources, not server-present resources. WSRF does not handle resource provision, and explicitly does not specify any general means of resource creation or discovery (though some of the search functionality in WS-Resource could be used as a crude discovery method; this would not be generally portable, and discovery isn't the big problem, provision is).
WSRF is mainly focused on resources-as-present, not resources-as-provided. It helps clients inspect resources the server happens to have around for interaction with via
Furthermore, the use of a resource specification in WS-Addressing for the call to operate on creates an implied argument. Were that implied argument important, as it would be if it specified the Data somehow, interoperability (especially easy interoperability) would be greatly reduced. People would have to use WS-A compliant clients, and more importantly would not be able to use 'out of box' autogenerated service client stubs, as is a common means for interoperating with foreign web services.
This isn't even reaching that our algorithms can operate on multiple pieces of Data, but WS-Resource services operate on singular Resources.
This problem will be our biggest challenge, but likely also one with a fairly simple solution in the end. Getting simple solutions right is often disappointingly hard, though.
In-progress Arguments
It is theoretically possible for an algorithm to request further input through the appropriate service while it is running; obviously it would be necessary to pass this request on to the remote client. WSRF does make it possible to determine and update properties, as well as pass notification based on property changes, but it includes no mechanism for 'requesting' further information of the client. The client is the actor in WS-Resource (the applicable part of the WSRF specs), not the service.
What WSRF Does Do For Us
An Interface for Scheduling
If we use algorithm-instance-as-resource, we can use a standardized set of properties combined with WS-ResourceLifetime to provide all the capabilities of the scheduling service. A progress property would be available to subscribe to for notification, for instance. Since WSRF does not specify the mechanism of resource creation, we can just treat request-as-instantiation (as the spec seems to suggest, in several places).
This is almost exactly analogous to the usage in a grid.
What WSRF Might Do For Us
Logging
In many ways logging is similar to scheduling, but the correspondence to a resource property is not quite there. A log is an ongoing thing, but it proceeds in a series of discrete updates. We could have the entire log as a property, but that would be inefficient and error prone (what should client behavior be if their previous version of the log does not match up with the first part of the updated log?). We could have a property for something like latest-log-message, but that's kludgy at best. I think a better way to handle logging would be a purer use of WS-Notification, though some aspect of resource specification may play into that.