1、 ETSI TS 102 828 V2.1.1 (2010-03)Technical Specification GRID;Grid Component Model (GCM);GCM Application DescriptionETSI ETSI TS 102 828 V2.1.1 (2010-03)2Reference DTS/GRID-0004-22 Keywords application, architecture, interoperability, network, service ETSI 650 Route des Lucioles F-06921 Sophia Antip
2、olis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The presen
3、t document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers o
4、f the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/stat
5、us/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restrictio
6、n extend to reproduction in all media. European Telecommunications Standards Institute 2010. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for
7、the benefit of its Members and of the 3GPP Organizational Partners. LTE is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 102 828 V2
8、.1.1 (2010-03)3Contents Intellectual Property Rights 4g3Foreword . 4g3Introduction 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Definitions 6g34 Overall Structure of the GCM Application Description . 6g34.1 Principles 6g34.2 Overall XML structure . 6g34
9、.2.1 Environment . 7g35 Application Specification . 7g35.1 Executable 8g35.2 Extension of applicationNodeType (ProActive) 9g35.2.1 Overall structure . 9g35.2.2 Definition of proactiveType 10g35.2.3 Technical Services 12g35.2.4 Data . 13g36 Resource Specification . 14g36.1 Node Provider 15g3Annex A (
10、normative): Schema 16g3Annex B (informative): Example of application descriptor . 20g3Annex C (informative): Bibliography . 21g3History 22g3ETSI ETSI TS 102 828 V2.1.1 (2010-03)4Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETS
11、I. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is availab
12、le from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced
13、in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee GRID (GRID). The present document is related to document TS 102 827 1 (GCM Inter
14、operability Deployment). Introduction The purpose of the present document is to offer a standard, uniform way of describing grid-based applications, and the resources they need. When building a grid, one is confronted with several problems, among which: choosing a grid framework, as many are availab
15、le; when running a grid-enabled application, one must rewrite configuration directives when switching to a different grid framework; a grid can be built on widely different hardware infrastructures, from an heterogeneous set of desktop machines to a dedicated cluster, or even any combination of thos
16、e; grid infrastructures can also be very dynamic, it should be easy to add or remove machines, and such changes should be transparent to users. To simplify this, the GCM Interoperability Deployment standard (TS 102 827 1) offers a uniform way to describe grid resources. On the application side, the
17、present document describes how various resources can be used by an application, providing gridification of applications in a very portable manner. ETSI ETSI TS 102 828 V2.1.1 (2010-03)51 Scope The present document describes an XML schema for describing application constraints and resources to be use
18、d for deploying these applications on distributed and parallel infrastructures, like enterprise and scientific grids or job schedulers. The present document will help enterprises and laboratories to manage their IT software within large-scale computer and telecom infrastructures with the necessary v
19、irtualization. Its primary audience are users of grid-based applications who will need to write application descriptors so they can run them on the grid for their grid. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-spec
20、ific. For a specific reference, subsequent revisions do not apply. Non-specific reference may be made only to a complete document or a part thereof and only in the following cases: - if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of t
21、he referring document; - for informative references. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guar
22、antee their long term validity. 2.1 Normative references The following referenced documents are indispensable for the application of the present document. For dated references, only the edition cited applies. For non-specific references, the latest edition of the referenced document (including any a
23、mendments) applies. 1 ETSI TS 102 827: “GRID; Grid Component Model (GCM); GCM Interoperability Deployment“. 2.2 Informative references The following referenced documents are not essential to the use of the present document but they assist the user with regard to a particular subject area. For non-sp
24、ecific references, the latest version of the referenced document (including any amendments) applies. i.1 Proactive, INRIA. NOTE: Available at http:/proactive.inria.fr. i.2 MPI Forum. NOTE: Available at http:/www.mpi-forum.org/docs/. i.3 Fractal, objectweb. NOTE: Available at http:/fractal.objectweb.
25、org/. ETSI ETSI TS 102 828 V2.1.1 (2010-03)63 Definitions For the purposes of the present document, the terms and definitions given in TS 102 827 1 and the following apply: component: abstraction of a software entity with a well-defined interface for both server and client parts component model: spe
26、cification of how components are defined and interact together executable: arbitrary program which can be the launch target of an GCM Application Descriptor fractal: modular and extensible component model NOTE: See http:/fractal.objectweb.org/ i.3. Message Passing Interface (MPI): computer specifica
27、tion and is an implementation that allows many computers to communicate with one another NOTE: See http:/www.mpi-forum.org/docs/ i.2. ProActive: Java Grid middleware for parallel, distributed and multi-threaded computing NOTE 1: See http:/proactive.inria.fr i.1. NOTE 2: ProActive is part of the Obje
28、ctWeb/OW2 consortium and developed by INRIA, CNRS and University of Nice Sophia Antipolis, with Open Source code under the GPL license. 4 Overall Structure of the GCM Application Description 4.1 Principles Like a deployment descriptor, an application descriptor is written in XML. Each element of the
29、 descriptor is defined as a single node, which can have attributes and child nodes. Also, see clause 6.1 of TS 102 827 1. 4.2 Overall XML structure A deployment descriptor has the following structure: The elements must be specified in this order. The element can be omitted, while the other ones are
30、mandatory. ETSI ETSI TS 102 828 V2.1.1 (2010-03)7The element is a table of variable names and their values, which is used to give some amount of flexibility to the descriptor. The element describes the application that will be run on the grid, and the amount of resources it will use (the number of p
31、rocessing nodes). Finally, the element describes the resources made available by the grid, by referencing deployment descriptors through elements. 4.2.1 Environment The element can have the following children elements: descriptorVariable: the value has to be set in the descriptor, and cannot be spec
32、ified in the program; descriptorDefaultVariable: a default value must be specified in the descriptor. The program has the ability to change the value at execution. If the value is changed in the program, then this new value will have precedence over the one defined in the descriptor; programVariable
33、: the value must be set in the program, and cannot be specified in the descriptor; programDefaultVariable: a default value must be specified by the program as a constant, or computed (based on input size, for instance). The descriptor has the ability to change the value. If the value is changed in t
34、he descriptor, then this new value will have precedence over the one defined in the program; includePropertyFile: read variable definitions from a property file. A property file contains variable definitions as “NAME = VALUE“ lines, for example: - variable1 = value1; - variable2 = value2. There can
35、be any number of these children elements. They cannot have child elements. , and have two attributes, “name“ and “value“, each accepting string values. only has a single “name“ attribute (since it can only be set in the program). only has a single “location“ attribute. EXAMPLE: 5 Application Specifi
36、cation The element is the core of the descriptor, as it describes the application which will be run on a GCM-described grid. It contains a single child which type determines the kind of application that will be launched on the grid. The types currently defined are: 1) Executable. 2) ProActive. ETSI
37、ETSI TS 102 828 V2.1.1 (2010-03)85.1 Executable An executable defines an application which is actually a simple command to be run. It can have the following child elements: nodeProvider (empty element with a single “refId“ attribute): the id of a node provider (defined in the part). There can be any
38、 number of such element; command (command): the command which will be run on the portion of the grid defined by the specified node providers. This element can have the following attribute: instances (one of “onePerHost“, “onePerVM“, “onePerCapacity“): the number of instances of the command which wil
39、l be run. The element can have the following children (in this specified order): path (path string): the path of the executable; arg (string): the arg string which will be passed to the command. There can be any number of such element; filetransfer (file transfer): the files which should be transfer
40、red prior to running the command. It can have the following attribute: name (string): name of the executable. If a child element is present, the value of this attribute will be appended to the value of the child element. Figure 1 ETSI ETSI TS 102 828 V2.1.1 (2010-03)9Example of a call to the “ls“ Un
41、ix command: -l -h -sort=time -r 5.2 Extension of applicationNodeType (ProActive) 5.2.1 Overall structure The proactiveType is a more complex extension of applicationNodeType than executableType.It uses the technicalServices and virtualNode XML types as follows: The technicalServices elements specify
42、 the set of technical services global to the instance of ProActive. Technical Services are described in clause 5.2.3. A element can have the following children: nodeProvider (reference to a node provider): the node provider for this virtual node - see below for description; technicalServices (techni
43、cal service): a technical service specific to the virtual node. There can be any number of such child elements. A virtualNode element can also have the following attributes: id (string): a string identifying the virtual node; capacity (positive integer): the capacity requested by this virtual node (
44、that is, the total number of nodes it will request from the node providers which are associated with it). If not specified, the virtual node gets as many node as possible. If multiple virtual nodes without a capacity are defined, a fair share allocation must be performed. Virtual nodes with specifie
45、d capacity must be fulfilled before virtual nodes without a specified capacity. A within a can only have child elements. These describe technical services specific to the node provider. A can also have the following attributes: refid (string): the id of the node provider (as defined in the resources
46、 element); capacity (positive integer): the capacity of the node provider (that is, the number of nodes which may be requested. ETSI ETSI TS 102 828 V2.1.1 (2010-03)105.2.2 Definition of proactiveType In addition to using standard GCM types, elements of type proactiveType can have the following chil
47、dren: configuration: various configuration parameters. This element can have the following children: - bootClasspath (simple classpath): the boot classpath for the JVM; - java (path string): the path to the Java executable; - jvmarg (string): arguments passed to the JVM; - applicationClasspath (clas
48、spath): classpath for the application; - proactiveClasspath (classpath): classpath used to override the standard ProActive classpath computed from its installation location; - securityPolicy (relative path): path to the Java security policy file; - proactiveSecurity: security policy for application
49、and runtime. This element has two children: square4 applicationPolicy (relative path): path to Java security policy file that will be applied on the applications objects deployed at runtime, like nodes and active objects; square4 runtimePolicy (relative path): path to Java security policy file that will be applied on the ProActive Runtime. - log4jProperties (relative path): path to the Java log4j configuration file; - userProperties (relative path): path to the Java properties file
