[saga-rg] Comments on the job API (revision 1.4)

[Christopher Smith]

FWIW

I see the JobService as being closely coupled to the resource manager, such
that the constructor of the JobService could take the address of an RM
endpoint. 

I'm also not sure of the usefulness of having separate createJob and run
methods, rather than submitJob ... and I can't recall the conversations that
lead to the distinction. :-)

I do believe that jobs started with runJob are still "jobs" and should be
added to indices. runJob is just a shortcut method (we had lots of
discussions about whether to add it or not).

-- Chris

On 3/3/06 03:35, "Graeme Pound" <G.E.POUND at soton.ac.uk> wrote:

> Hi,
> 
> I have some comments on the job section of the Strawman API (revision 1.4).
> 
> Thanks
>    Graeme
> 
> 
> 
>   -3.37 I do not understand the purpose of job_service.get_self() which
> returns a Job object.
> 
>   -3.38 I like the removal of the JobInfo and JobExitStatus objects from
> the API, and adding this information as attributes to Job. This
> streamlines the API, the concept of read only attributes also makes
> sense [to me] within the context of the Job object.
> 
>   -3.39 I like the simplification of the job_state enumeration. NB This
> is called 'state' in the SIDL and should be corrected to 'job_state'.
> 
>   -3.41 The separation of the JobService.submitJob() method into two
> methods JobService.createJob() [create the job object] and Job.run()
> [start the job] has not been seamless and there are several of
> conceptual and practical problems. This needs to be fine-tuned further.
> On many [all?] resource managers there is no separation between
> submitting a job to the resource manager and manually starting the job,
> this raises the following problem:
>          - Job objects are identified via the job_id which is described
> as the  "job identifier as returned by the resource manager".
> Unfortunately since this information will only be available upon
> submission of the job (via Job.run()) this breaks the methods
> JobService.list() and JobService.getJob(). It is now impossible to
> manage an index of Job objects within JobService based upon the job ID.
>          - What is the conceptual relationship between the JobService
> and the resource manager? At present this is a little confused in a
> couple of ways.
>              #1 Should there be a one to one relationship between
> JobService instances and resource managers; i.e. should the resource
> manager endpoint be specified in the JobService constructor (or
> otherwise as an argument to JobService.createJob())?
>              #2 The term JobService implies a close relationship to the
> resource manager. Previously JobService.submitJob() corresponded to
> communication with the resource manager. Now JobService.createJob()
> corresponds to the creation of instances of the Job class the JobService
> is acting as a factory. It may beneficial to rename JobService to
> JobFactory to clarify the relationship.
> 
>   -3.42 Should Job objects created by runJob() be added to the index
> managed by the JobService? Or in other terms, should JobService.runJob()
> be a Java 'static' method?
> 
> 
> 
>