Workflow

[Tony Linde]

> So the standard service interface will tell me what arguments 
> I need to pass to a particular service or rather there will 

No, I was referring to the resource description, whether it is stored in a
fine-grained registry or got by a two-step process from a coarse-grained
registry, where the parameter description is stored along with the rest of
the resource description required to invoke the service.

> With distributed data sets, we do not care where the data 
> actually resides as long as we have a transparent access 
> protocol and it will be the same with distributed computing 
> resources so don't throw out the concept of hot service deployment.

Completely agree. We need to divide the description of a resource into at
least two parts: the application and the instances of it (or data and where
it is served from ~= mirrors: see previous registry discussions). So you
select the application you want to run and (eventually) the workflow engine
selects the most suitable instance of it for your job.

Cheers,
Tony. 

> -----Original Message-----
> From: Matthew J. Graham [mailto:mjg at cacr.caltech.edu] 
> Sent: 19 January 2005 23:44
> To: Tony Linde
> Cc: 'Interop IVOA'
> Subject: Re: Workflow
> 
> Hi,
> 
> A couple of things in response:
> 
> >  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.
> 
> So the standard service interface will tell me what arguments 
> I need to pass to a particular service or rather there will 
> be a standard method I call to get the list of arguments so 
> invoking a service will actually be a two-tier process: first 
> get the list of arguments and then construct the standardized 
> call with these arguments? This means weakly-typed WSDLs.
> 
> I would rather that the standard interface just guarantees 
> things like I can get the status and logging information for 
> a job or its metadata description.
> 
> > 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.
> 
> With distributed data sets, we do not care where the data 
> actually resides as long as we have a transparent access 
> protocol and it will be the same with distributed computing 
> resources so don't throw out the concept of hot service deployment.
> 
> 	Cheers,
> 
> 	Matthew
>