[Pgi-wg] OGF PGI open issue Q3 : Activity ID: any special requirement

[Etienne URBAH]

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/ExecutionServicePoints

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 at lal.in2p3.fr
-----------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5073 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20100309/3a6171e6/attachment.bin