OGF PGI : EMI Execution Service Specification
Johannes, Morris, and all, Concerning the 'EMI Execution Service Specification' version 1.0 dated 20 December 2010 available at http://forge.gridforum.org/sf/go/doc16254?nav=1 here are my first remarks : General structure ----------------- Exactly like the the 'PGI Execution Service Specification' (doc15839), this document is built upside down, beginning with SOAP specific port-types and operations. Best practices of Software Engineering are to : - begin with use cases and requirements (or with documents or web pages detailing these use cases and requirements), - continue with the description of the managed and used entities, the security context, the relationships between the entities, the state model, the sequence of interactions, ... - only then describe the abstract (NOT SOAP-specific) dialog protocol with exchanged records, requests, responses, subscriptions, notifications, ... - describe SOAP specific port-types and operations in a separate RENDERING document referencing the SPECIFICATION document. So, at least, the SPECIFICATION document must have following structure : 1) Introduction 2) Use Cases and Requirements In particular for : - long term traceability, - Resource matching, - Data staging. 3) Managed and Used entities 3.1) Reference = GLUE 2.0 3.2) Entities = User, Policy, Activity, Endpoint, Data file, JSDL document 3.3) Security context = IGTF + VOMS + Delegation, X509 or SAML 3.4) UML Collaboration diagram(s) with comments 3.5) UML State Diagram(s) with comments 3.6) UML Sequence Diagrams with comments 4) Abstract dialog protocol 4.1) Exchanged records (representing entity attributes) 4.2) Operations (requests, responses, subscriptions, notifications) SOAP specific port-types and operations must be described in a separate RENDERING document referencing the SPECIFICATION document. 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 -----------------------------------------------------
Dear all, Since it was also my task to have a look through the EMI ES Specification, here my comments. * I would back up Etienne, that a chapter referring to Use Cases and Requirements would indeed be useful. * For the ordering I also felt that some things would have been more useful earlier on, especially the current chapter 8 "Resource and Activity representation and the current chapter 10 "Security Considerations" (especially with 10.3 therein) * The EMI ADL (chapter 9) would need a motivation why to start here from scratch and not just define an extension to something similar already existing. * The name of the Resource subelement NetworkInfo (9.3.5.3) could be chosen better, something like NetworkInfoInternal to emphasize that the network connection inside the computing element is meant. * 9.3.5.13 Benchmark is refering to BenchmarkType. That one is missing. Shouldn't Benchmark be a sub-element of BenchmarkType? * 9.3.6 RunTimeEnvironment is generally a sensible idea, but will be heavy on the service descriptions. This maybe needs more discussion with reference to 10.2. * The lines in Figure 1 should not go through the text. * The text is currently very hard to read, it needs at least a native speaker and a grammar nazi to fill in all the missing the, a, to,,,., and get rid of additional spaces. Some of the sentences are in best case misleading. My favorites were: 7/49 XML Validation: Chech whether XML is a valid XML document (i.e. well-formed and such like) 30/45, 9.3.5.8: If it is not defined that the user not interested to access session directory remotely (default is false). --> .. it is assumed that the user is... ? 9.3.5.2 Platform: Multiplicity is one or one. Minor things: p 7/45: Extensions marked as "must" must be understood, .. -> MUST p25/45: "critical": it is hard requirement. The service MUST provide this feature, satisfy the requirement otherwise the activity must be rejected (during the validation phase) --> "critical": it is a hard requirement. The service MUST provide this feature and satisfy the requirement, otherwise the activity MUST be rejected (already during the validation phase). p 19/45: In case of renewal the server must re-use the previous delegation ID submitted in the request. --> In case of renewal the server MUST re-use the previous DelegationID submitted in the request. End of chapter 7.1: Missing internal reference Cheers, Michaela -- Michaela Barth EGI.eu Coordination of Interoperations between NGIs and with other DCIs PDC Center for High Performance Computing CSC School of Computer Science and Communication KTH Royal Institute of Technology SE-100 44 Stockholm, Sweden Tel: +468-790 7891 SIP: caela@kth.se XMPP: caela@kth.se
Hi Michaela, thanks for taking the time to make comments. Very much appreciated! Take care, Morris
-- -----Ursprüngliche Nachricht----- -- Von: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] Im Auftrag von Michaela Barth -- Gesendet: Dienstag, 24. Mai 2011 18:07 -- An: pgi-wg@ogf.org -- Betreff: Re: [Pgi-wg] OGF PGI : EMI Execution Service Specification -- -- Dear all, -- -- Since it was also my task to have a look through the EMI ES -- Specification, here my comments. -- -- * I would back up Etienne, that a chapter referring to Use Cases and -- Requirements would indeed be useful. -- -- * For the ordering I also felt that some things would have been more -- useful earlier on, especially the current chapter 8 "Resource and -- Activity representation and the current chapter 10 "Security -- Considerations" (especially with 10.3 therein) -- -- -- * The EMI ADL (chapter 9) would need a motivation why to start here from -- scratch and not just define an extension to something similar already -- existing. -- -- -- * The name of the Resource subelement NetworkInfo (9.3.5.3) could be -- chosen better, something like NetworkInfoInternal to emphasize that the -- network connection inside the computing element is meant. -- -- * 9.3.5.13 Benchmark is refering to BenchmarkType. That one is missing. -- Shouldn't Benchmark be a sub-element of BenchmarkType? -- -- * 9.3.6 RunTimeEnvironment is generally a sensible idea, but will be -- heavy on the service descriptions. This maybe needs more discussion with -- reference to 10.2. -- -- * The lines in Figure 1 should not go through the text. -- -- * The text is currently very hard to read, it needs at least a native -- speaker and a grammar nazi to fill in all the missing the, a, to,,,., -- and get rid of additional spaces. Some of the sentences are in best case -- misleading. -- -- My favorites were: -- 7/49 XML Validation: Chech whether XML is a valid XML document (i.e. -- well-formed and such like) -- 30/45, 9.3.5.8: -- If it is not defined that the user not interested to access session -- directory remotely (default is false). -- --> .. it is assumed that the user is... ? -- 9.3.5.2 Platform: -- Multiplicity is one or one. -- -- -- -- Minor things: -- p 7/45: Extensions marked as "must" must be understood, .. -- -> MUST -- p25/45: "critical": it is hard requirement. The service MUST provide -- this feature, satisfy the requirement otherwise the activity must be -- rejected (during the validation phase) -- --> "critical": it is a hard requirement. The service MUST provide this -- feature and satisfy the requirement, otherwise the activity MUST be -- rejected (already during the validation phase). -- -- p 19/45: In case of renewal the server must re-use the previous -- delegation ID submitted in the request. -- --> In case of renewal the server MUST re-use the previous DelegationID -- submitted in the request. -- -- -- End of chapter 7.1: Missing internal reference -- -- -- Cheers, -- Michaela -- -- -- -- Michaela Barth -- EGI.eu Coordination of Interoperations between NGIs and with other DCIs -- PDC Center for High Performance Computing -- CSC School of Computer Science and Communication -- KTH Royal Institute of Technology -- SE-100 44 Stockholm, Sweden -- -- Tel: +468-790 7891 -- SIP: caela@kth.se -- XMPP: caela@kth.se -- _______________________________________________ -- Pgi-wg mailing list -- Pgi-wg@ogf.org -- http://www.ogf.org/mailman/listinfo/pgi-wg
participants (3)
-
Etienne URBAH -
Michaela Barth -
Morris Riedel