SourceForge : View Wiki Page: RequirementsTable

Search Wiki Pages Project: pgi-wg Wiki > RequirementsTable > View Wiki Page

wiki2239: RequirementsTable

PGI Requirements Table for agreement

Some of the sources of the collected requirements entered into the table :

Existing OGF recommendations : Mainly GLUE, BES, JSDL, HPC Basic Profile
PGI Security Model
PGI : Execution Service Context - Main types of Grid Jobs
Data Staging - Concepts and Scenarios
Use case: GROMACS
PGI Single Job State Model (available as ZARGO, XMI and PNG)
PGI Job Vector Quick Submission Sequence Diagram (PNG)
PGI Job Vector Submission With Full Validation Sequence Diagram (PNG)
Strawman functionality
Draft Specification Discussion Slides
Open Issues
PGI Execution Service Specification
Background information from RFP of the US XD programme, NSF 08-571

This Table of Requirements has following columns :

1	Nb	Requirement Number
2	Description	Requirement Description
3	Source	Source or Author of the Requirement
4	Areas	Areas to which the requirement apply
5	Dependencies	List of Requirement Numbers on which the current requirement depends
6	Status	Requirement Status
7	Date	Date of Status change (yyyy-mm-dd)

The Requirement Status can have one of following values :

Proposed (Not yet validated as in scope and open for detailed discussion)
Rejected (Not understandable, Out of scope, Contains hidden prerequisites, ...)
Dupl. (Duplicate, therefore Closed)
Premature (Detailed specification, Specification of implementation, ...)
Open (In scope, and under detailed discussion)
Agreed YES
Agreed NO
Met (The Wiki page can contain a link to the document and section)

Each requirement, if necessary, can point to a separate Wiki page providing :

The origin of the requirement,
The detailed description of the requirement,
Minutes of discussions
Minutes of agreement or rejection

Vocabulary and Terminology

The dedicated page PGI Vocabulary and Terminology details many terms. Below are presented only a few terms which are critical for the understanding of the requirements.

'Activity' and 'Job' are fully synonyms. 'Job' is used by the current version of JSDL. Since 'Activity' is used by the current versions of GLUE and BES, we will often use 'Activity' .
'Client' : Holder of credentials belonging to a member of a GLUE UserDomain. For example, a Client MAY submit an Activity to the Execution Service, or query the Status of an Activity.
'Payload' : Anything (Application, Script, Pilot Job, ...) executed by the Computing Resource on request of the Activity. The payload MAY completely ignore that is is executed inside a grid Activity.

NF) Requirements concerning Non-functional areas (2010-03-26: 20 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
NF1		Specifications MUST be designed so that the implementation and validation of Clients is easy	Etienne Urbah	Implementation issues, Cost		Dropped (Rejected, General Computer Science)	2010-04-27
NF1.1		Whenever multiple protocols are possible, Clients MAY implement only one	Etienne Urbah	Implementation issues, Cost	NF1	Dropped (Rejected, Out of scope)	2010-04-27
NF1.2	161	Whenever multiple protocols are possible, Services SHOULD implement at least the 2 most used protocols	Etienne Urbah	Implementation issues, Cost	NF1	Open	2010-04-28
NF2	145	Specifications MUST reuse as many existing standards as possible	General	Reuse Specs, Cost		Agreed YES	2010-04-28
NF3	146	Software components (Services and Clients) MUST ensure traceability of the original author of a request	Etienne Urbah	Event reports, Resilience, Accounting		Agreed YES	2010-05-10
NF4	147	Software components (Services and Clients) MUST generate adequate logs	General	Event reports, Resilience		Agreed YES	2010-04-28
NF5	148	Software components (Services and Clients) MUST generate and propagate meaningful error messages, including context description	General	Event reports, Resilience		Agreed YES	2010-04-28
NF6	162	Software components (Services and Clients) MUST implement the Security Policies defined by the JSPG (Joint Security Policy Group), in order to be resilient to attacks	Etienne Urbah	Resilience	NF3, NF4	Open	2010-04-28
NF7	149	Specifications SHOULD prevent the occurrence of SPOFs and bottlenecks	General	Resilience, Availability, Performance		Agreed YES	2010-04-28
NF8	150	Clean specifications and interface definitions, don't keep obsolete and never used elements (by whom?)	Balazs Konya	Extensibility		Agreed YES	2010-04-28
NF9	151	The specification should be as much self-contained as possible, limit external dependencies	Balazs Konya	Implementation issues	Conflicts with NF10, NF11, NF12, NF13	Open	2010-04-28
NF10	152	Evolutionary aspect of existing specifications (marketing efforts, bad community reputation if OGF standards are unstable). Any new specification should be result of evolution of previous specification. E.g. the scope and orientation of a spec should not change dramatically to the previous one, e.g. conceptual backward compatibility is a must.	NSF 08-571	Reuse Specs	Conflicts with NF9	Agreed YES	2010-05-10
NF11	153	Backwards compatibility (on-the-wire) not a precise requirements, conceptual backward compatibility a must - new portType - new compilation anyway but general concept should be kept.	NSF 08-571	Reuse Specs	Conflicts with NF9	Open (unclear)	2010-04-29
NF12	154	Basic SW Engineering basic principles - implementation encapsulation, separation of policies, construction by composition, don't re-invent new mechanisms when some existing	NSF 08-571	Reuse Specs	Conflicts with NF9	Agreed YES	2010-04-28
NF13	160	Execution Service MUST NOT try to provide ALL grid functionalities, but MUST have a well defined scope, and MUST work together with other grid services : Security, Accounting, Data (Storage, Movement, Catalog, ...), perhaps Information, Logging and Bookkeeping	Etienne Urbah	Reuse Specs, Cost	Conflicts with NF9	Agreed YES	2010-05-20
NF14	155	Data is equally important as compute	NSF 08-571			Open (unclear)	2010-04-29
NF15	156	Need to provide high availability and reliability	NSF 08-571	Availability, Resilience	Related to NF7	Agreed YES	2010-05-10
NF16	157	Single global namespace for resources of all kind (storage devices, compute device), for example: a path mechanism - 'address the same things everywhere'. Definitely not XML namespaces - more identification of resources. Closest analogy might be DNS.	NSF 08-571	Practical Client Interface		Open (unclear)	2010-04-29
NF17	158	Easier usage to get more users involved. How does it effects PGI?! A general rule like global namespaces (for example: path)	NSF 08-571	Practical Client Interface		Open (unclear)	2010-04-29
NF18	159	Specifications of the Execution Service should be so well designed that its interfaces are likely to be re-used by other Services (e.g. potential re-use of portTypes by other services - for example: information portType)	GIN	Reuse Specs, Extensability		Agreed YES	2010-05-20

IS) Requirements applying mainly to the Information functionality (2010-03-26: 18 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
IS1	1	All grid entities (if possible) MUST be described using the GLUE model. If not possible, extensions for the GLUE model are necessary	GIN	Information, Reuse Specs		Agreed YES	2010-06-22
IS1.1		All grid entities SHOULD be described in conformance with the latest published GLUE recommendation (currently GLUE 2.0)	Etienne Urbah	Information	IS1	Re-proposed	2010-11-17
IS1.2	2	For each grid entity which can NOT be described in conformance with GLUE, PGI should propose extensions	GIN	Information	IS1	Dropped (Dupl. IS1)	2010-04-29
IS2	163	Each Service MUST publish its properties (Name, Type, Endpoints, ...) and the properties of its Endpoints in conformance with GLUE recommendations	Etienne Urbah	Information		Re-proposed	2010-11-17
IS2.1		Each Service MUST publish the static and dynamic properties of each of its Endpoints to the Information functionality in conformance with GLUE recommendations	Etienne Urbah	Information	IS2	Dropped (Dupl. IS2)	2010-04-21
IS2.2	3	A GLUE Computing Endpoint can describe only 1 Job submission interface (for example BES). Job submission interfaces which have different properties (for example vector limits) MUST have different GLUE Computing Endpoints	Etienne Urbah	Information	IS2	Agreed YES	2010-06-22
IS3	4	Each service MUST publish information regarding its service properties	GIN	Information		Agreed YES	2010-04-28
IS4	5	The Execution Service MUST NOT expose detailed information about the GLUE entities which the Execution Service does not manage (all that are not expressed by the computing part of GLUE). For example, Storage Element GLUE entity NOT exposed by Execution Service, NO details about Storage entity.	Etienne Urbah	Information, Activity Management	NF13	Agreed YES	2010-04-28
IS5	6	Instance of Execution Service MUST provide access to attributes/meta data that describe this instance using GLUE2. (V-2 note: The appropriate sections of the XML rendering of GLUE2 need to be identified.). Different levels of verbosity should be offered.	Strawman functionality	Information		Agreed YES	2010-05-06
IS6	7	The Execution service instance MUST publish all data-staging capabilities (for example: supported protocols like GridFTP, ByteIO,...).	Draft Spec	Information, Activity Management, Data Management		Open	2010-05-05
IS7	8	If the Execution Service provides vector functionalities, then it MUST publish the vector limits as properties of GLUE Endpoints. If these vector functionalities have different vector limits, then they MUST be grouped inside separate GLUE Endpoints entities having each a homogeneous vector limit.	Draft Spec	Information, Activity Management	IS2.2	Agreed YES	2010-04-28
IS8	164	For not yet finished Activities, the Information functionality MUST accept requests querying the Activity Status, and MUST return this Status with different levels of verbosity (basic, detailed, more detailed)	Etienne Urbah	Information, Activity Management		Open (unclear)	2010-04-28
IS9	165	For already finished Activities, the Information functionality SHOULD accept requests querying the Activity Status, but MAY return an error	Etienne Urbah	Information, Activity Management		Agreed YES	2010-05-20
IS10		For requests querying Activity Status, the Information functionality MUST accept, as input parameter, 1 Activity ID	Etienne Urbah	Information, Activity Management	IS8	Re-proposed	2010-05-05
IS11		For requests querying Activity Status, the Information functionality MUST accept, as input parameter, a vector of Activity IDs	Etienne Urbah	Information, Activity Management	IS8	Dropped (Rejected, Bad prerequisite on Information Service)	2010-04-21
IS12		For requests querying Activity Status, the Information functionality MUST accept, as input parameter, complex queries on Activities expressed according to the GLUE2 model without explicit specification of the Activity IDs. The Information functionality MAY support multiple query languages in addition to the mandatory one.	Etienne Urbah	Information, Activity Management	IS8	Re-proposed	2010-05-05
IS13	166	For requests querying Activity Status, the Information functionality SHOULD support query languages	Etienne Urbah	Information, Activity Management	IS8	Agreed YES	2010-05-20
IS14	172	In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Information functionality SHOULD be separated from the Execution Service	Etienne Urbah	Information, Execution Service	NF13, IS5, IS12, IS13	Agreed YES	2010-05-20

AA) Requirements applying mainly to Security (Authentication, Authorization, Delegation) (2010-03-26: 31 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
AA1	9	If a server authenticates itself to clients, then it MUST do so with X509 certificates on TLS. It MAY optionally use other mechanisms.	General	Security		Agreed YES	2010-06-22
AA1.1	10	SSL certificates of servers MUST be signed by a CA belonging to IGTF	General	Security	AA1	Open	2010-04-28
AA2	11	Each Service MUST publish the Authentication and Authorization methods accepted by its Endpoints in conformance with GLUE recommendations	General	Security, Information	IS2.1	Agreed YES	2010-06-22
AA2.1		The Authentication and Authorization methods accepted by each Endpoint must be published inside the 'Capability' Attribute of the 'Endpoint' entity of the Information Service, as extensions of the 'security.authentication' and 'security.authorization' values of the 'Capability_t' data type	Etienne Urbah	Security, Information	AA2, IS2.2	Dropped (Premature, Implementation)	2010-04-21
AA3	12	For Client authentication, Services MUST require security credentials	General	Security		Open	2010-04-28
AA3.1	13	For Client authentication, Services MAY accept full X509 certificates	General	Security	AA3	Open (unclear)	2010-04-28
AA3.2	14	For Client authentication, Services MAY accept RFC-3820-compliant X509 proxies	General	Security	AA3	Open (unclear)	2010-04-28
AA3.3	15	For Client authentication, Services MAY accept SAML assertions	General	Security	AA3	Open (unclear)	2010-04-28
AA3.4	16	For Client authentication, Services MAY accept Shibboleth credentials	General	Security	AA3	Open (unclear)	2010-04-28
AA3.5	17	For Client authentication, Services must accept all following authentication methods: Full X509, X509 Proxy	General	Security	AA3	Agreed YES	2010-06-22
AA4	18	For Client authorization, Services MUST require security credentials	General	Security		Open	2010-04-28
AA4.1	19	For Client authorization, the packaging of security credentials MUST be designed to prevent that any software component gains undue privilege by extracting only some credentials from the package	Etienne Urbah	Security	AA4	Agreed YES	2010-04-28
AA4.2	20	For Client authorization, Services MAY accept the DN of the X509 certificate or RFC-3820-compliant X509 proxy	GIN	Security	AA4	Agreed YES	2010-04-28
AA4.3	21	For Client authorization, Services MAY accept X509 VOMS-style Attribute Certificates (VOMS extensions)	GIN	Security	AA4	Agreed YES	2010-04-28
AA4.4	22	For Client authorization, Services MAY accept SAML assertions	GIN	Security	AA4	Agreed YES	2010-04-28
AA4.5	23	For Client authorization, Services MAY accept Shibboleth credentials	GIN	Security	AA4	Agreed YES	2010-04-28
AA4.6	24	For Client authorization, Services MUST accept at least one of DN, X509 VOMS extensions, SAML assertions	GIN	Security	AA4.2, AA4.3, AA4.4	Open	2010-04-28
AA4.7	25	For Client authorization, Services SHOULD accept SAML assertions	GIN	Security	AA4.4	Open	2010-04-28
AA4.8	26	Cross-organization delegation, particularly to (university) campuses and other partner institutions, use native authentication mechanisms to national resources. I can use my credentials at University X to retrieve another credential for University Y that is in the same trust federation. For example: in US a lot of efforts towards SAML and 'incommon' driven by Internet2 (i.e. Shibboleth). Different attributes: Ways to use WS-Trust to work on this.	NSF 08-571	Security	AA4	Open	2010-04-28
AA5		For Client authentication and authorization, Services MUST follow the OGSA Basic Security Profile 2.0, which references Secure Addressing Profile 1.0 and Secure Communications Profile 1.0	Etienne Urbah	Security	Perhaps conflicts with AA6	Dropped (Rejected, NOT precise enough)	2010-04-21
AA6		For Client authorization, Services MUST implement the Common Open Policy Service (COPS) defined by RFC 4261, with PAP, PDP, PEP, ...	Etienne Urbah	Security	Perhaps conflicts with AA5	Dropped (Rejected, NOT precise enough)	2010-04-21
AA7	27	In order to keep middleware complexity and bandwidth usage as low as possible, grid Services should NOT send the full description of their security interface inside each message, but only when specifically requested	GIN	Security, Performance		Open	2010-04-28
AA8	28	Service has to act on behalf of another identity. Services often need to delegate those Credentials to other Service. Therefore, Services MUST offer interoperable methods for Credential delegation.	GIN	Security		Agreed YES	2010-04-28
AA8.1		For credential delegation, Services MUST follow the XACML profile and implementation for Authorization Interoperability between OSG and EGEE (David Groep can explain)	Etienne Urbah	Security	AA7; Perhaps conflicts with AA8.2	Dropped (Premature, Detailed specification)	2010-04-21
AA8.2		For credential delegation, Services MUST implement Use of WS-TRUST and SAML to access a Credential Validation Service, which is based on WS-Trust 1.3	Etienne Urbah	Security	AA7; Perhaps conflicts with AA8.1	Dropped (Premature, Detailed specification)	2010-04-21
AA8.3	29	We need delegation and have to define exactly what delegation is and its methods. E.g. the delegation procedure might require multiple steps (one approach might be the delegation portType), e.g. gridsite delegation method - bringing delegation to the portType level using operations.	GIN	Security	AA8	Agreed YES	2010-04-28
AA8.4	30	Delegation credential renewal should be supported	GIN	Security	AA8	Agreed YES	2010-04-28
AA8.5	31	Associate Activity to a specific delegation credential, e.g. certificate or SAML assertion, or... Each job belongs to a credential (associate them), when ever one credential expires then the Execution Service may terminate the corresponding Activities	Luigi Zangrando	Security	AA8	Agreed YES	2010-04-28
AA9	32	There must be a mechanism which allows users to manage Activities submitted by other users (access control lists/methods/policies). In order to authorize (or not) an request on an Activity, each instance of the Execution Service MUST enforce a consistent authorization method.	Luigi Zangrando	Security, Activity Management		Agreed YES	2010-04-28
AA10		Any action/invocation/functionality of the Execution Services requires authorization of end-users/clients		Security		Dropped (Dupl. AA4)	2010-04-21
AA11	33	It is assumed that the clients obtain security setup info through out-of-band mechanisms which are not covered by this specification.	Draft Spec	Security		Open	2010-04-28
AA12		Clients MUST authenticate Services with SSL certificates	Luigi Zangrando	Security		Dropped (Dupl. AA1)	2010-04-21

AR) Requirements applying mainly to Application Repository (2010-03-26: 3 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
AR1	34	An easy way of launching applications or pre-configured /pre-installed software w/o specifying location details. Installed/pre-configured ones should be exposed as well as part of the resource description. The available software should be exposed through the service and in turn be requestable for resource/applications statements in JSDL. E.g. extending the JSDL with "pre-configured sw pieces" and/or "software libraries", e.g. global namespace of this applications might be beneficial as well. , etc.	GIN, NSF 08-571	Application Repository, Information, Job Description, Activity Management		Agreed YES	2010-04-29
AR2	35	Application management, for example: pre-installed applications, abstract notion of the application (i.e. specify w/o executable locations), global namespace of this applications might be beneficial as well.	NSF 08-571	Application Repository, Job Description		Dropped (Duplicate AR1)	2010-04-29
AR3		Application management should use the Application Repository specified in the deliverable DSA1.1 of the EDGeS project	Etienne Urbah	Application Repository	AR1	Dropped (Premature, Specification of implementation)	2010-04-21

Ac) Requirements applying mainly to Accounting (2010-03-26: 2 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
Ac0	167	In order to permit efficient Accounting, a grid infrastructure MUST provide an Accounting functionality (without real time requirements) which consolidates Accounting records at the grid level from various systems, securely keeps Accounting records even after Activities have finished, implements complex accounting queries, and supports the corresponding CPU load	Etienne Urbah	Accounting		Open	2010-04-29
Ac1		In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Accounting functionality MUST be separated from the Execution Service	Etienne Urbah	Accounting, Activity Management	Ac0, NF13	Re-proposed	2010-04-23
Ac2	36	The Execution Service SHOULD provide Accounting records for each managed Activity. e.g. OGF Usage Records, for tracking resource usage. Most likely improving UR in terms of network and storage resource tracking and improvements of compute parts of multi-core-business. Grid-level attributes (for example: start-time on Grid vs. in batch-system).	NSF 08-571	Accounting		Agreed YES	2010-04-29

LB) Requirements applying mainly to Logging and Bookkeeping (2010-03-26: 8 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
LB1	37	In order to permit efficient Log analysis and Security audit, some Logging and Bookkeeping functionality MUST secure persistence at the grid level of Activity logs from various logging systems and MUST permit Client access to these Activity logs, even after Activities have finished	PGI	Logging and Bookkeeping, Execution Service	NF2, NF3, NF6	Re-proposed	2010-05-07
LB2	38	Some Logging and Bookkeeping functionality MUST accept requests querying the Status of an Activity (primarily for completed and finished Activities), and MUST return the Activity Status with different levels of verbosity (basic, detailed, more detailed)	PGI	Logging and Bookkeeping, Execution Service	LB1	Re-proposed	2010-05-07
LB3	39	Some Logging and Bookkeeping functionality MUST accept requests in order to obtain the Activity log, and MUST return the Activity History with different levels of verbosity (basic, detailed, more detailed)	PGI	Logging and Bookkeeping, Execution Service	LB1	Agreed YES	2010-04-29
LB4		For all requests, the Logging and Bookkeeping functionality MUST accept, as input parameter, 1 Activity ID	Etienne Urbah	Logging and Bookkeeping	LB1	Re-proposed	2010-05-07
LB5		For all requests, the Logging and Bookkeeping functionality MUST accept, as input parameter, a vector of Activity IDs	Etienne Urbah	Logging and Bookkeeping	LB1	Dropped (Premature, Detailed specification)	2010-04-21
LB6		For all requests, the Logging and Bookkeeping functionality MUST accept, as input parameter, complex queries on Activities expressed according to the GLUE model without explicit specification of the Activity IDs. The Logging and Bookkeeping functionality MAY support multiple query languages in addition to the mandatory one.	Etienne Urbah	Logging and Bookkeeping	LB1	Re-proposed	2010-05-07
LB7	40	In terms of queries, the Logging and Bookkeeping functionality SHOULD support query languages, e.g. at least one complex query language like XPath, XQuery, in order to obtain the activity logs, etc	PGI	Logging and Bookkeeping	LB1	Open	2010-04-29
LB8	41	In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Logging and Bookkeeping functionality SHOULD be separated from the Execution Service	Etienne Urbah	Logging and Bookkeeping, Execution Service	NF13, LB1...LB7	Open	2010-04-29

JM) Requirements applying mainly to Activity Management (2010-03-26: 67 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
JM1	42	For Activity submission, Clients MUST query the Information Service in order to get an adequate Endpoint of an Execution Service	Etienne Urbah	Activity Management, Information Service		Proposed	2010-03-17
JM2	43	The Execution Service MUST provide a way to create Activities.	General	Activity Management		Proposed	2010-03-19
JM3	44	Activities submitted by Clients to an Execution Service MUST be specified using a well-defined Job Description document	General	Activity Management, Job Description	JM2	Proposed	2010-03-17
JM4	45	On creation of an Activity, the Execution Service MUST return to the Client an Activity ID permitting the Client to perform subsequent actions (Query, Cancel, ...) on this precise Activity	General	Activity Management, Information Service	JM2	Proposed	2010-03-17
JM4.1	46	The service assigns a global unique Activity ID - not the client	General	Activity Management, Information Service	JM4	Proposed	2010-03-20
JM4.2		Potentially the WS-RF Factory pattern (BESFactory creates Activity Service instances, etc.) might be a good option and a good design in this context is the requirement. Mabye running into performance issues with multiple/bulk vector operations. It potentially makes it easier to use WS-Notification approach.	NSF 08-571	Activity Management, Information Service	JM4	Dropped (Premature, Detailed specification)	2010-04-23
JM4.3	47	The Activity ID MUST be suitable for manual transfer by a human (In case of problems with the Activity)	Etienne Urbah	Activity Management, Information Service	JM4	Proposed	2010-03-17
JM4.4	48	In case of an Activity being moved to another Execution Service, the Activity MUST still be accessible via the initial Execution Service which created the Activity	Etienne Urbah	Activity Management	JM4; Conflicts with JM4.5 and JM4.6	Proposed	2010-03-17
JM4.5	49	An Execution Service MAY offer several Endpoints to create and later manage the Activities while the later Endpoint must stay fixed	Etienne Urbah	Activity Management	JM4; Conflicts with JM4.4 and JM4.6	Proposed	2010-03-17
JM4.6	168	After creation of the Activity, the Endpoint used by the Client to manage the Activity MAY vary	Etienne Urbah	Activity Management	JM4; Conflicts with JM4.4 and JM4.5	Re-proposed	2010-04-27
JM4.7	50	The Execution Service MUST NOT assume that the Client is able extract any information from the Activity ID. Therefore, the Activity ID can be completely opaque.	General	Activity Management	JM4.4; Conflicts with JM4.8 and JM4.9	Proposed	2010-03-17
JM4.8	51	From the Activity ID, the Client MUST be able to extract the Endpoint suitable for Activity Management, but the Execution Service MUST NOT assume that the Client is able to extract any other information from the Activity ID	General	Activity Management	JM4.5; Conflicts with JM4.7 and JM4.9	Proposed	2010-03-17
JM4.9	52	From the Activity ID, the Client MUST be able (for example by querying a Name Server) to dynamically retrieve the Endpoint suitable for Activity Management, but the Execution Service MUST NOT assume that the Client is able to extract or retrieve any other information from the Activity ID	General	Activity Management	JM4.6; Conflicts with JM4.7 and JM4.8	Proposed	2010-03-17
JM4.10	53	Define exactly what an Activity ID is.	GIN	Activity Management, Information Service	JM4.1, JM4.2, JM4.3, JM4.4, JM4.5, JM4.6, JM4.7, JM4.8, JM4.9	Proposed	2010-03-19
JM4.11	54	Operations dealing with Activity management of the service SHOULD operate on Activity IDs in order to ensure a good performance	GIN	Activity Management	JM4.1, JM4.10	Proposed	2010-03-20
JM5	55	A simple Activity is defined by a simple Job Description containing only ONE local job executed by only ONE batch system	Etienne Urbah	Job Description, Activity Management	JM2	Proposed	2010-03-17
JM5.1	56	The Execution Service SHOULD accept vectors of simple Activities as input parameter for several operations such as Create(), ChangeState(), ActivityStatus(), Cancel(), Purge() (implementation aspect longly discussed in Munich - worth to keep)	Draft Spec	Activity Management	JM5	Proposed	2010-03-17
JM5.2	57	The execution service may have limits with respect to the size of the vector due to implementation aspects and if requests exceed the implementation limits the service communicates this via a fault.	Draft Spec	Activity Management	JM5.1	Proposed	2010-03-20
JM5.3	58	The Execution Service will NOT take into account Collection Activities (these are NOT vectors), which are containers for a limited number of explicitly described independent Single Activities	Draft Spec	Activity Management	JM5	Proposed	2010-03-17
JM5.4	59	The Execution Service will NOT take into account Parameter Sweep Jobs, which describe independent Single Activities to be created dynamically	Draft Spec	Activity Management	JM5	Proposed	2010-03-17
JM5.5	60	The Execution Service will NOT take into account DAG Jobs, which describe a DAG workflow of a limited number of explicitly described Single Jobs	Draft Spec	Activity Management	JM5	Proposed	2010-03-17
JM5.6	61	The Execution Service SHOULD support any Activity running massively-parallel processes using MPI and large-scale HPC Systems	Strawman functionality	Activity Management	JM5	Proposed	2010-03-18
JM6	62	The Execution Service MUST log enough grid information inside logging systems (which MAY vary during the lifetime of the Activity), in order to permit efficient Log analysis and Security audit	Etienne Urbah	Activity Management, Event reports	JM2	Proposed	2010-03-17
JM6.1	63	The Execution Service MUST accept requests querying the Status of an Activity, and MUST return the Activity Status	Draft Spec	Activity Management, Event reports	JM6	Proposed	2010-03-17
JM6.2	64	The Execution Service MUST provide the Activity Status information with different levels of verbosity (basic, detailed, more detailed)	Draft Spec	Activity Management, Event reports	JM6	Proposed	2010-03-18
JM6.3		The Logging & Bookkeeping Service, which consolidates Activity logs from various logging systems, MAY be completely separate from the Execution Service. But the Logging & Bookkeeping Service MAY also be provided by the Execution Service, in which case the Execution Service MUST accept requests for the log of an Activity, and MUST return the Activity log.	Etienne Urbah	Activity Management, Event reports	JM6	Dropped (Rejected, Bad prerequisite on Logging & Bookkeeping Service)	2010-04-23
JM6.4		In order to minimize polling of the Activity Status, the Execution Service MAY implement a mechanism for notification.	Etienne Urbah	Activity Management, Event reports, Notification	JM6	Dropped (Dupl. JM6.5)	2010-04-23
JM6.5	65	In order to minimize polling of the Activity Status, the Execution Service MAY implement a mechanism for notification. Asynchronous notification of Activity status (for example: e-mail, SMS, etc.) - human level notification	NSF 08-571	Activity Management, Notification	JM6	Proposed	2010-03-20
JM6.6		If notification in PGI, then OASIS WS-Notification (automatic notification) might be a good option. BES couldn't decide on a notification mechanism, because too many vendors in the boat. Experience in implementation in Grids present (for example: UNICORE)	NSF 08-571	Activity Management, Notification	JM6	Dropped (Premature, Specification of implementation)	2010-04-23
JM6.7	66	The Instance of Execution Service MUST permit any Client to request the list of all Activities managed by this instance on which the Client has authorization	Strawman functionality	Activity Management	JM6	Proposed	2010-03-18
JM6.8	67	If a Client queries for an already finished Activity, the Execution Service MAY response with an error.	Etienne Urbah	Activity Management, Information Service	JM6	Proposed	2010-03-26
JM6.9	68	The Execution Service MUST accept requests querying the detailed Information of an Activity, and MUST return the detailed Activity Information (more than just the status, for example: GLUE2 Activity). Provide Activity information with different levels of verbosity (basic, detailed, more detailed).	Draft Spec	Activity Management, Information Service	JM6	Proposed	2010-03-20
JM6.10	69	Obtain Activity session directory/staging-directory (maybe as part of more general) information via an Activity ID.	Draft Spec	Activity Management, Data Management	JM4, JM6	Proposed	2010-03-19
JM6.11		For all requests concerning Activities, the Execution Service functionality MUST accept, as input parameter, 1 Activity ID		Activity Management, Information Service	JM4, JM6	Re-proposed	2010-04-26
JM6.12	70	The Execution Service MAY provide the functionality to monitor (poll) the state of activities via filters (defined by queries, i.e. not requiring explicit Activity ID).	Luigi Zangrando	Activity Management, Information Service	JM6	Proposed	2010-03-19
JM6.13	71	The Execution Service MUST provide information about the Activity history (i.e. Activity status) and invoked operations on this Activity (log on ws level?!). Adopt potentially the JSDL instance specification.	Etienne Urbah	Activity Management, Information Service	JM6	Proposed	2010-03-20
JM6.14	72	The execution service MUST publish state information according to the common PGI state model, but status information might be optionally published according to multiple state models.	Draft Spec	Activity Management, Information Service	JM6	Proposed	2010-03-20
JM6.15	73	The execution service should offer more flexibility enabling complex queries on resource and Activity information expressed according to the GLUE2 model without explicit specification of the Activity IDs. The Execution Service MAY support multiple query languages in addition to the mandatory one.	Draft Spec	Activity Management, Information Service	JM6	Proposed	2010-03-20
JM6.16	74	The execution service SHOULD offer separate(!) operations to query Resource and Activity information.	Draft Spec	Activity Management, Information Service	JM6	Proposed	2010-03-20
JM6.17		An Execution Service mechanism in terms of queries should support Xpath 1.0 and MAY support additional query languages such as XQUERY, SQL, sparql and custom defined ones (for example: python-based).		Activity Management, Information Service	JM6	Dropped (Premature, Specification of implementation)	2010-04-23
JM7		The Execution Service MUST provide enough Usage Records as specified by UR to the Accounting Service	Etienne Urbah	Activity Management, Accounting	JM2	Dropped (Dupl. Ac2)	2010-04-23
JM7.1		The Accounting Service MUST be completely separate from the Execution Service. Therefore specifications will NOT take into account Client requests concerning Accounting.	Etienne Urbah	Activity Management, Accounting	JM7	Dropped (Dupl. AC1)	2010-03-17
JM8	75	In order to apply the principle of 'Full Automation of Processing', the Activity State Model SHOULD NOT have 'Hold' States	Etienne Urbah	Activity Management / State Model	Conflicts with JM9	Proposed	2010-03-18
JM9	76	In order to permit the Client to perform client-directed processing of submitted Activities (for example client-directed data staging), the Execution Service SHOULD manage 'Hold' points for Activities. Fault if not supported.	Strawman functionality	Activity Management / State Model	Conflicts with JM8	Proposed	2010-03-18
JM9.1	77	The Execution Service MUST be able to create Activity in 'Hold' state	Draft Spec	Activity Management / State Model	JM9	Proposed	2010-03-19
JM9.2	78	Requirement to have a pending state (i.e. waiting to be scheduled)	Morris Riedel	Activity Management / State Model	JM9	Proposed	2010-03-19
JM9.3	79	When the client wants to perform client initiated data-staging-in, the client MUST also specify in the Job Description via 'Hold' points that the Activity holds.	Draft Spec	Activity Management / State Model, Job Description	JM3, JM9	Proposed	2010-03-20
JM9.4	80	The Execution Service MAY offer the 'Hold' and corresponding 'Resume' functionality of Activity processing. Change state operation to resume a hold execution and to put the Activity into 'Hold'.	Draft Spec	Activity Management / State Model	JM9	Proposed	2010-03-20
JM10	81	On Activity submission, if the Execution Service fails to create the Activity for any reason, the Execution Service MUST return to the Client a descriptive error	General	Activity Management	JM2	Proposed	2010-03-18
JM10.1	82	It is important that optional Job Description elements MUST NOT be ignored by the service and rather throw a corresponding fault in the case that the service does not support this optional client request.	GIN	Activity Management	JM3, JM10	Proposed	2010-03-20
JM11	169	The Execution Service MAY provide its functionalities to Clients through various protocols (RPC, Corba, ActiveMQ, ...), but MUST provide them to Clients through a Web Service	General	Activity Management		Re-proposed	2010-04-26
JM11.1	83	The Execution Service MUST provide to the Client a Web Service using SOAP	Etienne Urbah	Activity Management	JM11	Proposed	2010-03-18
JM12	84	The Execution Service is NOT REQUIRED to provide any service management capability (for example start/stop accepting new Activities).	GIN	Activity Management		Proposed	2010-03-19
JM13	85	Activity recovery via 'changestatus' mechanism after Activity was failed.	Balazs Konya	Activity Management		Proposed	2010-03-19
JM14	86	The Execution Service offers the possibility to 'cancel/terminate/kill/destroy' an Activity. The cancel means that active data-staging processes SHOULD be cancelled and active executions in RMS MUST be cancelled.	Strawman functionality	Activity Management, Data Management		Proposed	2010-03-19
JM15	87	Lease of Activities (several Activities may get purged by the Execution Service if they loose contact with the client or after a timeout), 'automatic cleanup' in case the lease was not renewed	Luigi Zangrando	Activity Management		Proposed	2010-03-19
JM16	88	Request routing capabilities (for example: preferred shares, etc.) - Prepare for TIME CONSUMING DISCUSSIONS	GIN	Activity Management		Proposed	2010-03-19
JM17	89	Request Forwarding capabilities - Prepare for TIME CONSUMING DISCUSSIONS	GIN	Activity Management		Proposed	2010-03-19
JM18	90	Execution Service SHOULD perform validation (potentially several steps). An incomplete validation can be done immediately while a full validation will be only performed asynchronously, as requested by Client	Draft Spec	Activity Management	JM4.1, JM4.10	Proposed	2010-03-19
JM18.1	91	The validation MUST happen as part of the Activity creation and not later. If validation fails, an error has to be provided.	Draft Spec	Activity Management	JM4.1, JM4.10	Proposed	2010-03-20
JM18.2	92	The Execution Service can decide which level of activity validation is appropriate	GIN	Activity Management		Proposed	2010-03-20
JM19	93	The execution service should offer Time estimations to completion of asynchronous operations, such as State change, Cancellation, Purge	Draft Spec	Activity Management		Proposed	2010-03-20
JM20	94	Requirement to have a purge (maybe called wipe) operation. This operation is only allowed on any final state according to the state model. The operation is not supposed to kill Activities, that is why its only allowed on final states.		Activity Management / State Model		Proposed	2010-03-20
JM21	95	Cleanup of BES - a number of compromises were made to satisfy parties, drop, improve, etc. - but not breaking the general BES concept (more on GridForge BES session)	NSF 08-571	Non-functional		Proposed	2010-03-20
JM22	96	If underlying naming and binding mechanism be resilient to failure to migration and replication, for example: create Activity and its decided its to hand it of to another BES and (a) makes this new BES responsible or (b) migrate completely to the new BES (i.e. automatic forwarding). Migration is an important activity not only in compute but also in data.	NSF 08-571	Activity Management, Availability, Resilience		Proposed	2010-03-20
JM23	97	A user should be able to know the full routing of the forwarding actions of Activities by services. JSDL instance is partly tackling this problem.	NSF 08-571	Activity Management, Job Description		Proposed	2010-03-20
JM24	98	The user should be able to contact the end of the path (final) service.	NSF 08-571	Activity Management		Proposed	2010-03-20
JM25	99	StartAccepting and StopAccepting activities might be still required (for example: for Desktop Grids and HTC). Preserve backwards compatibility from PGI perspective.	NSF 08-571	Service Management		Proposed	2010-03-20

JD) Requirements applying mainly to Job Description (2010-03-26: 25 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
JD1		Activities submitted by Clients to an Execution Service MUST be specified using a well-defined Job Description document	Etienne Urbah	Job Description, Activity Management		Dropped (Dupl. JM3)	2010-04-23
JD2		Specifications will NOT take into account JSDL Parameter Sweep Activity Extension	Etienne Urbah	Job Description, Activity Management		Dropped (Dupl. JM5.3)	2010-04-23
JD3	100	The Job Description document MUST reference all grid entities in conformance to the GLUE specification	GIN	Job Description, Information Service		Agreed YES	2010-04-28
JD4	101	The Job Description document specification MUST permit the Client to request automatic data stage-in and stage-out	GIN	Job Description, Activity Management		Agreed YES	2010-04-28
JD5	102	The Job Description document specification MUST permit the Client to request the number of times the Execution Service should perform local automatic resubmission in case of Activity failure	Etienne Urbah	Job Description, Activity Management		Agreed YES	2010-04-29
JD6	103	The Job Description document specification MUST permit the Client to request that at specified Activity states, the Execution service sets the Activity on 'Hold'	Draft Spec	Job Description, Activity Management	JM9	Agreed YES	2010-04-28
JD7	104	The Job Description SHOULD allow to specify n different alternative(!) data sources of any single input data. (Semantics: data may be fetched from some of the alternative sources)	Draft Spec	Job Description, Data Management		Agreed YES	2010-04-28
JD8	105	Job Description supports : 1) Service-directed data-staging (i.e. specify data-stagings), 2) Client-initiated data-staging (i.e. specify data-staging but service will do nothing, only control whether files existing), 3) Manual data-staging (i.e. no specification of data-staging elements)	Draft Spec	Job Description, Data Management, Activity Management	JM9	Agreed YES	2010-04-28
JD9	106	The Job Description SHOULD allow to specify n different data targets of any single output data. Later to be decided how the targets will be handled.	Draft Spec	Job Description		Open (unclear after 10 mn)	2010-04-28
JD10		Specify exactly what happens when one data-staging (sources and target) element can not be satisfied: complete failure? Or continue?		Job Description	JD8, JD9	Dropped (Premature, Specification of Implementation)	2010-04-23
JD11	107	Job Description should be only used for Job Description not for any kind of feedback. Activity status information should not be communicated with a 'changed JSDL'.	Draft Spec	Job Description		Agreed YES	2010-04-28
JD12		Job Description should be only used for Job Description, NOT for any kind of feedback. The main status information should NOT be communicated with a 'changed JSDL'. Job Description MUST be strictly used only for expressing Activity requirements	Draft Spec	Job Description		Dropped (Dupl. JD11)	2010-04-23
JD13	108	Job Description comes with support for requesting multi-processor Activities (for example: threads/node, network topology, task/core mappings, multi-threading and such like)	Strawman functionality	Job Description		Agreed YES	2010-04-28
JD14	109	Job Description document should be with simple structure, which avoids unnecessary overlaps (e.g. memory in different places defined)	GIN	Job Description		Open (NO agreement after 10 mn)	2010-04-28
JD15	110	The PGI Job Description document MUST provide a simple structure for ranges or a proper description of ranges, e.g. simpler than currently defined in JSDL	Draft Spec	Job Description		Open (unclear after 10 mn)	2010-04-28
JD16	111	Job Description document should offer grouped data-stagings for a better clean structure	Draft Spec	Job Description		Open (NO agreement after 10 mn)	2010-04-28
JD17	112	Job Description document should offer a clear separation between resource requirements and application requirements (for example: suggest to put memory information into resource), e.g. improving the JSDL specification in this context (if necessary)	Draft Spec	Job Description		Agreed YES	2010-04-28
JD18	113	Job Description document should offer a new re-usable structure to describe an executable composed as path and argument	Draft Spec	Job Description, Application Repository		Open (unclear after 10 mn)	2010-04-28
JD19	114	Job Description document should offer a new re-usable structure to describe a software requirement, to express relations (OR, AND, GREATER, SMALLER, ...) of software requests and other requests		Job Description	JD24	Agreed YES	2010-04-29
JD20	115	Job Description document should offer a new re-usable structure to define 'scalabletime' requests optionally depending on benchmark results.	Draft Spec	Job Description		Open (unclear after 10 mn)	2010-04-29
JD21		Refinements and Tunings of numerous JSDL elements according to production experience.		Job Description		Dropped (Rejected, NOT precise enough)	2010-04-23
JD22	116	Clearly separate file and directory in the data-stagings., e.g. within the job description there the element are clearly labelled as file or directory , e.g. different aspect of handling directory or a file, you can not differentiate	Draft Spec	Job Description		Agreed YES	2010-04-29
JD23	117	New structure to describe the context in which the Job Description was generated (i.e. meta)	Draft Spec	Job Description		Agreed NO	2010-04-28
JD24	118	Improvement of JSDL specifications in terms of: 'OR' and 'NEGATION', currently there is only 'AND'	NSF 08-571	Job Description		Agreed YES	2010-04-28
JD25		When the client wants to perform client initiated data-staging-in, the client MUST also specify in the Job Description via holdpoints that the Activity holds		Job Description, Activity Management / State Model		Dropped (Dupl. JM9.1)	2010-04-23

SM) Requirements applying mainly to Activity Management / State Model (2010-03-26: 33 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
SM1	119	The Execution service MUST support a common state model	General	Activity Management / State Model		Proposed	2010-03-18
SM2	120	The Execution service MUST expose one or several state where the Activity is finished (with success, error, cancellation, failure, ...)	Etienne Urbah	Activity Management / State Model		Proposed	2010-03-23
SM3	121	The Execution service MUST NOT separate 'Payload Success' (= 'Application Success') and 'Payload Error', which are both detected by the Payload itself, and where Payload and Activity logs are complete	Etienne Urbah	Activity Management / State Model	SM2	Proposed	2010-03-18
SM3.1	122	The State Model for simple Activities MUST have a single state grouping 'Payload Success' and for 'Payload Error'	Etienne Urbah	Activity Management / State Model	SM3	Proposed	2010-03-18
SM3.2		The single state grouping 'Payload Success' and for 'Payload Error' is named 'Finished with Success or Error'	Etienne Urbah	Activity Management / State Model	SM3.1	Dropped (Premature, Specification of implementation)	2010-04-27
SM4	123	The Execution service MUST clearly separate the 2 following concepts : • 'Payload Error', which is detected by the Payload itself, and should be investigated by Application specialists first • 'Activity Abortion', which is caused / managed by the Execution Service, and require grid skills to be investigated	Etienne Urbah	Activity Management / State Model	SM2	Proposed	2010-03-18
SM4.1	124	The State Model for simple Activities MUST have separate states for 'Payload Termination' and for 'Activity Abortion'	Etienne Urbah	Activity Management / State Model	SM4	Proposed	2010-03-18
SM4.2	125	Inside 'Activity Abortion', the Execution service MUST clearly separate the 2 following concepts : • 'Activity Failure', which happens suddenly, is detected by the Execution Service itself, and where Activity logs can be partial or missing • 'Activity Cancellation', which is triggered by the Client, cleanly processed by the Execution Service, and where Activity logs are complete	Etienne Urbah	Activity Management / State Model	SM4.1	Proposed	2010-03-18
SM4.3		The state for 'Activity Failure' is called 'Failed'	Etienne Urbah	Activity Management / State Model	SM4.2	Dropped (Premature, Specification of implementation)	2010-04-27
SM4.4		The state for 'Activity Cancellation' is called 'Canceled'	Etienne Urbah	Activity Management / State Model	SM4.2	Dropped (Premature, Specification of implementation)	2010-04-27
SM5	126	On Activity failure, the Execution service MAY, as many times as specified in the Job Description document, perform an automatic resubmission of the Activity by setting the Activity state to 'Submitted'	General	Activity Management / State Model	JD5	Proposed	2010-03-18
SM6		The Execution Service MUST have an 'Output Data Retrieval' functionality : When the Activity is finished (with success, error, cancellation, failure, ...), if the Execution Service keeps Data related to the Activity (for example an 'Output Sandbox'), then the Execution Service MUST allow the Client to request the retrieval of this Activity Data, and the Execution Service MUST send this Activity Data to the Client	Etienne Urbah	Activity Management / State Model, Data Management	SM2	Dropped (Duplicate)	2010-04-27
SM6.1		The Execution Service MUST have a 'Purge' functionality : When the Activity is finished (with success, error, cancellation, failure, ...), the Execution service MUST be able, after the Client has retrieved Output Data of the Activity or after a long delay, to purge the Activity, that is to delete all Data related to the Activity (but the Execution service MUST NOT delete the Activity log).	Etienne Urbah	Activity Management / State Model, Data Management	SM6	Dropped (Duplicate)	2010-04-27
SM6.2		After the Execution Service has purged an Activity, the Activity log and Accounting MUST still be accessible (this MAY be achieved, for example, by separate 'Logging & Bookkeeping' and 'Accounting' services)	Etienne Urbah	Activity Management / State Model	LB1, SM6.1, conflicts with SM6.3	Re-proposed	2010-04-28
SM6.3		After an Activity has been purged, the Execution Service SHOULD NOT keep any information on this Activity, and SHOULD answer to any request on this Activity with an error message		Activity Management / State Model	SM6.1	Re-proposed	2010-04-28
SM6.4	127	Requirement to have a 'Purged' state, where 'Purge' refers to cleanup the whole existence of an Activity	General	Activity Management / State Model	SM6	Proposed	2010-03-18
SM7	128	The Execution service MUST clearly separate the 2 following high level Activity states : • 'Activity Submitted', where the Activity is (at least partially) validated, but storage / computing resources have perhaps NOT been allocated to the Activity yet • 'Activity Processing', where the Activity has already been fully validated, and storage / computing resources are being allocated or have already been allocated	Etienne Urbah	Activity Management / State Model		Proposed	2010-03-18
SM7.1		The state for 'Activity Submitted' is called 'Submitted'	Etienne Urbah	Activity Management / State Model	SM7	Dropped (Premature, Specification of implementation)	2010-04-27
SM8	170	In order to permit the Client to perform direct manual processing inside submitted Activities (for example manual data staging), the State Model MUST contain • one State permitting manual processing before Payload execution • one State dedicated for Payload execution • one State permitting manual processing after Payload execution	Etienne Urbah	Activity Management / State Model		Re-proposed	2010-04-28
SM8.1		The state for 'Manual processing before Payload execution' is called 'Pre-processing'	Etienne Urbah	Activity Management / State Model	SM8	Dropped (Premature, Specification of implementation)	2010-04-27
SM8.2		The state for 'Payload execution' is called 'Delegated'	Etienne Urbah	Activity Management / State Model	SM8	Dropped (Premature, Specification of implementation)	2010-04-27
SM8.3		The state for 'Manual processing after Payload execution' is called 'Post-processing'	Etienne Urbah	Activity Management / State Model	SM8	Dropped (Premature, Specification of implementation)	2010-04-27
SM9		The Execution service MUST set the Activity on 'Hold' at the Activity states specified inside the Job Description document	Etienne Urbah	Activity Management / State Model, Job Description	JM9, JD5	Dropped (Duplicate)	2010-04-27
SM9.1	129	Following Activity states MUST permit 'Hold' : 'Pre-processing', other active states, 'Post-processing'	General	Activity Management / State Model	SM8, SM9	Proposed	2010-03-18
SM9.2		The 'Submitted' Activity state MUST also permits 'Hold'	Etienne Urbah	Activity Management / State Model	SM9	Dropped (Premature, Specification of implementation)	2010-04-27
SM9.3	130	For each state permitting 'Hold', the 'Hold' state MUST be implemented as a substate	General	Activity Management / State Model	SM9	Proposed	2010-03-18
SM10		The Execution service MUST allow the Client to request a transition between Activity states	Etienne Urbah	Activity Management / State Model		Dropped (Duplicate)	2010-04-27
SM10.1	131	The Execution service MUST perform the transition between Activity states requested by the Client ONLY if it makes sense. Otherwise, the Execution service MUST return an error to the Client.	General	Activity Management / State Model	SM10	Proposed	2010-03-18
SM11	132	By default, the Activity should not end up in a 'Hold' state.	General	Activity Management / State Model		Proposed	2010-03-19
SM12	133	State model should enable the monitoring of the data-staging process (i.e. more feedback to the end-user via substates or similiar methods)	GIN	Activity Management / State Model	SM8	Proposed	2010-03-19
SM13	134	The Execution Service SHOULD have a hierachical state model consisting of 1-st level, 2nd-level, 3rd-level, ....states. Lower level states always sub-states of their parent-state.	Strawman Functionality	Activity Management / State Model		Proposed	2010-03-20
SM13.1	135	First two levels are mandatory or a reasonable level.	Draft Specification	Activity Management / State Model	SM13	Proposed	2010-03-20
SM14		Maybe a realization w/o hierarchical state models.		Activity Management / State Model		Dropped (Duplicate SM13)	2010-04-27

DM) Requirements applying mainly to Data Management (2010-03-26: 17 Req.)

Nb	ID	Description	Source	Areas	Dependencies	Status	Date
DM1		During Activity submission, the Execution Service MUST permit the Client to transfer small files from the Client's local storage to the Execution Service (for example the 'Input Sandbox'). Once the Execution Service has allocated an adequate Storage Resource to the Client's Activity, the Execution Service MUST transmit these small files to this Storage resource.	Etienne Urbah	Data Management, Activity Management		Dropped (Duplicate)	2010-04-27
DM2		The Execution Service MUST perform service-directed (was automatic) data staging in and out.	Etienne Urbah	Data Management, Activity Management	JD4	Dropped (Duplicate)	2010-04-27
DM3	136	The Execution Service MUST have an 'Output Data Retrieval' functionality : When the Activity is finished (with success, error, cancellation, failure, ...), if the Execution Service keeps Data related to the Activity (for example an 'Output Sandbox'), then the Execution Service MUST allow the Client to request the retrieval of this Activity Data, and the Execution Service MUST send this Activity Data to the Client	General	Data Management, Activity Management / State Model		Proposed	2010-03-18
DM4		In order to apply the principle of 'Full Automation of Processing' and to prevent too much complexity inside the Activity State Model, specifications will NOT take into account 'Hold' points for Activities	Etienne Urbah	Data Management, Activity Management		Dropped (Dupl. JM8)	2010-03-18
DM5		In order to permit the Client to perform manual data staging, the Execution Service MAY manage 'Hold' points for Activities. Fault if not supported.	Etienne Urbah	Data Management, Activity Management / State Model	JD6	Dropped (Dupl. JM9)	2010-03-18
DM5.1	137	If the Execution Service manages 'Hold' points for Activities, it SHOULD be able to detect which computing resources (GLUE ExecutionEnvironments) run several Activities per core, and which run at most 1 Activity per core	Etienne Urbah	Data Management, Activity Management	DM5	Proposed	2010-03-18
DM5.2	138	If the Execution Service has detected that the computing resource runs several Activities per core, then the Execution Service MAY set running Activities to a 'Hold' State (waiting for Client action) without under-utilizing available cores	Etienne Urbah	Data Management, Activity Management	DM5	Proposed	2010-03-18
DM5.3	139	If the Execution Service has detected that the computing resource runs at most 1 Activity per core, then the Execution service SHOULD prevent running Activities to go to a 'Hold' State (waiting for Client action), in order to prevent under-utilizing available cores	Etienne Urbah	Data Management, Activity Management	DM5	Proposed	2010-03-18
DM5.4	140	If the Execution Service is NOT able to detect if the computing resource runs several Activities per core or only 1, then the Execution service SHOULD prevent running Activities to go to a 'Hold' State (waiting for Client action), in order to prevent under-utilizing available cores	Etienne Urbah	Data Management, Activity Management	DM5	Proposed	2010-03-18
DM6		In order to permit the Client to perform manual data staging, the Execution service MUST allow the Client to request information about Storage resources allocated to the Activity, and return the requested information (or an warning if Storage resources have NOT been allocated yet)	Etienne Urbah	Data Management, Activity Management		Dropped (Duplicate)	2010-04-27
DM6.1	171	One of the storage resources allocated to the Activity MUST be named 'Session Directory'	Etienne Urbah	Data Management, Activity Management	DM5, DM6	Re-proposed	2010-04-28
DM6.2		If the Execution Service manages 'Hold' points for Activities, it MAY also be able to verify that manual data staging is really complete, and keep the Activity on 'Hold' otherwise	Etienne Urbah	Data Management, Activity Management	DM5, DM6	Dropped (Premature, Detailed specification)	2010-04-27
DM7	141	Any client should be able to interact with the 'session directory' of any Activity created by the Execution Service	GIN	Data Management, Activity Management	DM6, DM6.1	Proposed	2010-03-19
DM8	142	The Execution Service MUST support client-directed data staging in and out by exposing the locations of the Activity processing directory/session directory.	GIN	Data Management, Activity Management		Proposed	2010-03-19
DM9	143	Data Staging MUST support the following protocols (not defined in the document, added by Grimshaw to start discussion): HTTP(S), scp, gridftp, mailto, RNS/ByteIO	GIN	Data Management		Proposed	2010-03-18
DM10	144	Minimize the amount of calls required to interact with Execution Service (for example: in one WS: vector operations, service exposes the location where the client can stage any input data, service exposes the location where the client can fetch any output data.)	GIN	Data Management, Activity Management		Proposed	2010-03-19
DM11		In the context of data, any kind of data that has been marked as stage-in or any kind of temporarily generated data is not available for example: when activities enter the 'cancelled' state (or other final states?!). Data that is marked as stage-out, on the other hand, MUST be available if present.		Data Management, Activity Management		Dropped (Premature, Detailed specification)	2010-04-27

Show Details