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@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.