[SAGA-RG] Job service and sessions

[Andre Merzky]

Hi Malcolm, 

Quoting [Malcolm Illingworth] (Sep 23 2008):
> 
> Hi,
> 
> A hopefully simple implementation question ...
> 
> The SAGA Java API defines an abstract factory for obtaining a job service:
> 
> public abstract class JobFactory 
> {
> ...
> 
> 	protected abstract JobService doCreateJobService(Session session,
> URL rm)
> 	throws NotImplemented, IncorrectURL,
> 	AuthenticationFailed, AuthorizationFailed, 
> 	PermissionDenied, Timeout, NoSuccess;
> ... etc
> }
> 
> Now, Session is defined as containing multiple contexts. So in principle
> there is nothing to stop me creating a Session containing multiple user
> identities and passing it to create a JobService.
> 
> However, if I then submit a job using this JobService, it would appear to be
> undefined which identity would be used to attempt to submit the job. So it
> would seem to me that I should always throw an exception if an attempt is
> made to create a job service with multiple identities.
> 
> Am I missing something here?

What you see is  consistent with the late binding approach
for implementations which interface to multiple backends.

The following examples are simple (sorry for C++ speak)

  saga::context c1 ("Globus");
  saga::context c2 ("Unicore");

  saga::session s;
  s.add_context (c1);
  s.add_context (c2);

  saga::job::service js1 (s, "gram://remote.host.net");
  saga::job::service js2 (s, "unicore://remote.host.net");

It is supposed that, although living in the same session,
js1 will use the Globus ID from c1, and js2 will use the
Unicore ID from c2.

Now, what happens for

  saga::context c1 ("Globus");
  saga::context c2 ("Unicore");

  saga::session s;
  s.add_context (c1);
  s.add_context (c2);

  saga::job::service js1 (s); // use some default resource manager

?  You do not really know, yet, but on calling run_job or
create_job, your implementation should be able to decide.
If your job description contains a candidate host list
'globus-host.remote.net', your implementation may now decide
to use the globus ID, to instanciate a globus job server
instance, and to run through that.

So, the context's added to a session are not supposed to
say 'use id_1 _and_ id_2', but rather 'use id_1 _or_ id_2'.
Your implementation can pick the correct one at runtime.

And yes, if you have a session with multiple contexts, it is
undefined which context will be picked by your
implementation for running a specific job.  If you want to
ensure the globus ID to be used, then you need to create a
session with _just_ the globus context attached to it.

Hope that helps, 

  Andre.


> 
> Regards,
> Malcolm.
> 
> ---------------------------------------------------- |epcc| -
> 
> Malcolm Illingworth
> EPCC, University of Edinburgh
> James Clerk Maxwell Building
> Mayfield Road                   E-mail: malcolm at epcc.ed.ac.uk
> Edinburgh EH9 3JZ               Phone:  + 44 (0) 131 651 3388
> United Kingdom                  Fax:    + 44 (0) 131 650 6555
> 
> ------------------------------------------------------------- 
-- 
Nothing is ever easy.