Workflow

[Roy Williams]

I think there are two sorts of standard that we should be thinking about:

(1) How workflow components interact with their service container, and
(2) How a client interacts with an asynchronous service.

In more detail

(1) I recall the situation with message-passing and parallel computers about 15 years 
ago: each vendor had their own API to their specific messaging system, and 
consequently the development of parallel computing was held back, because nobody want 
to invest the time making code that might become obsolete. The development of the 
standard MPI really made parallel computing fly because every code would run on every 
machine. I think we are now in a similar situation with workflow systems. Each 
workflow vendor has their own API for how the component interatcs with the framework: 
Kepler, Chimera/Pegasus, Astrogrid/CEA, Globus4, DAGMan, Viper, Opticon/ESO, WSRF, 
etc etc. Personally, I would find it very difficult to devote serious effort to 
building components without knowing which will survive. Of course, the real problem 
may be that I simply lack enough understanding of the subtleties to see that these 
are all completely different animals -- in that case I would like my ignorance 
banished.

(2) When I interact with the batch queue on my cluster, I use the Unix commands qsub, 
qstat, qdel to submit, monitor, and kill jobs. I would like an analogous, standard, 
way to use an asynchronous web service, so that a single client code can interact 
with different services. I guess the conversation includes getting a sessionID, 
specifying parameters and inputs, starting up the job, then either the server 
notifies the client, or the client montors the service, and finally there is fetching 
a result. I would guess this is all in the WS-Something specification. And I seem to 
recall Guy Rixon posting something like this a year or so ago.

Roy

--------
California Institute of Technology
roy at caltech.edu
626 395 3670