ETSI TS 102 830-2010 GRID Grid Component Model (GCM) GCM Fractal Management API《GRID 网格部件模型(GCM) GCM分形管理API(版本1 1 1) 包括磁盘》.pdf

《ETSI TS 102 830-2010 GRID Grid Component Model (GCM) GCM Fractal Management API《GRID 网格部件模型(GCM) GCM分形管理API(版本1 1 1) 包括磁盘》.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 102 830-2010 GRID Grid Component Model (GCM) GCM Fractal Management API《GRID 网格部件模型(GCM) GCM分形管理API(版本1 1 1) 包括磁盘》.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 102 830 V1.1.1 (2010-03)Technical Specification GRID;Grid Component Model (GCM);GCM Fractal Management APIfloppy3ETSI ETSI TS 102 830 V1.1.1 (2010-03)2Reference DTS/GRID-0004-4 GCM_MgmtAPI Keywords architecture, interoperability, network, service ETSI 650 Route des Lucioles F-06921 Sophia A

2、ntipolis 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 pr

3、esent 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 printe

4、rs of 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/

5、status/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 restri

6、ction 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

7、for 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 83

8、0 V1.1.1 (2010-03)3Contents Intellectual Property Rights 4g3Foreword . 4g3Introduction 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 7g34 Overview of the Grid Component Model (GCM)

9、 7g35 Basic GCM component introspection 8g35.1 External component structure . 8g35.2 Component introspection API 9g35.3 Interface introspection API. 9g36 GCM component configuration 10g36.1 Internal component structure 10g36.2 Attribute control API 12g36.3 Binding control API . 13g36.4 Content contr

10、ol API 14g36.5 Life cycle control API 15g36.6 Collective interface control API . 16g36.7 Multicast control API . 16g36.8 Gathercast control API . 17g36.9 Migration control API 18g36.10 Monitoring control API 19g36.11 Priority control API 19g37 GCM component runtime instantiation 20g37.1 Factories AP

11、I 20g37.2 Templates . 21g37.3 Bootstrap 21g38 GCM Typing 22g38.1 Component interfaces contingency and cardinality 22g38.2 Type system API 22g38.3 Sub typing relation . 24g3Annex A (normative): Java API . 25g3Annex B (informative): Namespaces 26g3B.1 Description . 26g3B.2 Versioning 26g3Annex C (info

12、rmative): Examples . 27g3C.1 Instantiation 27g3C.2 Reconfiguration 28g3History 30g3ETSI ETSI TS 102 830 V1.1.1 (2010-03)4Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if

13、 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 available from the ETSI Secretariat. Latest updates are availabl

14、e 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 in ETSI SR 000 314 (or the updates on the ETSI Web server

15、) 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 documents 102-650-1 (GCM Interoperability Deployment), 102-650-2 (GCM Interoperability Ap

16、plication Description), and 102-830 (GCM Management API). Introduction The GCM has been first defined in the NoE CoreGRID (42 institutions). A reference Open Source implementation has been tested in the 5 previous GRID Plugtests organized from 2004 to 2008 by INRIA and ETSI. The GridCOMP EU project

17、(FP6, started June 2006 to February 2009) is working to further assess and experiment with the specification. ETSI ETSI TS 102 830 V1.1.1 (2010-03)51 Scope The present document describes standard API to manage GCM components at runtime in an interoperable way. It defines component management in a st

18、andard manner to create, introspect, monitor and reconfigure components at execution. The present document will help enterprises and laboratories to use their large-scale computer and telecom infrastructures with the necessary virtualization. Its primary audience are developers of distributed softwa

19、re who need to specify complex applications by composing existing software components. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. Non-specific re

20、ference 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 the referring document; - for informative references. Referenced documents which ar

21、e 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 guarantee their long term validity. 2.1 Normative references The following referenced

22、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 amendments) applies. 1 ETSI TS 102 829: “GRID; Grid Component Model (GCM); GCM Frac

23、tal Architecture Description Language (ADL)“. 2 ETSI TS 102 828: “GRID; Grid Component Model (GCM); GCM Application Description“. 3 ETSI TS 102 827: “GRID; Grid Component Model (GCM); GCM Interoperability Deployment“ 2.2 Informative references The following referenced documents are not essential to

24、the use of the present document but they assist the user with regard to a particular subject area. For non-specific references, the latest version of the referenced document (including any amendments) applies. i.1 “The Fractal Component Model“. NOTE: Available at http:/fractal.objectweb.org/specific

25、ation/index.html. i.2 CoreGRID NoE (FP6): “Basic Features of the Grid Component Model“. NOTE: Available at http:/ ETSI ETSI TS 102 830 V1.1.1 (2010-03)6i.3 GCM: “A Grid extension to Fractal for Autonomous Distributed Components“, F. Baude, D. Caromel, C. Dalmasso, M. Danelutto, V. Getov, L. Henrio,

26、C. Perez. Annals of Telecommunications - The Fractal Initiative, 2008. i.4 “A formal specification of the Fractal component model“. NOTE: Available at http:/hal.inria.fr/inria-00338987/. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and

27、 definitions apply: binding: communication path between a client and a server interface cardinality: property of an interface type that indicates how many interfaces of this type a given component may have NOTE: The cardinality is singleton, collection, multicast or gathercast. client interface: com

28、ponent interface that emits operation invocations complementary interface: of an interface I, a component interface with the same name, signature, contingency, and cardinality as I, but with opposite role and visibility (external or internal) component: runtime entity exhibiting a recursive structur

29、e and reflexive capabilities NOTE: A component is composed of a set of controllers and a content. A component has well defined access points called interfaces, and provides introspection and control capabilities (intercession) to other components. component interface: access point to a component, i.

30、e. a place where operation invocations can be emitted or received composite component: component that exposes its content (inner structure) content: one of the two parts of a component, the other one being its controller NOTE: A content is an abstract entity controlled by a controller. The content o

31、f a component is (recursively) made of sub components and bindings. contingency: property of an interface, indicates if the functionality of this interface is guaranteed to be available or not, while its component is running NOTE: The contingency is either optional or mandatory. control interface: c

32、omponent interface that manages a “non functional aspect“ of a component, such as introspection, configuration or reconfiguration, and so on NOTE: By convention, control interfaces are server interfaces whose name ends with -controller, or is equal to component. controller: one of the two parts of a

33、 component, the other one being its content NOTE: A controller is an abstract entity that embodies the control behaviour associated with a particular component. A controller can exercise an arbitrary control over the content of the component it is part of (intercept incoming and outgoing operation i

34、nvocations for instance). external interface: component interface that is only accessible from outside the component factory: component that can create other components NOTE: Generic factories can create several kinds of components, while standard component factories create only one kind of componen

35、ts. ETSI ETSI TS 102 830 V1.1.1 (2010-03)7functional interface: component interface that corresponds to a provided or required functionality of a component, as opposed to a control interface intercession: ability of a component (seen as a program) to modify its own execution state; or to alter its o

36、wn interpretation or semantics internal interface: component interface that is only accessible from inside the component, i.e. from its sub components introspection: ability of a component (seen as a program) to observe and reason about its own execution state language interface: type made of severa

37、l operation declarations, i.e. a Java interface for the Java API of the GCM mandatory interface: component interface whose functionality is guaranteed to be available, while the component is running optional interface: component interface whose functionality is not guaranteed to be available, while

38、the component is running primitive component: component with some control interfaces, but that does not expose its content reflection (reflective capabilities): ability of a component (seen as a program) to manipulate as data the entities that represent its execution state during its own execution N

39、OTE: This manipulation can take two forms: introspection and intercession. role: property of a component interface, indicates if this interface is a client or server interface server interface: component interface that receives operation invocations shared component: component that is contained in s

40、everal super components signature: of a component interface, is the name of the language interface type corresponding to this component interface sub component: component that is contained in another component super component: relatively to a (sub) component, a component that contains this (sub) com

41、ponent NOTE: Due to component sharing, a component may have several super components. template: special kind of factory that creates components that are “isomorphic“ to itself type: set of structural properties common to a set of entities (components and interfaces for instance) 3.2 Abbreviations Fo

42、r the purposes of the present document, the following abbreviations apply: ADL Architecture Description Language API Application Programming Interface GCM Grid Component Model 4 Overview of the Grid Component Model (GCM) By enforcing a strict separation between interface and implementation and by ma

43、king software architecture explicit, component-based programming can facilitate the implementation and maintenance of complex distributed software systems. ETSI ETSI TS 102 830 V1.1.1 (2010-03)8Existing component-based frameworks and architecture description languages, however, provide only limited

44、support for extension, adaptation, and distribution. These limitations lead to major drawbacks: they prevent the easy and possibly dynamic introduction of different control facilities for components such as non-functional aspects; they prevent application designers and programmers from making import

45、ant trade-offs such as degree of configurability vs performance and space consumption; and they can make difficult the use of these frameworks and languages in different environments, including distributed systems. The Grid Component Model (GCM) extends the Fractal component model. As an extension o

46、f Fractal the GCM reuses the Fractal concepts and features: we do not distinguish in the present document what is part of the basic Fractal component model and what is an extension (excepted for their namespaces, see annex B). We specify the whole features making the GCM. The GCM model alleviates th

47、e above problems by introducing a notion of component endowed with an open set of control capabilities. In other terms, components in GCM are reflective, and their reflective capabilities are not fixed in the model but can be extended and adapted to fit the programmers constraints and objectives, Al

48、so the GCM handle the component distribution over a set of resources by introducing location information and parallel communication mechanisms. Main goals of the GCM component model are to implement, deploy and manage (i.e. monitor and dynamically reconfigure) complex and distributed software system

49、s. These goals motivate the main features of the GCM model: parallel communications (predefined and customizable communication patterns), remote communication (fully transparent remote binding: a remote component can be used as a local one), composite components (to have a uniform view of applications at various abstraction levels), introspection capabilities (to monitor a running system), and configuration and reconfiguration capabilities (to deploy and dynamically reconfigure an application