ECMA 230-1997 Portable Common Tool Environment (PCTE) - IDL Binding (Interface Definition Language)《可移植通用工具环境(PCTE) IDL绑定(接口定义语言) 第2版》.pdf

《ECMA 230-1997 Portable Common Tool Environment (PCTE) - IDL Binding (Interface Definition Language)《可移植通用工具环境(PCTE) IDL绑定(接口定义语言) 第2版》.pdf》由会员分享，可在线阅读，更多相关《ECMA 230-1997 Portable Common Tool Environment (PCTE) - IDL Binding (Interface Definition Language)《可移植通用工具环境(PCTE) IDL绑定(接口定义语言) 第2版》.pdf（138页珍藏版）》请在麦多课文档分享上搜索。

1、Standard ECMA-2302nd Edition - December 1997Standardizing Information and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chPortable Common ToolEnvironment (PCTE) -IDL Binding (InterfaceDefinition Language).Standard ECMA-2302nd E

2、dition - December 1997Standardizing Information and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chIW Ecma-230.doc 17-02-98 10,13Portable Common ToolEnvironment (PCTE) -IDL Binding (InterfaceDefinition Language).Brief History(

3、1) The Object Management Group (OMG) has defined a general architecture to facilitate theinteroperability of object-oriented applications. One result of OMGs work is the CORBA interfacewhich defines the mechanism by which the operations of a given interface can be invoked fromany object residing in

4、a network. IDL is the language used to specify the interfaces of theoperations which can be invoked via CORBA. The IDL binding of PCTE allows a PCTEapplication to take place in the OMG architecture.(2) The IDL binding of PCTE has its origin in a joint project of the North American PCTE Initiative(la

5、ter the Object Management Group PCTE Special Interest Group) and ECMA TC33. ThisStandard is the result of a collaborative effort by all these bodies.(3) This second edition incorporates bindings for Standards ECMA-227 (Extensions for Support ofFine-Grain Objects) and ECMA-255 (Object Orientation Ext

6、ensions).Adopted as 2nd Edition of Standard ECMA-230 by the General Assembly of December 1997.- i -Contents1 Scope 12 Conformance 13 Normative references 14 Definitions 15 Formal notations 26 Outline of the Standard 27 Binding strategy 27.1 IDL standard 27.2 General principles 27.3 Sets and sequence

7、s 37.4 References and names 37.5 Implementation aspects 37.5.1 Source files 37.5.2 Naming changes in the IDL 47.5.3 Difference in generated C code 48 Datatype mapping 48.1 Basic datatypes 48.2 Sequences 48.3 The global pcte source file 78.4 The PCTE basic type source file 89 Object management 99.1 O

8、bject management datatypes 99.2 Link operators 119.3 Object operations 159.4 Version operations 199.5 Object and version operations reference interfaces 2110 Schema management 2410.1 Schema management datatypes 2410.2 Update operations 2610.3 Usage operations 3110.4 Working schema operations 34- ii

9、-11 Volumes, devices, archives, and clusters 3811.1 Volume, device, archive, and cluster datatypes 3811.2 Volume, device, and archive operations 3811.3 Cluster operations 4112 Files, pipes, and devices 4212.1 File, pipe, and device datatypes 4212.2 File, pipe, and device operations 4313 Process exec

10、ution 4513.1 Process execution datatypes 4613.2 Process execution operations 4613.3 Security operations 4913.4 Profiling operations 5013.5 Monitoring operations 5113.6 Mandatory security operations 5213.7 Consumer identity operations 5213.8 Contents handle operation 5214 Message queues 5314.1 Messag

11、e queue datatypes 5314.2 Message queue operations 5415 Notification 5615.1 Notification datatypes 5615.2 Notification operations 5616 Concurrency and integrity control 5716.1 Concurrency and integrity control datatypes 5716.2 Concurrency and integrity control operations 5717 Replication 5917.1 Repli

12、cation datatypes 5917.2 Replication operations 5918 Network connection 6018.1 Network connection datatypes 6018.2 Network connection operations 6118.3 Foreign system operations 6218.4 Time operations 6318.5 Other workstation operations 63- iii -19 Discretionary security 6419.1 Discretionary security

13、 datatypes 6419.2 Discretionary access control operations 6519.3 Discretionary security administration operations 6520 Mandatory security 6720.1 Mandatory_security datatypes 6720.2 Operations for mandatory security operation 6820.3 Mandatory security administration operations 6921 Auditing 7021.1 Au

14、diting datatypes 7021.2 Auditing operations 7322 Accounting 7522.1 Accounting datatypes 7522.2 Accounting administration operations 7723 References 7923.1 Reference datatypes 7923.2 Reference creation and discarding 8023.3 Object reference operations 8123.4 Link reference operations 8123.5 Type refe

15、rence operations 8324 Implementation limits 8424.1 Implementation limit datatypes 8424.2 Implementation limit operations 8525 Error conditions 8625.1 Error condition datatypes 86Annex A - Comparison with ECMA-158 93Annex B - IDL file structure 97Annex C - The object-oriented module 101Index of abstr

16、act operations 107Index of IDL subprograms 113Index of IDL datatypes 121- iv -.1 Scope(1) This ECMA Standard defines the standard binding of the Portable Common Tool Environment(PCTE), as specified in ECMA-149, to the CORBA Interface Definition Language (IDL) definedin ISO/IEC CD 14750.(2) A number

17、of features are not completely defined in ECMA-149, some freedom being allowed tothe implementer. Some of these features are specified as implementation limits. Some constraintsare placed on these implementation limits by this IDL Binding Standard. These constraints arespecified in clause 24, Implem

18、entation Limits.(3) PCTE is an interface to a set of facilities that forms the basis for constructing environmentssupporting systems engineering projects. These facilities are designed particularly to provide aninfrastructure for programs which may be part of such environments. Such programs, which

19、areused as aids to systems development, are often referred to as tools.2 Conformance(1) An implementation of PCTE conforms to this ECMA Standard if it conforms to 2.2 ofECMA-149, where the binding referred is taken to be the IDL Binding defined in clauses 1 to 5and 8 to 25 of this ECMA Standard. All

20、 other clauses in this ECMA Standard are provided asassistance to the reader and are not normative.(2) The IDL Binding defined in this Standard conforms to 2.1 of ECMA-149.3 Normative references(1) The following standards contain provisions which, through reference in this text, constituteprovisions

21、 of this ECMA Standard. At the time of publication, the editions indicated were valid.All standards are subject to revision, and parties to agreements based on this ECMA Standard areencouraged to investigate the possibility of applying the most recent editions of the standardsindicated below.(2) ECM

22、A-149 Portable Common Tool Environment (PCTE) - Abstract Specification(4th edition, December 1997)(3) ECMA-158 Portable Common Tool Environment (PCTE) - C Programming LanguageBinding (4th edition, December 1997)(4) ISO/IEC CD 14750 Information Technology - Open Distributed Processing - CORBA Interfa

23、ceDefinition Language (IDL) for ODP Systems4 Definitions(1) All technical terms used in this ECMA Standard, other than a few in widespread use, are definedin the body of this ECMA Standard or in the referenced documents.- 2 -5 Formal notations(1) For the IDL binding for each operation, the function

24、syntax is used as defined in ISO/IEC CD14750.6 Outline of the Standard(1) Clause 7 describes the strategy used to develop this binding specification(2) Clause 8 contains the mapping from the datatypes that are used in the Abstract Specification to theIDL datatypes.(3) Clause 9 to 22 define the bindi

25、ng of datatypes and operations in the corresponding clauses ofECMA-149. The extensions for fine-grain objects are added at the end of clause 11.(4) Clause 23 defines the binding of object, attribute, link, and type references, as specified in 23.1.2and 23.2 of ECMA-149.(5) Clause 24 defines the bind

26、ing of the implementation limit functions described in clause 24 ofECMA-149.(6) Clause 25 defines the binding of the error conditions described in annex C of ECMA-149, anddefines binding-defined error conditions for the IDL Binding.(7) There are 2 informative annexes. Annex A compares the structures

27、 of this IDL binding and of theC binding of ECMA-158, explaining the differences. Annex B describes the source file structureof the IDL binding.(8) Annex C, which is normative, contains the extensions for object orientation, corresponding toannex G of ECMA-149.7 Binding strategy7.1 IDL standard(1) T

28、his Standard conforms to the definition of IDL in ISO/IEC CD 14750.7.2 General principles(1) The following general principles were applied when generating the binding in this ECMAStandard.(2) The C interface generated from the IDL binding should be as close as possible to the PCTE Clanguage binding

29、of ECMA-158, so as to minimize changes to existing C applications.(3) The binding should leave open the possibility for an implementation of the binding to allow anon-PCTE process to access the PCTE object base without being statically linked to the PCTEinterface. This implies that the implementatio

30、n of the static bindings generated from the IDLmust not make use of any PCTE operations. The IDL binding has been structured, through theuse of Pseudo-IDL (PIDL), to leave this implementation option open.(4) The majority of the operations accept a Pcte_object_reference as controlling object. Therefo

31、re,ideally, there should exist a Pcte_object_reference interface which inherits from almost all otherinterfaces. This approach would allow for a static type checking but it is awkward. It has been- 3 -decided instead to allow casting and let the PCTE implementation raise an exception if the passedco

32、ntrolling object is not of the right type.(5) Many operations said to be applied to a process object are only applicable to the current processobject. This is specified whenever it is necessary. This is also meant sometimes by thecomment: /* Operation is applied to self */.(6) Sequences should be im

33、plemented as pseudo-objects to be mapped internally into CORBAsequences. This implies that each operation accepting or returning a sequence must map it in thecorrect format for the PCTE implementation server. In the case of a sequence of object or linkreferences, each reference must be mapped to a C

34、ORBA interface and returned to the client assuch. The major reason for this is that in general an object reference may not be easily mappedby an implementation into a format meaningful for network transport. It is easier to assume thatthe object references are kept on the implementation side, and th

35、at at the client side CORBAbrings an object handle. This mapping allows the use of dynamic bindings as well as staticbindings.(7) The possibility should be left open of a special implementation choice to implement the PCTECORBA static bindings stubs to make direct use of the current PCTE C interface

36、: this could bemore efficient, but does not allow a distributed implementation of the IDL interface and mightpreclude the use of dynamic bindings.7.3 Sets and sequences(1) All sequence operations are grouped under the Pcte_sequence interface. A difficulty is that theoperation create is not part of t

37、he interface of an object. To keep the resulting generated C codein line with ECMA-158, it is still part of the Pcte_sequence interface, but the controlling object isa constant.(2) The input and/or result of a sequence create, insert, or get has been mapped to the IDL type any.7.4 References and nam

38、es(1) A departure from ECMA-149 is the introduction of an extra interface called PCTE_RF(Reference Factory), which contains those operations that return a reference but do not use areference as a controlling object.(2) The rest of the mapping is straightforward, with three interfaces Pcte_object_ref

39、erence,Pcte_link_reference, and Pcte_type_reference.7.5 Implementation aspects7.5.1 Source files(1) The source file structure is described in annex B. To simplify the IDL compilation process afew new IDL source files are introduced; this is because the ECMA-158 header structureincludes both types an

40、d operations, where in many cases the latter are not needed. With IDLthis leads to many forward references, eliminated by the introduction of oms_types.idl,discretionary_types.idl and mandatory_types.idl.- 4 -7.5.2 Naming changes in the IDL(1) All parameters with name containing attribute have been

41、renamed with attribute replaced byattribute_ref.(2) All parameters with name containing object have been removed (i.e. as controlling object) orrenamed with object replaced by object_ref.(3) The enumeration values PCTE_KEY, PCTE_NON_KEY to PCTE_KEY_ATTR,PCTE_NON_KEY_ATTR have been renamed to avoid c

42、lashes of the first item with Pcte_key,as IDL does not allow two identifiers which differ only by case to be used in the same scope.(4) The sequence enumeration items have been renamed to avoid clashes with the typedef of thesequences.7.5.3 Difference in generated C code(1) All unions have extra _d

43、and _u fields and are introduced by means of typedef. A result is thatthe resulting C code must be changed to use these extra fields.(2) The enumeration items cannot have a user-defined value. The generated header files must bechanged manually.8 Datatype mapping8.1 Basic datatypes(1) The datatype ma

44、pping for basic types follows ECMA-158 closely.(2) - string is mapped to the IDL type string;(3) - natural and integer are mapped to the IDL type long;(4) - boolean is mapped to the IDL type boolean;(5) - float is mapped to the IDL type float;(6) - Pcte_pathname, Pcte_object_reference, etc. as ident

45、ifier and interface name have beenchanged to be interfaces or pseudo-objects;(7) As IDL does not allow two identifiers which differ only by case to be used in the same scope, an“_EI“ suffix has been added to the enumeration items of the Pcte_sequence_type (whichotherwise would have been conflicting

46、with sequence names).8.2 Sequences(1) /* The source file “sequences.idl“ */(2) #ifndef PCTE_SEQUENCES_INCLUDED#define PCTE_SEQUENCES_INCLUDED 1(3) #include “types.idl“- 5 -(4) enum Pcte_sequence_type PCTE_ACCOUNTING_FILE_EI, PCTE_ACL_EI, PCTE_AUDIT_FILE_EI,PCTE_ATTRIBUTE_ASSIGNMENTS_EI, PCTE_H_ATTRI

47、BUTE_ASSIGNMENTS_EI,PCTE_ATTRIBUTE_NAMES_EI, PCTE_ATTRIBUTE_REFERENCES_EI,PCTE_BUFFER_EI, PCTE_CONFIDENTIALITY_CRITERIA_EI,PCTE_ENUMERATION_VALUE_TYPE_EI,PCTE_H_ENUMERATION_VALUE_TYPE_EI,PCTE_ENUMERATION_VALUE_TYPE_IN_SDS_EI, PCTE_GENERAL_CRITERIA_EI,PCTE_INTEGRITY_CRITERIA_EI, PCTE_KEY_TYPES_EI, PC

48、TE_H_KEY_TYPES_EI,PCTE_KEY_TYPES_IN_SDS_EI, PCTE_LINK_NAMES_EI,PCTE_LINK_SET_DESCRIPTORS_EI, PCTE_H_LINK_SET_DESCRIPTORS_EI,PCTE_LINK_REFERENCES_EI, PCTE_MESSAGE_TYPES_EI,PCTE_NAME_SEQUENCE_EI, PCTE_OBJECT_CRITERIA_EI,PCTE_OBJECT_REFERENCES_EI, PCTE_TYPE_NAMES_EI,PCTE_TYPE_NAMES_IN_SDS_EI, PCTE_TYPE

49、_REFERENCES_EI,PCTE_USER_CRITERIA_EI, PCTE_VOLUME_INFOS_EI,/* New Object-Oriented extension sequences */PCTE_PARAMETER_ITEMS_EI,PCTE_METHOD_REQUESTS_EI,PCTE_CONTEXT_ADOPTIONS_EI,PCTE_METHOD_REQUEST_IDS_EI;(5) typedef Object Pcte_sequence_element;(6) typedef Object Pcte_array_of_sequence_elements;(7) interface Pcte_sequence;(8) #define Pcte_null_sequence (Pcte_sequence) NULL(9) typedef Pcte_sequence Pcte_accounting_file;(10) typedef Pcte_sequence Pcte_audit_file;(11) typedef Pcte_sequence Pcte_attribute_names;(12) typedef Pcte_sequence Pcte_attribute_references;(13)