GFD 210
GFD 210
GFD 210
210 Editors:
PGI EMI-ES Morris Riedel, JSC/FZJ
OGF – Production Grid Infrastructure Aleksandr Konstantinov, UoLund
http://redmine.ogf.org/projects/pgi-wg 31 March 2013
Category: INFORMATIONAL
Abstract
The Production Grid Infrastructure (PGI) working group works on a well-defined s et of standard profiles, and
additional standard specifications if needed, for job and data management that are aligned with a Grid
security and information model that addresses the needs of production Grid infrastructures. These needs
have been identified in various international endeavors and are in many cases based on lessons learned
obtained from the numerous activities in the Grid Interoperation Now (GIN) community group. Therefore, PGI
can be considered as a spin-off activity of the GIN group in order to feed back any experience of us ing early
versions of open standards (e.g. BES, JSDL, SRM, GLUE2, UR, etc.) in Grid production setups to improve
the standards wherever possible. This particular document captures the a reasonable stable draft of the
execution service specification of the European Middleware Initiative (EMI) that has been created based on
many identified PGI concepts. A complementary implementation of this draft specification is provided by the
EMI project including adoptions in ARC, gLite, and UNICORE. The goal of this document is to c apture
community practice and to have a foundation for a set of important standard specification updat es to be
addressed by the P GI set of profiles and/ or specifications of the corresponding related groups (e.g. BES,
JSDL, etc.).
pgi-wg@ogf. org 1 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Cont ents
1. Introduction ..................................................................................................................................... 3
2. Interface: Creation Port-Ty pe ............................................................................................................ 7
3. Interface: ResourceInfo Port-Ty pe................................................................................................... 10
4. Interface: ActivityManagement Port-Type ........................................................................................ 13
5. Interface: ActivityInfo Port-Ty pe ...................................................................................................... 24
6. Interface: Delegation Port-Type....................................................................................................... 26
7. Activity State Model ........................................................................................................................ 32
8. Resource and Activity Representation ............................................................................................. 36
9. Activity Description......................................................................................................................... 47
10. Security Consideration ................................................................................................................ 58
11. Outlook and list of deferred issues ............................................................................................... 59
12. Editor Information ....................................................................................................................... 60
13. Authors ...................................................................................................................................... 60
14. Acknowledgments....................................................................................................................... 61
15. Intellectual Property Statement .................................................................................................... 61
16. Full Copyright Notice................................................................................................................... 61
17. Referenc es................................................................................................................................. 61
pgi-wg@ogf. org 2 / 61
PGI EMI-ES GFD-I.210 31 March 2013
1. Introduction
This document provides the interface specification, including relat ed data models such as state model,
activity description, and resource and activity information, of an execution service, matching the needs of the
EMI production middleware stack composed of EMI products including A RC, gLite and UNICORE
components. This service therefore is referred to as the EMI Execution Servic e (or “ES” for short).
This document is a continuation of the work previously knows as the GENEVA, then AGU (“A RC, gLite
UNICORE”) [1], then PGI execution service. As a starting point, the v0.42 of the “P GI Execution Service
Specification” (doc15839) was used. This particular P GI document is bas ed on the EMI-ES specification
version 1.16.
The targets for this specification are the so -called Computing Elements (CEs), that is Grid services providing
access to computing resources usually localized at a site (e.g. a cluster, a computing farm), usually managed
by a Local Resource Management System (LRMS). Higher level services (suc h as workload managers,
brokering servic es, or workflow systems) are out of scope.
This document covers the following items:
Interfaces to create and manage activities
Activity description language (“EMI-A DL”), an XML dialect for describing the activity including data
staging and resourc e requirements
Data staging capabilities
Activity related information, that can be ret rieved by clients
Resource related information, required for clients to access information relevant for making brokering
and resource selection decisions
Delegation, needed to implement data staging
The relations hips between these “elements” are shown in Figure 1 below.
An Execution S ervice can be implement ed using different security setups (see S ecurity Considerations).
Therefore it is assumed that the clients obtain security setup info through out -of-band mec hanisms which are
not covered by this specification.
Resource and activity information is provided according to the GLUE2 specification 61 with some extensions,
more specifically its XML rendering.
Several items were considered during the preparation of this version of the specific ation, but were postponed
to a later version. A full list of these items is provided in Section 11.
pgi-wg@ogf. org 3 / 61
PGI EMI-ES GFD-I.210 31 March 2013
1.2 Architecture
The EMI-ES consists of five main modules. These modules offer differe nt functionalities realized as
independent port -types, and can be grouped and offered via independent services, usually on the same
machine, eventually running separat ely on different machines.
Each of them implements a set of operations. The following des cribes each module's purpos e and the
operations corresponding to each port-type.
• ActivityCreation port-type: CreateActivity
• ResourceInfo port-type: GetResourceInfo, QueryResourceInfo
• ActivityManagement port-type: GetActivityStatus, GetActivityInfo, NotifyService, PauseActivity,
ResumeActivity, CancelActivity, WipeActivity, RestartActivity
• ActivityInfo port -type: ListActivities, GetActivityStatus, GetActivityInfo
• Delegation port-type: InitDelegation, PutDelegation, Get DelegationInfo
For convenience, some (GetActivityStatus and GetActivityInfo) operations can be accessed via both the
ActivityManagement and ActivityInfo port-types.
It must be stressed that the ResourceInfo port-type refers only to information related to the Computing
Element and it does not contain information about activities. Activities information can be retrieved using the
ActivityInfo port -type.
This section describes the data staging functionality of the EMI Execution Service.
As entities to be considered for data staging, we refer to files.
We consider here only data staging done before or after job execution. Of course the job itself is free to do
any data staging during its execution, but this is not something implement ed using functionality provided by
the EMI ES.
We call stage-in directory the place offered t o clients to upload data. This is also the place to which t he ES
may pull input data in the “server data pull” stage -in scenario (see below). This directory is created by the ES
and either returned as part of the CreateActivity response or obtainable from GetActivityInfo. There is a
single stage-in directory per activity, possibly accessible by multiple protocols (in future specifications it will
be investigated the possibility to have different stage-in directories for the different data objects). The
Execution Service MUS T provide this directory when entering the PREPROCESS ING phase of states.
We call stage-out directory the place where the output data are collected and can be retrieved from the
client. It is used for the “client data pull” scenario (see below). Output data for the “server data push” scenario
(see below) can also appear in this directory. This directory is created by the ES and either returned as part
of the CreateActivity response or obtainable from GetActivityInfo. There is a single stage-out directory per
activity, possibly accessible by multiple protocols (in future specifications it will be investigated the possibility
to have different stage-out directories for the different data objects). The Execution Service MUS T provide
this directory upon entering the POS TP ROCESSING phase of states.
We call se ssion directory the directory on t he worker node where the us er job is executed. The provision of
access to the end user to this session directory (which in general can not be accessible from the Execution
Service) is optional. The access to the session directory enables client to access and modify the content of
pgi-wg@ogf. org 4 / 61
PGI EMI-ES GFD-I.210 31 March 2013
the session directory between stage-in and stage-out states. The session directory address is published as
part of activity info. The possibility of accessing the session directory provides some sort of interactivity. The
Execution Service MUS T provide this directory in the PROCESS ING phase of states.
For what concerns stage-in, that is the staging of input data to the execution service done before job
execution, there are two possible scenarios:
1. Server data pull: the ES pulls the needed data from the specified (in the activity description
document) sources and makes them available later in the session directory. These data MAY be
first uploaded into the stage-in directory. This “server data pull” scenario requires delegation
support, since the server has to act on behalf of the activity owner. Server data pull takes place
in the preprocessing or proce ssing-running state. The server-stagein attribute is used to
report about this server-initiated data transfer.
2. Client data push: The client uploads the data into the stage-in directory. The activity description
MUS T contain a flag informing the server that the client wishes to push data (attribute
Client DataPush of the DataStaging element, see section 55). When done with data push, the
client explicitly tells the server to continue processing t he activit y via the NotifyService operation.
The data to be pushed MAY be declared in the activity description. In this case, client
implementations MUS T stage-in all the declared files. Data can be pus hed when the stage -in
directory has been creat ed, and the activity is in a state with the client-stagein-possible
attribute set.
For what concerns stage-out, that is the staging of output data from the execution service done after job
execution, there are two possible scenarios:
1. Server data push: the ES pushes the relevant data to the specified (in the activity
description document) targets. The “server data push” scenario requires delegation support,
since the server has to act on behalf of the activity owner. Tak es place when the server-
stageout state attribut e is set.
2. Client data pull: the client pulls the data from t he stage -out directory of the ES. The downloading
MUS T take place in states with the client-stageout-possible state attribute set. The data to be pulled MUS T
be declared in the activity description.
pgi-wg@ogf. org 5 / 61
PGI EMI-ES GFD-I.210 31 March 2013
The Execution Servic e should properly advertise data staging capabilities as part of the res ource information.
Because one can't expect all implementations to be capable of supporting the same set of data trans fer
capabilities there must be a way for execution service to announce its capabilities and their possible
combinations (e.g.: stage-out-to-https).
For what concerns the handling of failures:
• If there is a failure during “server pull” stage-in, the activity is moved to terminal state
with one of *-failure attributes set and the user job is not run at all.
• If t here is a failure during execution of t he user job, the user can decide for each data
object whether stage-out should be performed, see the UseIfFailure attribute (section
57).
• If there is a failure during the stage out of a file, activity will go into the terminal with
postproce ssing-failure attribute. At any rate the stage out process must be done for all
the other data output objects (i.e. it must not stop at the first data stage out failure)
If the activity is cancelled during user job execution, the ES can optionally (configurable in the activity
description document, see attribute UseIfCancel, section 57) t ry to carry out the stage-out phase. Possible
options that could be specified for each data object in case of job cancellation are:
• Don't try the stage-out
Let the output objects available in the stage -out directory (even for the “server data push” scenario) for
manual download
1.4 Delegation
Clients need t o be able to pass delegation tokens to the ES. The ES uses those tokens to access third party
services, mostly storage services. This is needed in particular to support “server data pull” and “server data
pull” staging scenarios (see Sect. 1.3).
There are two main delegation tokens considered:
• X.509 proxy credentials (proxies): the content of the proxy is well agreed while the trans fer of the
proxy is not agreed (i.e. no standard exists for that ). Two solutions to “transfer” proxies are in use:
• GSI mechanisms, i.e. via a modified SSL protocol which is not compatible with off-the-shelf, industry-
standard SSL .
• Service-specific interfaces
• SAML: transferred as part of SOAP communication. The content of SAML token is NOT standardized
(EMI may offer a common profile). The trans fer mechanism is instead standardized.
There are several “consumers” of X. 509 delegation tokens, e.g. GridFTP, SRM, LFC, LB servers. Instead
currently there aren't yet EMI services (apart from the UNICORE services) that are able to consume SAML
tokens.
For this reason, the scope of delegation in this specific ation refers only to X.509 proxy token delegation
(SAML tokens will be supported in future versions of the EMI ES specification).
Only RFC3820 proxies are allowed. Any extension is allowed. Extensions marked as “must” must be
understood, otherwise the service must throw failure.
The ES MUS T support the direct “pus h” of X. 509 proxy tokens to the ES directly from the client.
Section 6 describes the details of the delegation model.
pgi-wg@ogf. org 6 / 61
PGI EMI-ES GFD-I.210 31 March 2013
The following Figure 3 illustrat es the activity creation and validation process, and the client intera ctions
required for client data push.
pgi-wg@ogf. org 7 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Request
The CreateActivity() operation has one mandatory input parameter:
Vector of activity descriptions composed of one activity description document per element that is
compliant wit h Section 9 of this specification.
Response
The response of the CreateActivity operation returns a vector of values in the same order as in the request;
each value is as follows:
• For those activities for which the activity creation was successful the execution s ervice returns the
following:
• It MUS T ret urn an activityID assigned to the activity and uniquely identifying it inside the service
• It MUS T ret urn the ActivityManagement Endpoint URL t hat MUS T be contacted to manage the
activity.
• It MUS T ret urn the Res ourc eInfo Endpoint URL that MAY be contacted to retrieve CE information.
• It MUS T ret urn the current activity state
• It MAY return the estimated time of the next state change
• It MAY return the stage-in directory and/or the session directory and/or the stage -out directory,
which are accessible via possibly multiple prot ocols
• For those activities for which the activity creation failed the execution service SHOULD return one
of the following
◦ For those activities where the service could perform validation and t he activity description is
not compliant with the EMI-A DL schema, the servic e must return a respons e containing the
message error InvalidActivityDescriptionFault
◦ For t hose activities where the service could perform validation and the activity description
contains a semantic error that occurs during the semantic validation step (see below), the
service MUS T return a response message error InvalidActivityDescriptionSemanticFault
◦ For those activities where the activity description requests a capability that is not provided by
the service, the service MUS T return a response containing a message error
UnsupportedCapabilityFault.
◦ For those activities which can't be processes due internal access control decisions specific
to those activities the service MUS T return a response cont aining a message error
AccessControlFault.
◦ In all other cases where activity could not be created error message InternalBaseF ault is
used.
In cas e the number of submitted activities is too large, instead of CreateActivity respons e the service MUS T
return SOAP fault V ectorLimitExceededFault, which c ontains the maximal allowed number of activity
descriptions per single Creat eActivity request. In this case the service MUS T NOT attempt to create any
activities.
Faults
All faults returned by all EMI ES operations are derived from InternalBaseFault. This base fault provides
numerical FailureCode of fault, short textual Message and lon ger Description. All these values are
implementation specific and are not defined in this doc ument. The base fault also provides Timestamp of
when failure happened. Other kinds of faults may also provide additional information.
AccessControlFault – client is not allowed to perform CreateActivity operation.
VectorLimitExceededFault – number of elements in request exceeds allowed one.
InternalBaseFault – any other failure preventing service from processing all activities.
pgi-wg@ogf. org 8 / 61
PGI EMI-ES GFD-I.210 31 March 2013
pgi-wg@ogf. org 9 / 61
PGI EMI-ES GFD-I.210 31 March 2013
The resource information served by this port-type refers only to information relat ed to the Computing
Element, represented via a “res ourc e document” c omposed of GLUE2 entities and attributes. It MUS T
contain information related t o all EMI-ES port-types regardless whether these are hosted by a s ingle service
or deployed in a distributed fashion. The document MAY contain ot her non EMI -ES endpoints and resource
information in case these are hosted by the same services running EMI-ES. The documents MUS T NOT
include information about activities (not even the list of activity ids).
• The respons e MUS T include the resource doc ument as described in Section 8.1.
• In case of no possibility to return a c omplet e res ource document, an appropriate fault MUS T be
returned.
Faults
InternalResourc eInfoFault – servic e failed to generate/ retrieve requested information
ResourceInfoNotFoundFault – service has no information to report and this is not information
generation fault
AccessControlFault – client is not allowed to perform Get Resorc eInfo operation
InternalBaseFault – any other failure preventing service from performing request
pgi-wg@ogf. org 10 / 61
PGI EMI-ES GFD-I.210 31 March 2013
<URL>https://somehost.somedomain:8000/ActivityManagement</URL>
</Endpoint3>
<Endpoint4 Delegation>
<URL>https://somehost.somedomain:8000/ Delegation</URL>
</Endpoint4>
</ComputingService>
<Service JobInfo>
<Endpoint ActivityInfo >
<URL>https://otherhost.otherdomain: 8111/ActivityInfo</URL>
</Endpoint>
</Service>
</Services>
</GetResourceInfoResponse>
pgi-wg@ogf. org 11 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Response
Faults
NotValidQueryStatementFault – the query expression is not recognized as valid query for specified query
dialect
InternalResourc eInfoFault – servic e failed to generate/ retrieve requested information
ResourceInfoNotFoundFault – service has no information to report and this is not information generation fault
AccessControlFault – client is not allowed to perform QueryResourceInfo operation
pgi-wg@ogf. org 12 / 61
PGI EMI-ES GFD-I.210 31 March 2013
4.1 PauseActivity
Functionality
This operation requests to stop execution of the activity (stop whatever the service was doing). It may be
not possible for service to perform stop immediately. For example it takes time to propagate a stop request
to the underlying batch system. In such case the service MUS T inform the cli ent that the operation is going
to happen asynchronously and optionally provide estimated time.
Depending on implementations and execution environment it may be not possible to perform a stop in a
particular state. In such a case either the request fails and the service informs the client about that, or the
service performs the request asynchronously and stops processing in the next state. The last case should
be acceptable only in very short transitional states.
If during application of PauseActivity request failure happens and the activity is transferred to one of states
applicable for failure processing, the request to stop processing is still applicable unless that new state is
terminal.
The following list describes the effect of PauseActivity on various states:
accepted state - any activity validation and provisioning stops. Once the activity processing is paused the
service assigns the activity client-paused attribut e.
preproce ssing state – any provisioning and data staging activities are stopped. Once the activity processing
is paused the service assigns the activity client-paused attribut e.
proce ssing-accepting – the job submission procedure to batch system is stopped. Once the job processing
is paused the service assigns the activity client-paused attribute. Not e: it is highly likely that due to short
lifetime of this state service will choose to stop activity processing in next proce ssing-queued state.
proce ssing-queued – the batch system is informed to pause processing of the job. If the batch system does
not support such functionality, the request fails. Once job processing is paused the service assigns the
activity the client-paused attribut e.
proce ssing-running – the batch system is informed to pause ex ecution of t he job. If the batch system does
not support suc h functionality the request fails. Once job processing is paused the service assigns the
activity the client-paused attribut e.
postproce ssing – any de-provisioning and data staging activities are stopped. Once proc essing is paused
the servic e assigns the activity the client-paused attribute.
terminal – not applicable.
Request
vector of activityID elements
Response
The respons e of the PauseActivity() operation returns a list of values; each value is as follows:
• For those activities which can be paused, the exec ution service should return information on the
timing in which the pause will be done (i.e., whether the activity has already been paused, or pause
will be attempted in the future)
• Time estimation: E TP - Estimated time to pause, with the following special values:
◦ 0 means already paused (i.e. immediately),
◦ undefined if the service is not able to perform an estimation
• For those activities which cannot be paused, an appropriate error element is returned
◦ ActivityNotFoundFault – specified activityID does not match any known activity
◦ OperationNotPossibleFault – operation can't be performed because properties of activity
somehow prevent it
◦ OperationNotAllowedFault - operation can't be performed because activity is not in suitable
pgi-wg@ogf. org 13 / 61
PGI EMI-ES GFD-I.210 31 March 2013
state
◦ AccessControlFault - operation can't be performed due to internal access control decisions
specific to this activity
◦ InternalBaseFault – any other error preventing service t o perform operation on specific
activity
Faults
AccessControlFault – client is not allowed to perform PauseActivity operation.
VectorLimitExceededFault – number of elements in request exceeds allowed one.
InternalBaseFault – any other failure preventing service from processing all activities.
pgi-wg@ogf. org 14 / 61
PGI EMI-ES GFD-I.210 31 March 2013
4.2 ResumeActivity
Functionality
This operation is the counterpart of Paus eActivity. It instructs the service to remove the client-paused
attribute of the activity state. This will resume activities stopped as result of a PauseActivity operation. This
operation may be processed asynchronously. Whether activity processing is resumed exactly at the place
where it was stopped or there is some activity repeated is implementation specific. But the final result must
be independent of whether the activity was paused or not.
Request
vector of activityID elements
Response
The respons e of the ResumeActivity() operation returns a list of values; each value is as follows:
• For those activities which can be resumed, the execution service should return information on the
timing in which the resuming will be done (i.e., whether the activity has already been resumed, or
resume will be attempted in the fut ure).
• Time estimation: E TP - Estimated time to resume, with the following special values:
◦ 0 means already resumed (i.e. immediately),
◦ undefined if the service is not able to perform an estimation
• For those activities which cannot be resumed, an appropriate error element is returned
◦ ActivityNotFoundFault – specified activityID does not match any known activity
◦ OperationNotPossibleFault – operation can't be performed because properties of activity
somehow prevent it
◦ OperationNotAllowedFault - operation can't be performed because activity is not in suitable
state
◦ AccessControlFault - operation can't be performed due internal access control decisions
specific to this activity
◦ InternalBaseFault – any other error preventing service t o perform operation on specific
activity
Faults
AccessControlFault – client is not allowed to perform Res umeActivity operation.
VectorLimitExceededFault – number of elements in request exceeds allowed one.
InternalBaseFault – any other failure preventing service from processing all activities.
pgi-wg@ogf. org 15 / 61
PGI EMI-ES GFD-I.210 31 March 2013
4.3 NotifyService
Functionality
The operation is used to notify the service that the client completed an operation. It is in particular used
to notify the service when the client completed the client data push or client data pull.
Data-Staging Implications
As discussed in section 1.3, there are two possible approaches for data stage in:
• Server data pull
• Client data push
In the client data push, the user is supposed to upload the needed data in the stage-in directory as soon
as the activity reaches a status with the client-stagein-possible flag. When the client has completed
this data push, it MUST inform the service (with the NotifyService operation) that it c ompleted the stage
in. Otherwise the activity won't proceed its processing.
Similarly, there are two possible approaches for data stage out:
• Server data push
• Client data pull
In the client dat a pull, the user is supposed to retrieve the out put data from the stage-out directory as soon
as the activity reaches a status with the client-stageout-possible flag. When the client has completed the
data pus h, it CAN (it is not mandatory) inform the service (with the NotifyClient operation) that it completed
the stage out.
Request:
This operation accepts as input a vector where each element of it contains:
• The activityID
• A string, which specifies what the client wants to notify service about. This string allows for one
of the possible values:
• client-datapull-done: this is used to notify the service that the client has completed the
client data pull action
• client-datapush-done: this is used to notify the service that the client has completed
the client data push action
Response:
The respons e of the NotifyService op eration returns a vector of values; one per input element with each
value as follows:
• For those activities for which the notific ation has been accepted, an acknowledgement is returned
• For those activities for which the notification could not be accepted, an appropriate error element is
returned
◦ ActivityNotFoundFault – specified activityID does not match any known activity
◦ OperationNotPossibleFault – operation can't be performed because properties of activity
somehow prevent it
◦ OperationNotAllowedFault - operation can't be performed because activity is not in suitable
state (like client-datapush-done notification while activity is in postproce ssing state)
◦ AccessControlFault - operation can't be performed due internal access control decisions
specific to this activity
◦ InternalNotificationFault - any other failure preventing servic e to perform operation on
specific activity and related to notification functionality
◦ InternalBaseFault – any other error preventing service t o perform operation on specific
activity
pgi-wg@ogf. org 16 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Faults
• VectorLimitExceededFault – request contains vector with too many elements (see CreateActivity)
• AccessControlFault – client is not allowed to perform NotifyService operation
• InternalNotificationFault - any other failure preventing service from processing all activities and
related to notification functionality
• InternalBaseFault – any other failure preventing service from processing all activities
pgi-wg@ogf. org 17 / 61
PGI EMI-ES GFD-I.210 31 March 2013
pgi-wg@ogf. org 18 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Functionality
This operation can be used to request the complete removal of a set of activities, including the activity -
related information as well as the removal of all temporary data associated with these activities. As a res ult
of this operation, the activity disappears from the service environment and thus no further operations can be
invok ed on wiped activity identifiers.
Data-Staging Implications
In the context of dat a, any kind of data (i.e. stage -in directory, stage-out directory, session directory) or any
kind of temporarily generated data is NOT available after the invocation of the WipeActivity() operation.
State Model Implications
This operation is only allowed on any final (terminal) state according to the state model. If the activity is
not in any final state yet, the service must return error element OperationNotAllowedFault
Request
The input parameter is a vector of activity identifiers. Other mechanisms of specifying a subset of the
affected activity identifiers (e.g. filtering, grouping) are considered t o be out of scope, bec ause of simplicity
of the service int erface itself.
Response
The respons e of the WipeActivity() operation returns a list of values; each value is as follows:
• For those activities which can be wiped out, the execution service should return information on the
timing in which the activities will be no longer in the system (i.e., whet her the activity has already been wiped
out, or it will be attempt ed in the future);
• Time estimation: E TW - Estimated time to wipe out the activity , special values: 0 means
already wiped (i.e. immediately), undefined if the service is not able to perform an
estimation
• For those activities which cannot be wiped out, an appropriat e error element is returned
◦ ActivityNotFoundFault – specified activityID does not match any known activity
◦ OperationNotPossibleFault – operation can't be performed because properties of activity
somehow prevent it
◦ OperationNotAllowedFault - operation can't be performed because activity is not in suitable
state (one of terminal states)
◦ AccessControlFault - operation can't be performed due internal access control decisions specific to
this activity
◦ InternalBaseFault – any other error preventing service to perform operation on specific activity
Faults
AccessControlFault – client is not allowed to perform WipeActivity operation.
VectorLimitExceededFault – number of elements in request exceeds allowed one.
InternalBaseFault – any other failure preventing service from processing all activities.
pgi-wg@ogf. org 19 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Response
The respons e of the RestartActivity operation returns a vector of values; each value is as follows:
• For t hose activities which can be restarted, the execution service should return time estimation in
which the restart will be done;
• EstimatedTime: estimated time resta rt the activity , special values: 0 means already
restarted (i.e. immediately), undefined if the servic e is not able to perform an estimation
• For those activities which cannot be restarted, an appropriate error element is returned
◦ ActivityNotFoundFault – specified activityID does not match any known activity
◦ OperationNotPossibleFault – operation can't be performed because properties of activity
somehow prevent it
◦ OperationNotAllowedFault - operation can't be performed because activity is not in suitable
state
◦ AccessControlFault - operation can't be performed due internal access control decisions specific to
this activity
◦ InternalBaseFault – any other error preventing service to perform operation on specific activity
Faults
OperationNotPossibleFault – if service does not support this operation
AccessControlFault – client is not allowed to perform RestartActivity operation.
VectorLimitExceededFault – number of elements in request exceeds allowed one.
InternalBaseFault – any other failure preventing service from processing all activities.
pgi-wg@ogf. org 20 / 61
PGI EMI-ES GFD-I.210 31 March 2013
pgi-wg@ogf. org 21 / 61
PGI EMI-ES GFD-I.210 31 March 2013
1) Full activity documents are returned. Note that the mandatory elements are always present in the
full document response.
<GetActivityInfoResponse>
<ActivityInfoIt em>
<ActivityID>15f4a518</ActivityID>
<ActivityInfoDocument>
<ID>15f4a518<ID>
pgi-wg@ogf. org 22 / 61
PGI EMI-ES GFD-I.210 31 March 2013
<IDFromE ndpoint>https://cream-10.pd.infn.it:8443/Activity/15f4a518</IDFromEndpoint>
<State>emies:accepted</State>
<State>emiesattr:validating</State>
<Owner> CONFIDE NTIAL</Owner>
</ActivityInfoDocument>
<ActivityInfoIt em>
<ActivityInfoIt em>
<ActivityID>798ac354</ActivityID>
<ActivityInfoDocument>
<ID>798ac354<ID>
<IDFromE ndpoint>https://cream-10.pd.infn.it:8443/Activity?798ac 354</ IDFromE ndpoint>
<State>emies:preprocessing</State>
<State>emiesattr:server-stagein</State>
<Owner>/DC=eu/DC=KnowARC/O=Lund University/CN=demo1</Owner>
</ActivityInfoDocument>
<ActivityInfoIt em>
<GetActivityInfoResponse>
2) Filtered documents are returned; in this case the document contains only the requested elements, namely
Error and StageOutDirectory:
<GetActivityInfoResponse>
<ActivityInfoIt em>
<ActivityID>15f4a518</ActivityID>
<ActivityInfoDocument>
<Error>Error code 476259</Error>
<StageOutDirectory>gsiftp://localhost:2811/FILESPACE/15f4a518</StageOut Directory>
</ActivityInfoDocument>
</ActivityInfoItem>
<ActivityInfoIt em>
<ActivityID>798ac354</ActivityID>
<ActivityInfoDocument>
<Error>Error code 421223</Error>
<StageOutDirectory>gsiftp://localhost:2811/FILESPACE/798ac354/</StageOutDirectory>
</ActivityInfoDocument>
</ActivityInfoItem>
<GetActivityInfoResponse>
pgi-wg@ogf. org 23 / 61
PGI EMI-ES GFD-I.210 31 March 2013
If no parameters are specified, the operation returns the full list of activityIDs belonging to that us er.
Otherwise the IDs of those activities are returned that were created in the given window A ND are in one of
the listed states.
<ListActivitiesRequest>
<FromDat e />
<ToDate />
<Limit />
<ActivityStatusList>
<ActivityStatus>
<State>accepted</State>
<StateAttribute>validating</StateAttribute>
<StateAttribute>client-stagein-possible</StateAttribute>
<StateAttribute>client-stageout-possible</StateAttribute>
</ActivityStatus>
<ActivityStatus>
<State>terminal</State>
<StateAttribute>validation-failure</StateAttribute>
<StateAttribute>app-failure</StateAttribute>
</ActivityStatus>
<ActivityStatus>
<State>processing-queued</State>
<StateAttribute>server-paused</StateAttribute>
<StateAttribute>client-paus ed</StateAttribute>
</ActivityStatus>
</ActivityStatusList>
</ListActivities Request>
pgi-wg@ogf. org 24 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Response
The respons e of the ListActivity operation returns a list of ActivityIds or an appropriate fault.
An additional boolean flag “truncated” indicates that the result list was truncated.
Faults
InvalidParameterFault - some input parameter is illegal (for example FromDate is older than ToDate)
AccessControlFault – client is not allowed to perform ListActivities operation.
InternalBaseFault – any other failure preventing service from processing all activities.
pgi-wg@ogf. org 25 / 61
PGI EMI-ES GFD-I.210 31 March 2013
The int erface described in this section describes the direct delegation of RFC3820 X.509 proxies bet ween
clients and ES. Since delegation is critical for other services as well (such as data management services ), a
common s olution for all the EMI services is desirable. Currently EMI ES adopts not y et rele ased version 2.1
of GridSite delegation service. Version 2.1 is modified version 2. 0 adapted to document/literal WSDL style.
Below GridSite delegation operations are described as applicable to EMI Execution service.
Functionality
The getInterfaceVersion operation provides version of this interface. Its value must be 2. 1.
Data-Staging Implications
None.
State model Implications
None.
Request
The request is empty.
Response
The respons e contains getInterfaceVersionRet urn string element containing “2.1” value.
Faults
DelegationException – generic error
pgi-wg@ogf. org 26 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Functionality
The getServiceMetadata operation provides access to meta -data describing this service. Meta-data is
organised in key -value pairs. Service is free to provide any meta-data. For EMI ES no meta-data is
required.
Data-Staging Implications
None.
State model Implications
None.
Request
The request contains k ey of requested meta-data.
Response
The respons e contains corresponding value of requested meta-data.
Faults
DelegationException – generic error. Also returned if meta -data for requested key does not exist.
Functionality
The getProxyReq operation starts the delegation procedure by asking for a certificate signing request from
the server. The server ans wers with a certificate signing request which includes the publ ic key for the new
delegated credentials. The PutProxy operation is used to complete the delegation procedure.
Data-Staging Implications
The delegationID supplied in request MAY be used in the DataStaging element of t he activity description in
order to assign a delegated credential (once the delegation process was completed) to a data-staging
operation to be performed by the Execution Service on behalf of the client (in t he “s erver data push” and
“server data pull” data staging scenarios).
State model Implications
The two-step delegation process MUS T be performed at least once before the invocation of the
CreateActivity operation which uses the delegationID passed within the DataStaging JS DL block. The
delegationID MAY be (re-)used in multiple CreateActivity operation invocations.
Request
• delegationID: the ID to be assigned to be used in putProxy and assigned to stored delegation.
GridSite allows for empty delegationID which is then replaced by hash of certificate subject and V OMS(7)
attributes. But because neither has hing algorit hm nor way to combine V OMS attributes are defined
delegationID MUS T be not empty in EMI ES implementation.
Response
The respons e includes getProxyReqReturn wit h an X. 509 certificate signing request in PEM format.
Faults
DelegationException – generic error.
pgi-wg@ogf. org 27 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Functionality
The getProxyReq operation starts the delegation procedure by asking for a certificate signing request from
the server. The server ans wers with a certificate signing request which includes the public key for the new
delegated credentials. The PutProxy operation is used to complete the delegation procedure.
Data-Staging Implications
The delegationID provided in response MAY be used in the DataStaging element of the activity description
in order to assign a delegat ed credential (once the delegation process was completed) to a data-staging
operation to be performed by the Execution Service on behalf of the client (in t he “s erver data push” and
“server data pull” data staging scenarios).
State model Implications
The two-step delegation process MUS T be performed at least once before the invocation of the
CreateActivity operation which uses the delegationID passed within the DataStaging JS DL block. The
delegationID MAY be (re-)used in multiple CreateActivity operation invocations.
Request
Request is empty.
Response
The response includes proxyRequest with an X. 509 certificate signing request in PEM format and
delegationID assigned by service.
Faults
DelegationException – generic error. Also returned if credentials with specified delegationID already exists.
Functionality
The renewProxyReq operation requests to replac e already existing delegation with new one. The server
answers with a certificate signing request whic h includes the public key for the renewed delegated
credentials. The PutProxy operation is used to complete the delegation procedure.
Data-Staging Implications
The credentails renewal operation may happen after CreateActivity. In this case after PutProxy is performed
renewed credentials are to be passed to already existing activity. If activity is in data-staging state it is up to
implementation how soon new credentials become active.
State model Implications
The two-step delegation process MUS T be performed before c redentials renewal operation is complete.
Request
• delegationID: the ID of delegation to be replaced.
Response
The response includes renewProxyReqReturn with an X.509 certificate signing request in PEM
format.
Faults
DelegationException – generic error. Also returned if delegationID does not match any of client's delegated
credentials.
pgi-wg@ogf. org 28 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Functionality
The putProxy operation completes the delegation procedure by sending the signed proxy certificat e along
with the delegationI D to the server. The signed certificate is based on the certificate signing request
previously retrieved together with the d elegationI D via an getProxyReq, getNewProxyRequest or
renewP roxyReq operation invoc ation.
Data-Staging Implications
The delegated credential MAY be used by the Execution Servic e to carry out data-staging operations on
behalf of the user. The delegated c redential is assigned to the data transfer via a dedicated activity
description element of the DataStaging block of the EMI-JS DL.
In general, it is possible that the same user delegates different kind of credentials (with different delegation
IDs) to the same Execution Service. This could be useful, for example, if the user belongs to different Virtual
Organizations (VOs) and wants to delegate credentials bound to different VOs to the same service.
Different VOs could be necessary to access data on different Storage Elements (SEs).
State model implications
The two-step delegation process MUS T be performed at least once before the invocation of the
CreateActivity operation which uses the delegationID passed within the DataStaging JS DL block. The
DelegationID MAY be (re-)used in multiple Creat eActivity operation invocations.
Request
The request includes the following information:
• the delegationID identifying delegation session as assigned in getP roxyReq/renewProxyReq or
obtained by getNewProxyRequest
• the proxy element which contains RFC 3280 style proxy certificate, signed by the client
Response
The respons e includes the SUCCESS string in case of successful putProxy operation.
Faults
DelegationException – generic error. This is also returned if session for delegationID was not started using
getProxyReq/getNewProxyRequest.
pgi-wg@ogf. org 29 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Functionality
The getTerminationTime operation returns expiration time of specified delegation.
Data-Staging Implications
None.
State model implications
The delegation is two-step process. Hence getTerminationTime can succeed only after second step
delegation process is complete.
Request
The request includes the delegationID identifying delegated credentials for which information is requested.
Response
The response includes the get TerminationTimeReturn element whic h contains expiration time of delegated
credentials.
Faults
DelegationException – generic error. This is also returned of no delegat ed credentials found matching
delegationID for requesting client.
pgi-wg@ogf. org 30 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Functionality
The destroy operation erases delegated credentials or open delegated session from servic e.
Data-Staging Implications
None.
State model implications
None.
Request
The request includes the delegationID identifying delegated credentials or delegat ed session started by
getProxyReq/getNewProxyRequest/renewProxyReq operations.
Response
Successful response is empty.
Faults
DelegationException – generic error. This is also returned if no delegated credentials or session found
matching delegationID for requesting client.
pgi-wg@ogf. org 31 / 61
PGI EMI-ES GFD-I.210 31 March 2013
The state model is the external one, i.e. intended for clients. Internally, the service implementation might use
a different state model.
The EMI ES state model consists of state s and state attributes. An activity can only be in one state but can
have multiple state attributes. A state and all its assigned attributes together defines an activity status.
The state s can be grouped into 5 phases:
• ACCEP TE D phase: the activity has been created and is being validated. This phase is represented
by state accepted.
• PREPROCESSING phase: the activity environment, including data is being prepared. This phase is
represented by state preproce ssing.
• PROCESSING phase: the job is being submitted to and processed by the underlying system or it is
already handled by the batch system. This phase is split into the following states:
◦ proce ssing-accepting – intermediate state representing the time slot while the Execution Service
communicates with the underlying batch system.
◦ proce ssing-queued – this state indicates that the job was accepted by the batch system, but the
payload is not yet running.
◦ proce ssing-running – this state indicates that the job was accepted by the batch system and the
payload is running.
• POSTP ROCESSING phase: the job has left the batch system. It is possibly activity is doing stage -
out, releasing resources (de-provisioning). This phase is represent ed by state postrpoce ssing.
• TE RMINAL phase: there is no more activity by the service, the activity is in a final state. Output data
is available for client data pull. This phase is represented by state terminal.
Each state may by assigned multiple attributes. The purpose of attributes is to provide information about
particular functions being performed by the service. It is main source of information for clients to choose
action to perform. There may be few or no attributes assigned to the current state. Not every attribute may be
assigned to every state.
The following state attribute s are defined:
• validating informs that service is performing validation of activity request.
• server-paused means server stopped activity processing due to some internal decisions. This flag
can be raised and removed only by servic e itself.
• client-paused is raised by client through submitting a PauseActivity request. This is a flag which can
be removed by client through submitting a Res umeActivity request. The activity processing is stopped and
will not continue until the client-paused attribut e is removed.
• client-stagein-possible and client-stageout-possible are indicating that client can access stage-
in/stage-out location. This is a flag which can be removed by client through submitting NotifyService request .
The service will stop activity processing at the point where it can't continue waiting for the client-stagein-
possible to be removed. It must be noted that there is no need for removing the client-stageout-possible
attribute.
• provi sioning and deprovisioning refer to any preparations before and aft er user job goes to batch
system not related to data staging.
• server-stagein and server-stageout are representing service performing server data pull and
server data push.
pgi-wg@ogf. org 32 / 61
PGI EMI-ES GFD-I.210 31 March 2013
• batch-suspend refers to situation when batch system decides to suspend execution of payload
• app-running denot es execution of payload specified in the activity description – the user job. This
attribute is meant to distinguish between execution of payload specified by client and other actions wh ich
service may choose to delegat e to batch system.
• *-cancel attributes [preprocessing -cancel, processing-cancel, postprocessing-cancel] inform
that activity was cancelled on client request. First part of name refers to phase of activity when cancellation
request was executed.
• *-failure attributes [validation-failure, app-failure, preprocessing-failure, processi ng-failure,
postproce ssing -failure] inform that activity proc essing failed. First part of name refers to phase of activity
where failure was detected. Additionally validation-failure refers to job failed due to failure to validate
activity request. app-failure means failure of specified payload.
• expired indicates that the activity was cancelled because its expiration time has been exceeded.
The expiration time is optionally set in the activity description, see section Error! Bookmark not defined..
pgi-wg@ogf. org 33 / 61
PGI EMI-ES GFD-I.210 31 March 2013
processing-accepting
processing-running
postprocessing
processing-queued
terminal
preprocessing
accepted
validating X
client-paused X X X X X
client-stagein-possible X X
server-paused X X X X X
provisioning X
server-stagein X X X
batch-suspend X X
app-running X
server-stageout X X
deprovisioning X
client-stageout-possible X X
preprocessing-cancel X X
processing-cancel X X
postprocessing-cancel X X
validation-failure X X
app-failure X X
preprocessing-failure X X
processing-failure X X
postprocessing-failure X X
expired X
pgi-wg@ogf. org 34 / 61
PGI EMI-ES GFD-I.210 31 March 2013
terminal
From terminal state with *-failure attributes following failure recovery transitions are allowed:
validation-failure → NO
app-failure → processing
proce ssing-failure → processing
preprocessing-failure → preprocessing
postproce ssing -failure → postprocessing
The implementation of such "failure recovery transitions" is optional (i.e. some servic es can be able to
support some recoveries )
pgi-wg@ogf. org 35 / 61
PGI EMI-ES GFD-I.210 31 March 2013
pgi-wg@ogf. org 36 / 61
PGI EMI-ES GFD-I.210 31 March 2013
<GetResourceInfoResponse>
<Services>
<ComputingService>
<!-- Mandatory -->
ID
Type
HealthState
Capability
QualityLevel
<ComputingEndpoint>
pgi-wg@ogf. org 37 / 61
PGI EMI-ES GFD-I.210 31 March 2013
</ComputingE ndpoint>
<ComputingEndpoint>
InterfaceName = org. ogf.glue.emies.activitymanagement
Capability
...
</ComputingE ndpoint>
<ComputingEndpoint>
InterfaceName = org. ogf.glue.emies.activityinfo
Capability
...
</ComputingE ndpoint>
<ComputingEndpoint>
InterfaceName = org. ogf.glue.emies.res ourc einfo
Capability
...
</ComputingE ndpoint>
<ComputingEndpoint>
InterfaceName = org. ogf.glue.emies.activityinfo
Capability
...
</ComputingE ndpoint>
pgi-wg@ogf. org 38 / 61
PGI EMI-ES GFD-I.210 31 March 2013
<ComputingManager></ComputingManager>
<ComputingShare></ComputingShare>
<Location></Location>
<Contacts></Contacts>
<!-- non EMI-ES endpoints -->
<ComputingEndpoint>
InterfaceName = org. nordugrid.gridftpjob
Capability
...
</ComputingE ndpoint>
<ComputingEndpoint>
InterfaceName = org. nordugrid.ldapng
Capability
...
</ComputingE ndpoint>
</ComputingService>
<Services>
</GetResourceInfoResponse>
<GetResourceInfoResponse>
<Services>
<ComputingService>
ID = bd9aa2ca-ccf3-11e1-be88-001e331f6e47
Type = org.distributed.CE
Name = jobmanager service
OtherInfo = This service hosts two EMI-ES port-types
OtherInfo = and one non EMI-ES Endpoint
<ComputingEndpoint>
InterfaceName = org. ogf.glue.emies.activitycreation
Capability
...
</ComputingE ndpoint>
<ComputingEndpoint>
InterfaceName = org. ogf.glue.emies.activitymanagement
Capability
...
</ComputingE ndpoint>
<ComputingManager></ComputingManager>
<ComputingShare></ComputingShare>
<Location></Location>
<Contacts></Contacts>
<!-- non EMI-ES endpoints -->
<ComputingEndpoint>
InterfaceName = org. nordugrid.gridftpjob
Capability
...
</ComputingE ndpoint>
</ComputingService>
<ComputingService>
ID = 17e5f658-ccf4-11e1-970e-001e331f6e47
Type = org.distributed.CE
Name = jobinfo service
OtherInfo = This service hosts one EMI-ES port -type
<ComputingEndpoint>
InterfaceName = org. ogf.glue.emies.activityinfo
Capability
...
pgi-wg@ogf. org 39 / 61
PGI EMI-ES GFD-I.210 31 March 2013
</ComputingEndpoint>
</ComputingService>
<Service>
ID = 9ddec5b4-ccf4-11e1-817a-001e331f6e47
Type = org.distributed.CE
Name = resourceinfo service
OtherInfo = This service hosts one EMI-ES port -type
OtherInfo = and one non EMI-ES Endpoint
<Endpoint>
InterfaceName = org. ogf.glue.emies.res ourc einfo
Capability
...
</Endpoint>
<!-- non EMI-ES endpoints -->
<Endpoint>
InterfaceName = org. nordugrid.ldapng
Capability
...
</Endpoint>
</Service>
<Service>
ID = cba592a2-ccf4-11e1-a51f-001e331f6e47
Type = org.distributed.CE
Name = delegation service
OtherInfo = This service hosts one EMI-ES port -type
<Endpoint>
InterfaceName = org. ogf.glue.emies.delegation
Capability
...
</Endpoint>
</Service>
<Services>
</GetResourceInfoResponse>
8.1.2.1 ID
Each GLUE2 ID element of the resource document MUS T have a univers ally unique valid URI as a value;
The IDs must not be interpreted by the user or the system as having any meaning other than identifiers. In
particular, there is no predefined relationship between an ID and a network endpoint or activityID. IDs MUS T
be persistent, as long as the service is considered to be the same. For example, a service restart or
configuration changes should not result in a new ID unless it is deliberately requested by operational needs.
It is up to implementation how to generate suitable IDs.
pgi-wg@ogf. org 40 / 61
PGI EMI-ES GFD-I.210 31 March 2013
If the service contains non EMI-ES endpoints, then their InterfaceName must be published according to the
official GLUE2 Enumeration list for Interfac eName_t.
pgi-wg@ogf. org 41 / 61
PGI EMI-ES GFD-I.210 31 March 2013
Capability_t Description
data.access.sessiondir.<protocol> Capacity of providing access to the directory
(eventually on a worker node) where the job is
executed by means of <protocol>
<protocol> is one of: ftp, https, gridftp
data.access.stageindir.<prot ocol> Capacity of offering clients a place where to upload
data by means of <protocol>
<protocol> is one of: ftp, https, gridftp
data.access.stageoutdir.<protoc ol> Capacity of offering clients a place from where to
download output data by means of <protocol>
<protocol> is one of: ftp, https, gridftp
data.trans fer.cepull.<protoc ol> Capacity of the Computing Element to fetch files
from remote net work location.
<protocol> is one of: ftp, https, gridftp, srm
data.trans fer.cepush.<prot ocol> Capacity of the Computing Element to upload files to
remot e network location.
<protocol> is one of: ftp, https, gridftp, srm
executionmanagement.jobc reation Capacity of creating an activity or a set of activities
executionmanagement.jobmanagement Capacity of managing an activity or a set of activities
on a Computing Element
information.discovery.job Capacity of locating activities, possibly satisfying a
set of requirements
information.look up.job Capacity of providing information about an activity or
a set of activities
information.query.<language> Capacity of answering information system queries
specified in a <language>
<language> can be one of:
xpath1 (for XPath v 1.0 ),
xpath2 (for XPath v 2.0),
xquery1 ( for Xquery v 1.0),
custom (for custom queries)
pgi-wg@ogf. org 42 / 61
PGI EMI-ES GFD-I.210 31 March 2013
pgi-wg@ogf. org 43 / 61
PGI EMI-ES GFD-I.210 31 March 2013
JobDescription:
RestartState:
ExitCode:
ComputingManagerExitCode:
Error:
WaitingPosition:
UserDomain:
LocalOwner:
RequestedTotalWallTime:
RequestedTotalCP UTime:
RequestedSlots:
RequestedApplicationEnvironment:
Sdtin:
Stdout:
StdErr:
LogDir:
ExecutionNode:
Queue:
UsedTotalWallTime:
UsedTotalCPUTime:
UsedMainMemory:
SubmissionTime:
ComputingManagerS ubmissionTime:
StartTime:
ComputingManagerE ndTime:
EndTime:
WorkingAreaEraseTime:
ProxyExpirationTime:
SubmissionHost:
SubmissionClient:
OtherMessages:
StageInDirectory:
StageOutDirectory:
SessionDirectory:
ComputingActivityHistory:
<ActivityInfoDocument>
8.2.2.1 ID
This mandatory element is the universally unique ID of the activity document, as mandated in GLUE2: each
GLUE 2 ID element MUS T have a universally unique valid URI as a value; The IDs must not be interpreted
by the user or the system as having any meaning other than identifie rs. In particular, there is no relationship
between an ID and a network endpoint. IDs MUS T be persistent during the lifetime of the activity. The activity
document ID MAY be the same as the ActivityID (the one returned by the Creat eActivity operation).
8.2.2.2 State
This mandatory element values are taken from a special set of ComputingActivity_t strings with the syntax
mandated by GLUE 2. Values are defined in this specification for both EMI -ES states and state attributes as
follows:
• For EMI-ES states, the state name is prefixed wit h the string “emies:” followed by the EMI-ES state
name.
Example: EMI-ES state processi ng-queued is represented as emies:processing-queued
• For EMI-ES state attributes, the state attribute name is prefix ed with the string “emiesattr:” followed
by the EMI-ES state attribut e name.
Example: EMI-ES state attribute client-stagein-possible is represented as emiesattr:client-stagein-possible
In case of a state with multiple state attributes, all the state attributes MUS T be published together with the
state. In addition to EMI-ES states, the state element of the activity document MAY contain also other
GLUE 2 states belonging to different state models.
Example:
pgi-wg@ogf. org 44 / 61
PGI EMI-ES GFD-I.210 31 March 2013
<State>emies:terminal</State>
<State>emiesattr:app-failure</State>
<State>emiesattr:processing-failure</State>
<State>nordugrid: failed</State>
<State>bes:terminated</State>
Several state attribut es trigger the publication of ot her elements of the activity document:
StageInDirectory element MUS T be published IF activity state includes client-stagein-possible state
attribute.
StageOutDirectory element Must be published IF activity state includes client-stageout-possible state
attribute.
8.2.2.4 Owner
This mandatory element value as defined in the GLUE 2 model is a String containing the Grid identity of the
activitie's owner. It is RECOMMENDED that the Grid identity is specified as the subject name of client's
credentials pres ented during authentication process. If anonymity is requested, the reserved value
CONFIDE NTIAL should be used.
8.2.2.5 CreationTime
This optional element value contains the creation time of the activity document, and not of the activity.
8.2.2.7 StageInDirectory
This optional element is defined as part of the EMI-ES specification. If published, the value MUS T contain a
URL which can be used by the client to stage in data as described in section Error! Bookmark not defined..
This element MUS T be published IF activity state includes client-stagein-possible state attribute.
8.2.2.8 StageOutDirectory
This optional element is defined as part of the EMI-ES specification. If published, the value MUS T contain a
URL which can be used by the client to stage out data as described in section Error! Bookmark not
defined.. This element MUS T be published IF activity state includes client-stageout-possible state
attribute.
8.2.2.9 SessionDirectory
This optional element is defined as part of the EMI-ES specification. If published, the value MUS T contain a
URL which can be used by the client to access activity execution directory as described in section Error!
Bookmark not defined..
pgi-wg@ogf. org 45 / 61
PGI EMI-ES GFD-I.210 31 March 2013
<Timestamp>2012-07-13T09:20: 43.000+02:00</Timestamp>
</ActivityStatus>
<ActivityStatus>
<State>preprocessing</State>
<Timestamp>2012-07-13T09:20: 43.000+02:00</Timestamp>
</ActivityStatus>
<ActivityStatus>
<State>processing-accepting</State>
<Timestamp>2012-07-13T09:20: 43.000+02:00</Timestamp>
</ActivityStatus>
<Operation>
<RequestedOperation>creat e_activity</RequestedOperation>
<Timestamp>2012-07-13T09:20: 42.000+02:00</Timestamp>
<Success>true</Success>
</Operation>
<Operation>
<RequestedOperation>start_activity</RequestedOperation>
<Timestamp>2012-07-13T09:20: 47.000+02:00</Timestamp>
<Success>true</Success>
</Operation>
</ComputingActivityHistory>
pgi-wg@ogf. org 46 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9. Activity Description
This section defines the activity description, an XML document that serves as a request description for
creating activities on an execution service.
All of these cases have different semantics and may require additional elements.
Therefore, this specification defines the activity description for direct consumption by the execution service
(case c). Additional information and structures to be used for match m aking can be added, but will be
ignored by the ex ecution s ervice. Activity description instances for clients/brok ers are at different level, and
outside the scope of this specification.
Since the exec ution service interfac e is a web -service interface, the activity description rendering is in XML.
Its normative XML schema is defined as part of the web service WSDL and XML schema.
Since the activity description contains several abstractions, for example the Software, RuntimeE nvironment
or ParallelEnvironment, this concretization is a mandatory step.
pgi-wg@ogf. org 47 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9.3.2 Type s
In addition to the basic types such as string, integer, dateTime and URI, the activity description utilizes the
following types:
9.3.2.1 ExecutableType
This complex element denotes an executable having path and optional argument subelements. An optional
attribute failIfExitCodeNotEqualTo allows to specify that the Execution Service should treat the job as failed
if the exit code is not equal to the specified value. Typically, this value will be set to “0” to indicate that exit
code of zero indicates successful execution. By default, the Execution Service MUS T NOT check the exit
code of the user application to decide whether to continue processing.
• path: the pat h to the executable, relative to the session directory. Multiplicity is one.
• argument: optional subelements specifying the arguments, multiplicity is zero or more.
• failIfExitCodeNotEqualTo: optional integer-valued attribute
9.3.2.2 SoftwareRequirement
The S oft wareRequirement structure provides the general envelope to express logical relation of Software
requests.
The Soft wareRequirement element specifies the software requirements of a job. It MAY contain multiple
Software elements. This element MAY cont ain a B oolean that specifies that all OR one of its child elements
has to be satisfied. The multiplicity of this element is zero or more. There is no default value of this element.
9.3.2.3 Software
The Soft ware is a triplet of strings. The multiplicity is zero or more. There is no default value of this element.
The structure is composed of Family, Name and Version string elements.
9.3.2.4 BenchmarkType
The benchmark type is composed of the name of the benchmark as defined by GLUE 2 and the non -negative
integer benchmark value.
The benchmark name is an open enumeration with values of the GLUE2 Benchmark_t type:
• bogomips
• cfp2006
• cint2006
• linpack
pgi-wg@ogf. org 48 / 61
PGI EMI-ES GFD-I.210 31 March 2013
• specfp2000
• specint2000
9.3.3.1 Name
This optional string element MAY be specified by a us er t o name the activity. It may not be unique to a
particular activity description, which means that a user MAY specify the same ActivityName for multiple
activity descriptions. Some project defines their own format for the ActivityName in order to categorize and
explicitly define t he particular version of activity they run. However t he recommended way to attach user
specified categories to the activity is to use ActivityAnnotation element.
This element has no default value. The multiplicity of this element is zero or one.
9.3.3.2 Description
This optional longer string element may contain a longer t extual description of the activity. This element has
no default value. The multiplicity of this element is zero or one.
9.3.3.3 Type
This optional element provides a classification of the activity in compliance with GLUE 2. The default value
of this element is single. The multiplicity of this element is zero or one. The type of t his elem ent is an
enumeration wit h the following elements:
• collectionelement: an activity submitted as part of a collection of individual activities which do not
• communicate among them,
• parallelelement: an activity submitted as part of a collection of individual activities which
communicate among them,
• single: an individual stand-alone activity,
• work flownode: an activity submitted as part of a work flow.
9.3.3.4 Annotation
This optional string-valued element is for human readable comments, tags for free grouping or identify ing
different activities. This element has no default value. The multiplicity of this element is zero or more.
9.3.4 Application
The main goal of this block is to explicitly describe the executed application and its software environment.
This activity description block is mandatory and its multiplicity is one.
9.3.4.1 Executable
This optional element of type ExecutableType is specifying the main execut able of the job. Multiplicity is
zero or one. If no executable is specified, it is assumed that the selected runtime environment provides an
executable.
9.3.4.2 Input
This optional element is a string specifying the input (Standard Input) for the Executable. The Input element
is a filename which should be relative to the session directory of the job. There is no default value of th is
element. The multiplicity is zero or one.
9.3.4.3 Output
This optional element is a string specifying the output (Standard Output ) for the Executable. The Output
element is a filename which should be relative to t he session directory of the job. There is no def ault value
of this element.. The multiplicity is zero or one.
pgi-wg@ogf. org 49 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9.3.4.4 Error
This optional element is a string specifying the error output (Standard Error) for the Executable. The Error
element is a filename which should be relative to t he session directory of the job. There is no default value
of this element. The multiplicity is zero or one.
9.3.4.5 Environment
This optional element s pecifies the operating system environment variables which should be defined at the
execution service in the exec ution environment of the job. It consists of a Name Value pair of strings. The
multiplicity of this element is zero or more with strict ordering. There is no default value of this element.
Name
This mandatory string element defines the name of the environment variable. Multiplicity is one. There is no
default value of this element.
Value
This mandat ory string element defined the value of the environment variable. Multiplicity is one. There is no
default value of this element. It is not recommended to use system specific notion, macro etc as a value of
this element.
9.3.4.6 PreExecutable
This optional element of type ExecutableTy pe specifies an command that should be executed before
invoking the user's application. Multiplicity is zero or more.
9.3.4.7 PostExecutable
This optional element of type ExecutableTy pe specifies an command that should be executed after invoking
the user's application. Multiplicity is zero or more.
9.3.4.8 RemoteLogging
The optional elements specifies a logging service to send reports about activity. There is no default value of
this element. Multiplicity is zero or more. In case of multiple elements computing service MUS T t ry to send
reports to all specified logging services. It is not a failure if communication fails. It is up to a user to make
sure the requested logging service accepts reports from the set of computing service he or she intends to
use.
The content of this element and information sent may be very specific to type of logging service. So we only
define minimal set of information. One example is the OGSA Resource Usage Ser vice (RUS ) [7] which
accepts Usage Records (UR) [8].
OPT-IN
9.3.4.8.1 ServiceType
9.3.4.8.2 URL
If applicable this optional element specifies the endpoint at which the service may be contacted.
9.3.4.9 ExpirationTime
The element is optional and specifies the date and time after which the processing of the activity MUS T be
cancelled. The activities not completed before the expiration time – if defined - MUS T be cancelled by the
service. Multiplicity is zero or one. There is no default value of this element.
OPT-IN.
9.3.4.10 WipeTime
The requested duration the activity MUS T stay in the terminal phase before it MAY be wiped by the service.
There is no default value of this element. Multiplicity is zero or one.
pgi-wg@ogf. org 50 / 61
PGI EMI-ES GFD-I.210 31 March 2013
OP T-IN.
9.3.4.11 Notification
This optional element defines the request in custom format for notifications on activity state change.
Multiplicity is zero or more. There is no default value of this element. The service advertises its notification
capabilities
OPT-IN.
9.3.4.11.1 Protocol
This mandatory element specifies the protocol to be used for notification. Multiplicity is one. The initial list of
protocol is “email”. (TB D: others, e.g. “ws-notification”). This field will be used for validating whether the
execution service has the required capability.
9.3.4.11.2 OnState
This optional element denotes the state which should trigger the notification. This can be one of the valid
primary states of the activity (accepted, etc). The default value of this element is “terminal”, i.e. by default,
notifications will be sent when the activity enters a terminal state. Multiplicity is zero or more.
9.3.4.11.3 Recipient
The string-valued address to send notifications to, e.g. “user@domain.org”. Multiplicity is one or more.
9.3.5 Resource s
The optional complex resource element describe the resourc e requirements of the job. Multiplicity is zero or
one.
9.3.5.1 OperatingSystem
This optional complex element specifies the operating system required for the user job. Its type is
SoftwareRequirement. Multiplicity is zero or more, where multiple values are interpreted as giving
alternatives (i.e. “OR” semantics are implied). There is no default value of this element.
In case of OperatingSystem the Family element of the Software structure embedded in the
SoftwareRequirement is open enumeration with values of the GLUE2 OSFamily _t type:
• linux: Family of operating systems based on Linux kernel
• macosx: Family of operating systems based on MacOS X
• solaris: Family of operating systems based on Solaris
• windows: Family of operating systems based on Windows
• aix: AIX
• centos: CentOS
• debian: Debian
• fedoracore: RedHat Fedora
• gentoo: Gent oo Linux
• leopard: Mac OS X 10.5 (Leopard)
• linux-rock s:
• mandrak e: Mandrake
• redhatenterpriseas: RedHat Enterprise Server
• scientificlinux: Scientific Linux
• scientificlinuxcern: Scientific Linux CE RN
• suse: SUSE
• ubuntu: Ubuntu
• windows vista: Microsoft Windows Vista
• windows xp: Microsoft Windows XP
In case of OperatingSystem the Name element of the Software structure embedded in the
SoftwareRequirem ent is open enumeration with values of the GLUE2 OSName_t type:
• aix: AIX
• centos: CentOS
• debian: Debian
pgi-wg@ogf. org 51 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9.3.5.2 Platform
Optional element specifies the plat form archit ecture required for the user job. Multiplicity is zero or one.
There is no default value of this element. Its is an open enumeration with a values of the GLUE2 Platform_t
type:
• amd64: AMD 64bit architecture
• i386: Intel 386 archit ecture
• itanium: Intel 64-bit architecture
• powerpc: PowerPC architecture
• sparc: SPARC architecture
9.3.5.2.1 Coprocessor
This is an open enumeration that specifies the type of coprocessing unit that is available.
• CUDA: Compute Unified Device Architecture, a parallel computing architectu re developed by NVIDIA
• FPGA: Field programmable gate array
OP T-IN.
9.3.5.3 NetworkInfo
This optional element specifies the type of the interconnect, the internal net work connection available inside
the computing element. Multiplicity is zero or one. There is no d efault value of this element. Multiplicity is
zero or one. Its is an open enumeration wit h the values of GLUE2 Network Info_t type:
• 100megabitethernet: Network based on 100 MBit/s Ethernet technology
• gigabitethernet: Network based on 1 GBit/s Ethernet technology
• 10gigabitethernet: Network based on 10 GBit/s Ethernet technology
• infiniband: Network based on Infiniband technology
• myrinet: Net work based Myrinet technology
OPT-IN
9.3.5.4 NodeAcce ss
The optional element defines the required c onnectivity of the executation node. Multiplicity is zero or one. If
it is not defined, then net work connection is not required for the user job. It is an enumeration with the
following values:
• inbound: inbound network is required for the us er job
• outbound: outbound net work is required for the user job
• inoutbound: both directions are required for the us er job
9.3.5.5 IndividualPhysicalMemory
This optional element is a integer value specifying the amount of physical memory required to be available
on every node of the computing element used by (a multi slot) job. The amount is given in bytes. Multiplicity
is zero or one.
pgi-wg@ogf. org 52 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9.3.5.6 IndividualVirtualMemory
This optional element is a integer range value specifying the amount of virtual memory required to be
available on every node of the computing element us ed by (a multi slot) job. The amount is given in bytes.
Multiplicity is zero or one.
9.3.5.7 Di skSpaceRequirement
This optional integer element specifies the total required disk space of the job in bytes.
9.3.5.8 RemoteSessionAccess
A boolean to request remote access to the session directory. Multiplicity is zero or one. If it is not defined that
the user not interested to access session directory remotely (default is false).
9.3.5.9 SlotRequirement
This optional complex element s pecify the requested count of slots and its distribution for multi-slot jobs.
Multiplicity is zero or one.
9.3.5.9.1 NumberOfSlots
This mandatory integer range element specifies the total number of slots to allocate on the batch system.
The term “Slot” is used to denot e a logical CP U visible to and allocat able by the resource management
system. It may correspond to a physical CPU, a physical CP U core or a virtual CPU or core, depending on
the hardware capabilities. Multiplicity is one.
9.3.5.9.2 SlotsPerHost
This optional integer element specifies the number of slots to be allocated on each single host.
An optional attribute “useNumberOfSlots” can be set to “true” to indicate that the value of the NumberOfSlots
element should be used. In this case the value of the SlotsPerHost element MAY be left empty, and if it is
given any way, it MUST be ignored by the execution service.
9.3.5.9.3 ExclusiveExecution
This optional boolean element specifies whether a host should be allocated for exclusive use by the user job.
Each site has a default value for this, which should be advertised through GLUE 2.
9.3.5.10 QueueName
This optional string element defines the name of the preferred queue. Multiplicity is zero or one. There is no
default value of this element.
9.3.5.11 IndividualCPUTime
This optional element specifies the number of CPU seconds requested for each slot of the user job. There is
no default value of this element. Multiplicity is zero or one.
9.3.5.12 TotalCPUTime
This optional element specifies the total number of CPU seconds requested for the user job. It is the sum of
the times requested for each individual slot. There is no default value of this element. Multiplicity is zero or
one.
9.3.5.13 WallTime
This optional element is the wall clock time requested for the user job, from the start of the first process until
the completion of the last process. Multiplicity is zero or one.
9.3.5.14 Benchmark
This optional element of type Benchmark Type specifies a required minimum benchmark value (as
performance indicat or). The multiplicity is zero or one.
OP T-IN.
pgi-wg@ogf. org 53 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9.3.5.15 RuntimeEnvironment
This optional Soft wareRequirement element defines the runtime en vironment required by the user job.
Multiplicity is zero or more. There is no default value of this element.
A runtime environment MAY provide a default execut able for the job, i.e. the end-user need not specify an
executable, but may rely on the default one for the given runtime environment.
The available runtime environments MUS T be advertised in the services's description via GLUE2.
OPT-IN.
9.3.5.15.1 Name
The mandat ory name of the runtime environment.
9.3.5.15.2 Version
The optional version of the runtime environment.
9.3.5.15.3 Option
This optional element specifies an option that should be enabled in the selected runtime environment. For
example, it can be used to enable debugging or verbose mode. Multiplicity is zero or more.
9.3.5.16 ParallelEnvironment
The parallel environment is used to specify the execution environment for parallel jobs. Multiplicity is zero
or one.
If a ParallelEnvironment element is present, the execution service MUS T create the correct invocation for
the requested parallel environment. The execution servic e MAY also add environment variables and path
settings as appropriate.
The parallel environments available at an execution servic e MUS T be advertised through the GLUE2
description of the execution service using ApplicationEnvironment element.
9.3.5.16.1 Type
This optional elem ent defines the type of multi-slot application. There is no default value of this element. It is
string valued, with the following initial set of values taken from the SPMD extension 61 for the JSDL
• MPI: Any MPI environment
• GridMPI: The GridMPI environment
• IntelMPI: The Int el MPI environment
• LAM-MPI:The LAM/MP I environment
• MPICH1: The MP ICH version 1 environment
• MPICH2: The MPICH version 2 environment
• MPICH-GM: The MP ICH-GM environment
• MPICH-MX: The MPICH-MX environment
• MVAPICH: The MVAPICH (MP I-1) environment
• MVAPICH2: The MVAPICH2 (MPI-2) environment
• OpenMPI: The Open MP I environment
• POE: The POE (IBM MP I) environment
• PVM: A Parallel Virt ual Machine environment
9.3.5.16.2 Version
The optional version of the parallel environment.
pgi-wg@ogf. org 54 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9.3.5.16.3 ProcessesPerHost
This optional integer element specifies the number of instanc es of the executable that the consuming
system MUST start on eac h allocated host. Multiplicity is zero or one. Default value is “1”.
An optional flag "useSlotsPerHost" allows to indicate that the value of "SlotsPerHost" should be used.
9.3.5.16.4 ThreadsPerProcesses
This optional integer element specifies the number of threads per process (i.e., per instance of the
executable). There is no default value of this element. Multiplicity is zero or one.
An optional flag "useSlotsPerHost" allows to indicate that the value of "SlotsPerHost" should be used.
9.3.5.16.5 Option
This optional element is a string valued name/ value pair allowing to specify additional options to the parallel
environment. This allowed names and values depend on the type of environment. Exact set of allowed
options is advertised through the GLUE2 description of the execution service.
9.3.6 DataStaging
Data staging is an optional complex element which describes all the fil es that should be transferred to the
computing element (stage in) and the files that should be transfered from the computing element (stage
out). The data movement can be performed by both the client and execution service. Multiplicity is zero or
one. There is no default value of this element.
9.3.6.1 ClientDataPush
This optional boolean element indicat es that the client wishes to push data to the service under control of the
client. If this element is present wit h the value “true”, the execution service MUS T allow client access to the
stage-in directory and MUST wait for the end of client data push indicated by a call to NotifyService, as
detailed in section 1.3. If the file path in a file transfer request from the client includes hierarchy in respect to
stage-in directory all intermediate directories MUS T be created automatically.
If the element is not present, or has the value “false”, the execution service is not obliged to provide stage -in
directory access for the client and will not wait for a call to NotifySer vice before moving the activity to the
PROCESSING phase (also see Source element below).
9.3.6.2 InputFile
InputFile is an optional complex element which describes a file that should be transferred to the computing
element (stage-in) and later made available in session directory. Multiplicity is zero or more.
Note: service MAY choose to provide access to input file in session directory using way other than ordinary
copying. For example, an implementation might choose to cache input files and provide them to the j ob via a
file system link). Hence the job should not expect any access to specified file other than read -only.
9.3.6.2.1 Name
This mandatory string element defines the name of the staging object on the ex ecution service. The name is
given as a relative path to the session directory.
Multiplicity is one.
9.3.6.2.2 Source
This optional complex element specifies the source location of the stage in data trans fer of a file. Multiplicity
is zero or more. In case of multiple sources it is up to the computing service implement ation h ow utilize them.
All Sources are treated as binary identical. The ordering of the Source sub -elements is not significant. All
files to be transferred via server dat a pull (transfer initiat ed by the service) MUS T be specified and MUS T
contain Source element.
If no Source sub-element is provided this means that the file will be staged by the client into the stage-in
directory (client data push).
pgi-wg@ogf. org 55 / 61
PGI EMI-ES GFD-I.210 31 March 2013
The files to be trans ferred via client data push (i.e. that will be uploaded on the stage -in directory by the
client) MAY be specified (it is not mandatory).
9.3.6.2.2.1 URI
This mandatory URI element defines the source location of the file. It is up to a user to mak e sure the
computing servic e or the client is able communicate to the given data sourc e.
Multiplicity is one.
9.3.6.2.2.2 Option
This optional key/value pair can be used to convey additional parameters needed for the transfer. Multiplicity
is zero or more.
9.3.6.2.2.3 DelegationId
This string attribute specifies the delegationId to be used for the transfer of this file. It is mandatory only if the
protocol expressed in the URI element requires it.
There is no default value.
9.3.6.2.3 IsExecutabl e
This optional boolean element specify whet her the executable flag has to be put on the file or not. Multiplicity
is zero or one. The default value is false.
9.3.6.3 OutputFile
OutputFile is an optional complex element which describes a file that should be transferred from the
computing element (stage-out). Multiplicity is zero or more.
All files for both client data pull (i.e. the ones that will be downloaded from the client from the stage-out
directory ) and server data push must be declared.
9.3.6.3.1 Name
This mandatory string element defines the name of the staging object on the ex ecution service. Multiplicity is
one. The name is given as a relative path to the session direct ory.
9.3.6.3.2 Target
This optional complex element specifies the target location of the stage out data transfer of a file. Multiplicity
is zero or more. There is no default value of this element. The ordering of the Target sub-elements is not
significant.
In case of multiple targets the execution service MUS T upload the file to all the mandatory targets (see
below) or at least one of the targets in case there was no mandatory element defined. In case of both
mandatory and non-mandatory Target elements present non-mandatory elements are used only if all
mandatory failed. If staging file to any of Target elements failed it is treated as having no Target elements
(see below).
To inform the servic e that the file has to be copied in the stage-out directory for client data pull, there MUS T
NOT be a Target element. In that case file MUS T be provided in stage-out directory under the specified
name.
9.3.6.3.2.1 URI
This mandatory URI element defines the target location of the file, and refers to a remote location (server
data push). It is up to a user to mak e sure the computing service or the client is able communicat e to the
given dat a target. Multiplicity is one.
pgi-wg@ogf. org 56 / 61
PGI EMI-ES GFD-I.210 31 March 2013
9.3.6.3.2.2 Option
This optional key/value pair can be used to convey additional parameters needed for the transfer. Multiplicity
is zero or more.
9.3.6.3.2.3 DelegationId
This string attribute specifies the delegationId to be used for the transfer of this file. It is mandatory only if the
protocol expressed in the URI element requires it. There is no default value.
9.3.6.3.2.4 Mandatory
This optional boolean attribute defines if the given Target must be used during the stage out data transfer or
not. There is no default value of this element.
9.3.6.3.2.5 CreationFlag
This optional flag allows to choose whether existing files should be overwritten or appended to, or whether
an error should occur if the file already exists. It can take the values “Overwrite”, “Append”, or
“DontOverwrite”. Default is “Overwrite”.
9.3.6.3.2.6 UseIfFailure
This optional element defines if the specified Target element is to be used if activity failed in previou s states.
Default value is false.
9.3.6.3.2.7 UseIfCancel
This optional element defines if the specified Target element is to be used if activity was cancelled by client
request in previous states. Default value is fals e.
9.3.6.3.2.8 UseIfSuccess
This optional element defines if the specified Target element is to be used if activity reached
POSTP ROCESSING phase without failures. Default value is true.
Note: if all default values of UseIf* elements are applied in case of failure or cancelation of the activity, the
OutputFile is treated as stageable by client.
pgi-wg@ogf. org 57 / 61
PGI EMI-ES GFD-I.210 31 March 2013
pgi-wg@ogf. org 58 / 61
PGI EMI-ES GFD-I.210 31 March 2013
This section lists a number of items that were considered out of scope for the first version of the EMI ES
specification, but are of considerable interest for an updated version.
Delegation:
• support credential service (similar to MyProxy)
Activity Management
• more options for filtering in ListActivities
Data staging:
• support file sets
• In order to inform users about the progress of data staging, the activity information SHOULD include
a progress value (in percent from 0-99) that indicates how much of the proc essing in the present state has
been already completed. Implementations are free in how they calculate the progress.
Activity Description:
• allow to specify activities and their priorities (QoS attributes)
• “scalable time”, i.e. specification of requested time values in relation to some benchmark value.
Information:
• ComputingActivityProgress – contains perc entage of activity completeness. Exact mapping of
presented value to activity state is not defined and number is provided for reference only. This element is
optional.
• AccessPolicy – possible values are undefined. This needs a separate agreement.
Activity Information:
EMI-ES GLUE2 XML rendering is currently based on an XS D schema that features a hierarchical
representation of GLUE 2 objects. The GLUE2 Working Group is currently working on a non-hierarchical
XSD schema that represent the model objects as a flat list. The EMI-ES specific ation may be eventually
updated in future to be compliant with the GLUE2 Group rec ommendations regarding the Resource and
Activity Documents.
pgi-wg@ogf. org 59 / 61
PGI EMI-ES GFD-I.210 31 March 2013
13. Authors
Bernd Schuller
Juelich Supercomputing Centre, Germany
Email: b.schuller@fz-juelich.de
Balazs Konya
University of Lund, Sweden
Email: balazs.konya@hep.lu.se
Oxana Smirnova
University of Lund, Sweden
Email: oxana.smirnova@hep.lu.se
Florida Paganelli
University of Lund, Sweden
Florido.paganelli@hep.lu.se
Alexandr Konstantinov
University of Oslo, Norway
Email: aleksandr.konstantinov@fys.uio.no
Morris Riedel
Juelich Supercomputing Centre, Germany
EMail: m.riedel@fz -juelich. de
Shahbaz Memon
Juelich Supercomputing Centre, Germany
Email: m.memon@fz-juelich.de
Shiraz Memon
Juelich Supercomputing Centre, Germany
Email: a.memon@fz-juelich.de
Lisa Zangrando
National Institute of Nuclear Physics, Italy
Email: lisa.zangrando@pd.infn.it
Massimo Sgaravatto
National Institute of Nuclear Physics, Italy
Email: massimo.sgaravatto@pd.infn.it
Eric Frizziero
National Institute of Nuclear Physics, Italy
Email: eric.frizziero@pd.infn.it
pgi-wg@ogf. org 60 / 61
PGI EMI-ES GFD-I.210 31 March 2013
14. Acknowledgments
We are grateful to numerous colleagues for discussions on the topics covered in this document , and to the
people who provided comments on the public drafts.
The OGF invites any interested party to bring to its attention any copyrights, patents or patent applications,
or other proprietary rights, whic h may cover t echnology that may be required to practice this
recommendation. Please address the information to the OGF Executive Director.
Disclaimer
This document and the information contained herein is provided on an “As Is” basis and the OGF disclaims
all warranties, express or implied, including but not limited to any warranty that the use of the information
herein will not infringe any rights or any implied warranties of merchantability or fitness for a particular
purpose.
17. References
[1] Strawman of the AGU Execution Service: Functionality Description,
http://forge.gridforum.org/sf/go/ doc15736
[2] Job Submission Description Language (JS DL) Specification, Version 1.0
www.gridforum.org/doc uments/GFD.136.pdf
[3] GLUE Specification v. 2. 0,
www.gridforum.org/doc uments/GFD.147.pdf
[4] JSDL SPMD Application Extension, Version 1. 0,
www.gridforum.org/doc uments/GFD.115.pdf
pgi-wg@ogf. org 61 / 61