Workflow

[Tony Linde]

I think the difference with the MPI example is that we've already agreed
that services will generally be web services and we've got a standard
interface those must meet. We also need to define how those are described in
the registry. Once these are all sorted, we'll have a standard way that any
app can be delivered so that it can be found and run in a standard way. But
the web services will all run on the computers where they've been installed.
We're not talking about shifting the code around - a web service runs where
it is installed. If there are multiple instances, they will still be
executable instances.

And once the above is decided, you simply have to write the service
according to those rules. How a given workflow tool describes them for
invocation by a job execution service is irrelevant to how the service is
written - that is core to a service grid.

I'm not saying there might not be aspects of workflow that would be useful
to be standardised but that we really don't need to do that now - the IVOA
has plenty of things that we really need before the international VObs can
be realised without haring off after non-essentials.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-interop at eso.org [mailto:owner-interop at eso.org] On 
> Behalf Of Roy Williams
> Sent: 19 January 2005 21:55
> To: Interop IVOA
> Subject: Re: Workflow
> 
> 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 
>