Balazs, Morris, Luigi, Johannes and all, Concerning OGF PGI open issue Q3 : Activity ID: any special requirement : Thanks to all for their participation to the telephone conference on Monday 08 March 2010. I now understand the issues much better, and I write down below some clear statements which should be quite easy to accept and reject : A) PGI Terminology ------------------ Job = Activity, therefore Job ID = Activity ID Client = Job Submitter Job migration = Job delegation B) Local and Global Uniqueness ------------------------------ - As agreed before, IDs generated by a client can NOT be trusted to be unique at all. - IDs generated by a server are trusted : - to be unique for this server, - but NOT to be globally unique (among all servers) - If we really want an ID to be globally unique, we need something like a GUID. C) Human traceability of Jobs ----------------------------- In case of problems, the Job ID MUST be suitable for manual transfer by a human. Therefore, the Job ID MUST : - contain only 7-bits non-blank printable characters (such as MIME64 or GUID), or 7-bits XML with non-meaningful blanks and newlines. - NOT be too long. I suggest to specify a maximum length of 1000 chars. D) EPRs are suitable for Services, NOT for Jobs ------------------------------------------------ As far as I know, an EPR is an URL of a Service to which a Client MAY submit requests. Therefore, anything pointed by an EPR is a Service instance which MUST be able to receive requests from Clients. A Job is NOT a Service, but an Activity managed by an Execution Service. Therefore, the Job itself does NOT receive requests from Clients, and the Job ID MUST NOT be an EndPoint. In particular, PGI can decide that a Job ID MAY have an XML syntax, or PGI can decide that a Job ID MUST have an XML syntax, but in any case, the Job ID MUST NOT begin with <wsa:EndpointReference>. E) Execution Service responsible for the management of a particular Job ----------------------------------------------------------------------- As soon as a Job is created, there is an Execution Service responsible for the management of this Job. This responsible Execution Service MAY delegate the execution of the Job to a second Execution Service (and so on ...). The responsible Execution Service MAY return to the Client some information about the second Execution Service, and the Client MAY be able to use this information. But the Client MAY also be unable to use this information. Therefore, the responsible Execution Service MUST stay wholly responsible for the Job during the Job lifetime. F) Endpoint(s) of Execution Service(s) -------------------------------------- At the beginning, a Client has picked a (hopefully) suitable EndPoint of an Execution Service from a GLUE-based Information Service, and has submitted a vector of Job descriptions to this EndPoint. E.A) If the Execution Service receiving a vector of Job descriptions is designed so that the Client has to submit ALL subsequent requests to the ORIGINAL Endpoint, then : - The Client does NOT need to extract any Endpoint from the Job ID, and - The Job ID can be completely opaque (such as GUID). E.B) If the Execution Service receiving a vector of Job descriptions is NOT designed so that the Client has to submit ALL subsequent requests to the ORIGINAL Endpoint, then : - Each Job ID must be built so that the Client easily extracts the EndPoint of the Execution Service responsible for the Job, - This EndPoint must stay the SAME for the whole Job lifetime, as explained in chapter E above. - PGI has to specify a limited number of Job ID syntaxes, which MUST be understood by ALL Clients. For example : - URL + '?' + GUID - <pgi:jobid> <wsa:Address>xs:anyURI - PGI SERVICE URL + '?' + GUID </wsa:Address> <wsa:ReferenceParameters>xs:any* - GUID </wsa:ReferenceParameters> ? </pgi:jobid> F) Instances and Shares ------------------------ A Client MUST NOT have to bother with Instances and Shares of an Execution Service. The Execution Service MUST store any information about Instances, Shares, ... inside the Job ID in such a way that : A Client willing to issue a request for the Job just has to send the Request containing the whole Job ID to the URL of the responsible Execution Service as explained in chapter E above. I will also write that inside the WIKI at http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Executio... To be carefully criticized. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------