The Common Object Request Broker: Architecture and Specification

(1)

The Common Object Request Broker:

Architecture and Specification

Revision 2.0 July 1995

(2)

BNR Europe Ltd, Expersoft Corporation, IBM Corporation, ICL plc, IONA Technologies Ltd, Digital Equip- ment Corporation, Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Novell USG, Object Design, Inc., Sun Microsystems, Inc., SunSoft, Inc, hereby grant to the Object Management Group, Inc.

a non-exclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version.

Each of the copyright holders listed above agrees that not person shall be deemed to have infringed any copyright, patent or any other proprietary right of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.

NOTICE

The information contained in this document is subject to change without notice.

The material in this document details an Object Management Group specification in accordance with the license and notices set forth on this page. This document does not represent a commitment to implement any portion of this specification in any companies' products.

WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE OBJECT MANAGEMENT GROUP, DIGITAL EQUIPMENT CORPORATION,

HEWLETT-PACKARD COMPANY, HYPERDESK CORPORATION, NCR CORPORATION, OBJECT DESIGN, INC., SUN MICROSYSTEMS, INC., AND X/OPEN CO. LTD., MAKE NO WARRANTY OF ANY KIND WITH REGARDS TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The Object Management Group, Inc., Digital Equipment Corporation, Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Object Design, Inc., Sun Microsystems, Inc., and X/Open Co. Ltd. shall not be liable for errors contained herein or for inci- dental or consequential damages in connection with the furnishing, performance or use of this material.

The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its des-

(3)

RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013.

Hewlett-Packard Company is a trademark of Hewlett-Packard Company HyperDesk is a trademark of HyperDesk Corporation

Smalltalk/V is a registered trademark of Digitalk, Inc.

SunSoft is a trademark of Sun Microsystems, Inc., licensed to SunSoft, Inc.

X/Open and the "X" symbol are trademarks of X/Open Company Limited VisualAge is a trademark of International Business Machines Corporation VisualWorks is registered trademark of ParcPlace Systems, Inc.

Other names, products, and services may be the trademarks or registered trademarks of their respective holders.

(4)

(5)

CORBA V2.0 July 1995 iii

1. The Object Model . . . . 1-1

1.1 Overview . . . 1-1 1.2 Object Semantics . . . 1-2 1.2.1 Objects . . . 1-2 1.2.2 Requests . . . 1-2 1.2.3 Object Creation and Destruction. . . 1-3 1.2.4 Types . . . 1-4 1.2.5 Interfaces . . . 1-5 1.2.6 Operations. . . 1-5 1.2.7 Attributes . . . 1-7 1.3 Object Implementation . . . 1-7 1.3.1 The Execution Model: Performing Services . . . 1-7 1.3.2 The Construction Model . . . 1-8

(6)

2.1.1 Object Request Broker. . . 2-5 2.1.2 Clients. . . 2-6 2.1.3 Object Implementations . . . 2-6 2.1.4 Object References. . . 2-6 2.1.5 OMG Interface Definition Language . . . 2-7 2.1.6 Mapping of OMG IDL to Programming Languages

2-7

2.1.7 Client Stubs . . . 2-8 2.1.8 Dynamic Invocation Interface. . . 2-8 2.1.9 Implementation Skeleton . . . 2-8 2.1.10 Dynamic Skeleton Interface . . . 2-8 2.1.11 Object Adapters . . . 2-9 2.1.12 ORB Interface. . . 2-9 2.1.13 Interface Repository . . . 2-9 2.1.14 Implementation Repository. . . 2-10 2.2 Example ORBs. . . 2-10 2.2.1 Client- and Implementation-resident ORB . . . . 2-10 2.2.2 Server-based ORB . . . 2-10 2.2.3 System-based ORB . . . 2-10 2.2.4 Library-based ORB. . . 2-10 2.3 Structure of a Client . . . 2-11 2.4 Structure of an Object Implementation . . . 2-12 2.5 Structure of an Object Adapter. . . 2-14 2.6 Example Object Adapters. . . 2-16 2.6.1 Basic Object Adapter . . . 2-16 2.6.2 Library Object Adapter. . . 2-16 2.6.3 Object-Oriented Database Adapter . . . 2-16 2.7 The Integration of Foreign Object Systems . . . 2-16

3. OMG IDL Syntax and Semantics . . . . 3-1

3.1 About This Chapter . . . 3-1 3.2 Lexical Conventions. . . 3-2

(7)

CORBA V2.0 July 1995 v

3.4 OMG IDL Grammar. . . 3-9 3.5 OMG IDL Specification . . . 3-13 3.5.1 Module Declaration . . . 3-13 3.5.2 Interface Declaration . . . 3-13 3.6 Inheritance . . . 3-15 3.7 Constant Declaration . . . 3-17 3.7.1 Syntax . . . 3-17 3.7.2 Semantics . . . 3-18 3.8 Type Declaration . . . 3-19 3.8.1 Basic Types. . . 3-20 3.8.2 Constructed Types . . . 3-22 3.8.3 Template Types . . . 3-25 3.8.4 Complex Declarator . . . 3-26 3.9 Exception Declaration . . . 3-26 3.10 Operation Declaration . . . 3-27 3.10.1 Operation Attribute. . . 3-28 3.10.2 Parameter Declarations. . . 3-28 3.10.3 Raises Expressions . . . 3-29 3.10.4 Context Expressions . . . 3-29 3.11 Attribute Declaration . . . 3-30 3.12 CORBA Module. . . 3-31 3.13 Names and Scoping . . . 3-31 3.14 Differences from C++ . . . 3-33 3.15 Standard Exceptions. . . 3-33 3.15.1 Standard Exceptions Definitions . . . 3-34 3.15.2 Object Non-Existence . . . 3-35

4. Dynamic Invocation Interface . . . . 4-1

4.1 Overview . . . 4-1 4.1.1 Common Data Structures . . . 4-1 4.1.2 Memory Usage . . . 4-3 4.1.3 Return Status and Exceptions . . . 4-3 4.2 Request Operations . . . 4-4 4.2.1 create_request . . . 4-4 4.2.2 add_arg . . . 4-6 4.2.3 invoke . . . 4-7 4.2.4 delete . . . 4-7 4.3 Deferred Synchronous Operations . . . 4-7 4.3.1 send. . . 4-7

(8)

4.3.4 get_next_response . . . 4-9 4.4 List Operations. . . 4-10 4.4.1 create_list . . . 4-10 4.4.2 add_item . . . 4-11 4.4.3 free . . . 4-11 4.4.4 free_memory. . . 4-11 4.4.5 get_count . . . 4-12 4.4.6 create_operation_list. . . 4-12 4.5 Context Objects . . . 4-12 4.6 Context Object Operations . . . 4-13 4.6.1 get_default_context . . . 4-14 4.6.2 set_one_value . . . 4-15 4.6.3 set_values . . . 4-15 4.6.4 get_values . . . 4-15 4.6.5 delete_values . . . 4-16 4.6.6 create_child . . . 4-16 4.6.7 delete . . . 4-16 4.7 Native Data Manipulation . . . 4-17

5. Dynamic Skeleton Interface . . . . 5-1

5.1 Overview . . . 5-2 5.2 Explicit Request State: ServerRequest Pseudo Object . . . 5-2 5.3 Dynamic Skeleton Interface: Language Mapping . . . 5-3

5.3.1 ServerRequest’s Handling of Operation Parameters 5-3

5.3.2 Registering Dynamic Implementation Routines 5-4

6. The Interface Repository . . . . 6-1

6.1 Overview . . . 6-1 6.2 Scope of an Interface Repository . . . 6-2 6.3 Implementation Dependencies . . . 6-3 6.3.1 Managing Interface Repositories . . . 6-4

(9)

CORBA V2.0 July 1995 vii

6.5.1 Supporting Type Definitions . . . 6-8 6.5.2 IRObject . . . 6-9 6.5.3 Contained . . . 6-9 6.5.4 Container . . . 6-11 6.5.5 IDLType . . . 6-15 6.5.6 Repository . . . 6-16 6.5.7 ModuleDef . . . 6-17 6.5.8 ConstantDef Interface . . . 6-17 6.5.9 TypedefDef Interface . . . 6-18 6.5.10 StructDef . . . 6-19 6.5.11 UnionDef . . . 6-19 6.5.12 EnumDef. . . 6-20 6.5.13 AliasDef . . . 6-21 6.5.14 Read Interface. . . 6-21 6.5.15 PrimitiveDef . . . 6-21 6.5.16 StringDef . . . 6-22 6.5.17 SequenceDef . . . 6-22 6.5.18 ArrayDef. . . 6-23 6.5.19 ExceptionDef . . . 6-23 6.5.20 AttributeDef . . . 6-24 6.5.21 OperationDef . . . 6-25 6.5.22 InterfaceDef . . . 6-27 6.6 RepositoryIds . . . 6-30 6.6.1 OMG IDL Format. . . 6-30 6.6.2 DCE UUID Format . . . 6-30 6.6.3 LOCAL Format . . . 6-30 6.6.4 Pragma Directives for RepositoryId . . . 6-31 6.7 TypeCodes . . . 6-33 6.7.1 The TypeCode Interface . . . 6-34 6.7.2 TypeCode Constants . . . 6-38 6.7.3 Creating TypeCodes . . . 6-39 6.8 OMG IDL for Interface Repository . . . 6-41

7. ORB Interface . . . . 7-1

7.1 Converting Object References to Strings . . . 7-1 7.2 Object Reference Operations . . . 7-2

7.2.1 Determining the Object Implementation and

Interface . . . 7-3 7.2.2 Duplicating and Releasing Copies of Object

References . . . 7-3 7.2.3 Nil Object References. . . 7-4

(10)

7.2.6 Object Reference Identity . . . 7-5 7.3 Overview: ORB and OA Initialization and Initial References 7-6 7.4 ORB Initialization . . . 7-6 7.5 OA and BOA Initialization. . . 7-8 7.6 Obtaining Initial Object References . . . 7-10

8. The Basic Object Adapter. . . . 8-1

8.1 Role of the Basic Object Adapter . . . 8-1 8.2 Basic Object Adapter Interface . . . 8-3 8.2.1 Registration of Implementations. . . 8-5 8.2.2 Activation and Deactivation of Implementations 8-5 8.2.3 Generation and Interpretation of Object References

8-8

8.2.4 Authentication and Access Control. . . 8-9 8.2.5 Persistent Storage . . . 8-10 Appendix A Standard OMG IDL Types . . . A-1

9. Interoperability Overview . . . . 9-1

9.1 Elements of Interoperability. . . 9-1 9.1.1 ORB Interoperability Architecture . . . 9-1 9.1.2 Inter-ORB Bridge Support . . . 9-2 9.1.3 General Inter-ORB Protocol (GIOP) . . . 9-2 9.1.4 Internet Inter-ORB Protocol (IIOP) . . . 9-3 9.1.5 Environment-Specific Inter-ORB Protocols (ESIOPs)

9-4

9.2 Relationship to Previous Versions of CORBA . . . 9-4 9.3 Examples of Interoperability Solutions . . . 9-4 9.3.1 Example 1 . . . 9-5 9.3.2 Example 2 . . . 9-5 9.3.3 Example 3 . . . 9-5 9.3.4 Interoperability Compliance . . . 9-5 9.4 Motivating Factors . . . 9-8

(11)

CORBA V2.0 July 1995 ix

10. ORB Interoperability Architecture . . . 10-1

10.1 Overview . . . 10-1 10.1.1 Domains . . . 10-1 10.1.2 Bridging Domains. . . 10-2 10.2 ORBs and ORB Services . . . 10-2 10.2.1 The Nature of ORB Services . . . 10-3 10.2.2 ORB Services and Object Requests . . . 10-3 10.2.3 Selection of ORB Services . . . 10-4 10.3 Domains . . . 10-4 10.3.1 Definition of a Domain . . . 10-5 10.3.2 Mapping Between Domains: Bridging . . . 10-6 10.4 Interoperability Between ORBs . . . 10-6 10.4.1 ORB Services and Domains . . . 10-7 10.4.2 ORBs and Domains . . . 10-7 10.4.3 Interoperability Approaches . . . 10-8 10.4.4 Policy-Mediated Bridging. . . 10-10 10.4.5 Configurations of Bridges in Networks. . . 10-10 10.5 Object Addressing . . . 10-11 10.5.1 Domain-relative Object Referencing . . . 10-12 10.5.2 Handling of Referencing Between Domains. . . 10-12 10.6 An Information Model for Object References . . . 10-14 10.6.1 What Information do Bridges Need? . . . 10-14 10.6.2 Interoperable Object References: IORs . . . 10-14 10.6.3 Profile and Component Composition in IORs. . 10-16 10.6.4 IOR Creation and Scope . . . 10-17 10.6.5 Stringified Object References . . . 10-17 10.6.6 Object Service Context . . . 10-18

11. Building Inter-ORB Bridges . . . 11-1

11.1 In-Line and Request-Level Bridging . . . 11-1 11.1.1 In-line Bridging . . . 11-2 11.1.2 Request-level bridging . . . 11-3 11.1.3 Collocated ORBs . . . 11-4 11.2 Proxy Creation and Management . . . 11-4 11.3 Interface-specific Bridges and Generic Bridges . . . 11-5 11.4 Building Generic Request-Level Bridges . . . 11-5 11.5 Bridging Non-Referencing Domains . . . 11-6 11.6 Bootstrapping Bridges . . . 11-7

(12)

12.2 General Inter-ORB Protocol Overview . . . 12-2 12.2.1 Common Data Representation (CDR) . . . 12-2 12.2.2 GIOP Message Overview . . . 12-3 12.2.3 GIOP Message Transfer . . . 12-3 12.3 CDR Transfer Syntax . . . 12-4 12.3.1 Primitive Types. . . 12-4 12.3.2 OMG IDL Constructed Types. . . 12-8 12.3.3 Encapsulation . . . 12-9 12.3.4 Pseudo-Object Types . . . 12-9 12.3.5 Object References. . . 12-15 12.4 GIOP Message Formats . . . 12-15 12.4.1 GIOP Message Header . . . 12-15 12.4.2 Reply Message . . . 12-18 12.4.3 CancelRequest Message . . . 12-20 12.4.4 LocateRequest Message . . . 12-21 12.4.5 LocateReply Message . . . 12-21 12.4.6 CloseConnection Message . . . 12-23 12.4.7 MessageError Message . . . 12-23 12.5 GIOP Message Transport . . . 12-23 12.5.1 Connection Management . . . 12-24 12.5.2 Message Ordering. . . 12-25 12.6 Object Location . . . 12-25 12.7 Internet Inter-ORB Protocol (IIOP) . . . 12-27 12.7.1 TCP/IP Connection Usage . . . 12-27 12.7.2 IIOP IOR Profiles . . . 12-27 12.8 OMG IDL for the GIOP and IIOP Specifications. . . 12-29 12.8.1 GIOP Module . . . 12-29 12.8.2 IIOP Module . . . 12-31

13. The DCE ESIOP . . . 13-1

13.1 Goals of the DCE Common Inter-ORB Protocol . . . 13-1

(13)

CORBA V2.0 July 1995 xi

13.3.2 Array-based Interface . . . 13-7 13.4 DCE-CIOP Message Formats. . . 13-10 13.4.1 DCE_CIOP Invoke Request Message . . . 13-10 13.4.2 DCE-CIOP Invoke Response Message . . . 13-11 13.4.3 DCE-CIOP Locate Request Message . . . 13-13 13.4.4 DCE-CIOP Locate Response Message . . . 13-14 13.5 DCE-CIOP Object References . . . 13-16 13.5.1 DCE-CIOP String Binding Component . . . 13-16 13.5.2 DCE-CIOP Binding Name Component . . . 13-17 13.5.3 DCE-CIOP No Pipes Component . . . 13-18 13.5.4 Object Key Component . . . 13-19 13.5.5 Endpoint ID Component . . . 13-19 13.5.6 Location Policy Component . . . 13-20 13.6 DCE-CIOP Object Location. . . 13-21 13.6.1 Location Mechanism Overview . . . 13-21 13.6.2 Activation . . . 13-22 13.6.3 Basic Location Algorithm. . . 13-22 13.6.4 Use of the Location Policy and the Endpoint ID

13-23

13.7 OMG IDL for the DCE CIOP Module . . . 13-24 13.8 References for this Chapter . . . 13-26 Appendix B OMG IDL Tags . . . B-1

14. C Language Mapping . . . 14-1

14.1 Requirements for a Language Mapping . . . 14-1 14.1.1 Basic Data Types . . . 14-2 14.1.2 Constructed Data Types . . . 14-2 14.1.3 Constants . . . 14-2 14.1.4 Objects . . . 14-2 14.1.5 Invocation of Operations . . . 14-2 14.1.6 Exceptions . . . 14-3 14.1.7 Attributes . . . 14-3 14.1.8 ORB Interfaces . . . 14-4 14.2 Scoped Names . . . 14-4 14.3 Mapping for Interfaces . . . 14-5 14.4 Inheritance and Operation Names . . . 14-6 14.5 Mapping for Attributes. . . 14-7 14.6 Mapping for Constants . . . 14-8 14.7 Mapping for Basic Data Types . . . 14-8

(14)

14.10 Mapping for Union Types . . . 14-10 14.11 Mapping for Sequence Types . . . 14-11 14.12 Mapping for Strings . . . 14-14 14.13 Mapping for Arrays . . . 14-15 14.14 Mapping for Exception Types . . . 14-16 14.15 Implicit Arguments to Operations . . . 14-16 14.16 Interpretation of Functions with Empty Argument Lists . . . 14-17 14.17 Argument Passing Considerations . . . 14-17 14.18 Return Result Passing Considerations . . . 14-18 14.19 Summary of Argument/Result Passing. . . 14-19 14.20 Handling Exceptions . . . 14-21 14.21 Method Routine Signatures . . . 14-23 14.22 Include Files. . . 14-24 14.23 Pseudo-objects . . . 14-24 14.24 Mapping of the Dynamic Skeleton Interface to C . . . 14-25 14.24.1 Mapping of ServerRequest to C . . . 14-25 14.24.2 Mapping of BOA’s Dynamic Implementation Routine

to C . . . 14-27 14.25 BOA: Mapping for Object Implementations . . . 14-27 14.25.1 Operation-specific Details . . . 14-27 14.25.2 Method Signatures . . . 14-27 14.25.3 Binding Methods to Skeletons . . . 14-29 14.25.4 BOA and ORB Operations . . . 14-29 14.26 ORB and OA/BOA Initialization Operations . . . 14-30 14.27 Operations for Obtaining Initial Object References . . . 14-32

15. C++ Mapping Overview . . . 15-1

15.1 Key Design Decisions . . . 15-1 15.1.1 Compliance. . . 15-1 15.1.2 C++ Implementation Requirements . . . 15-2

(15)

CORBA V2.0 July 1995 xiii

16.1.2 C++ Type Size Requirements . . . 16-2 16.1.3 CORBA Module . . . 16-2 16.2 Mapping for Modules. . . 16-3 16.3 Mapping for Interfaces . . . 16-3 16.3.1 Object Reference Types . . . 16-4 16.3.2 Widening Object References . . . 16-5 16.3.3 Object Reference Operations . . . 16-5 16.3.4 Narrowing Object References. . . 16-6 16.3.5 Nil Object Reference . . . 16-7 16.3.6 Interface Mapping Example . . . 16-7 16.4 Mapping for Constants . . . 16-9 16.5 Mapping for Basic Data Types . . . 16-10 16.6 Mapping for Enums . . . 16-11 16.7 Mapping For String Types . . . 16-11 16.8 Mapping for Structured Types . . . 16-12 16.8.1 T_var Types . . . 16-13 16.9 Mapping for Struct Types. . . 16-15 16.10 Mapping for Union Types . . . 16-17 16.11 Mapping for Sequence Types . . . 16-21 16.11.1 Sequence Example . . . 16-23 16.11.2 Using the “release” Constructor Parameter. . . . 16-24 16.11.3 Additional Memory Management Functions . . 16-25 16.11.4 Sequence T_var Type . . . 16-26 16.12 Mapping For Array Types . . . 16-26 16.13 Mapping For Typedefs . . . 16-28 16.14 Mapping for the Any Type . . . 16-29

16.14.1 . . . . Handling Typed Values . . . 16-30 16.14.2 . . . .

Insertion into Any. . . 16-30 16.14.3 . . . .

Extraction From Any . . . 16-33 16.14.4 . . . .

Distinguishing boolean, octet, char, and bounded string. . . 16-35 16.14.5 Widening to Object . . . 16-37 16.14.6 . . . .

Handling Untyped Values . . . 16-38 16.14.7 Any Constructors, Destructor, Assignment Operator

16-39

(16)

16.15 Mapping for Exception Types . . . 16-40 16.16 Mapping For Operations and Attributes . . . 16-42 16.17 Implicit Arguments to Operations . . . 16-43 16.18 Argument Passing Considerations . . . 16-43

17. Mapping of Pseudo Objects to C++ . . . 17-1

17.1 Usage . . . 17-1 17.2 Mapping Rules . . . 17-2 17.3 Relation to the C PIDL Mapping . . . 17-3 17.4 Environment. . . 17-3 17.4.1 Environment Interface . . . 17-4 17.4.2 Environment C++ Class . . . 17-4 17.4.3 Differences from C-PIDL . . . 17-4 17.4.4 Memory Management. . . 17-4 17.5 NamedValue . . . 17-5 17.5.1 NamedValue Interface . . . 17-5 17.5.2 NamedValue C++ Class . . . 17-5 17.5.3 Differences from C-PIDL . . . 17-5 17.5.4 Memory Management. . . 17-5 17.6 NVList . . . 17-6 17.6.1 NVList Interface . . . 17-6 17.6.2 NVList C++ Class . . . 17-6 17.6.3 Differences from C-PIDL . . . 17-7 17.6.4 Memory Management. . . 17-7 17.7 Request. . . 17-7 17.7.1 Request Interface . . . 17-10 17.7.2 Request C++ Class . . . 17-10 17.7.3 Differences from C-PIDL . . . 17-11 17.7.4 Memory Management. . . 17-12 17.8 Context. . . 17-12 17.8.1 Context Interface . . . 17-12

(17)

CORBA V2.0 July 1995 xv

17.10 TypeCode . . . 17-14 17.10.1 TypeCode Interface. . . 17-15 17.10.2 TypeCode C++ Class . . . 17-16 17.10.3 Differences from C-PIDL . . . 17-16 17.10.4 Memory Management. . . 17-16 17.11 BOA . . . 17-17 17.11.1 BOA Interface . . . 17-17 17.11.2 BOA C++ Class . . . 17-17 17.11.3 Differences from C-PIDL . . . 17-18 17.12 ORB . . . 17-18 17.12.1 ORB Interface. . . 17-18 17.12.2 ORB C++ Class . . . 17-19 17.12.3 Differences from C-PIDL . . . 17-19 17.12.4 Mapping of ORB and OA/BOA Initialization

Operations . . . 17-20 17.12.5 Mapping of Operations to Obtain Initial Object

References . . . 17-22 17.13 Object. . . 17-22 17.13.1 Object Interface . . . 17-23 17.13.2 Object C++ Class . . . 17-23

18. Server-Side Mapping. . . 18-1

18.1 Implementing Interfaces. . . 18-1 18.2 Implementing Operations . . . 18-2 18.3 Examples . . . 18-3 18.3.1 Using C++ Inheritance for Interface Implementation

18-3

18.3.2 Using Delegation for Interface Implementation 18-4 18.4 Mapping of Dynamic Skeleton Interface to C++ . . . 18-6

18.4.1 . . . . Mapping of ServerRequest to C++ . . . 18-6 18.4.2 Handling Operation Parameters and Results. . . 18-6 18.4.3 Sample Usage . . . 18-7 18.4.4 Reporting Exceptions . . . 18-7 18.4.5 Mapping of BOA’s Dynamic Implementation

Routine . . . 18-8 Appendix C C++ Definitions for CORBA . . . C-1 Appendix D Alternative Mappings For C++ Dialects. . . D-1 Appendix E C++ Keywords . . . E-1

(18)

19.1.1 Consistency of Style, Flexibility and Portability of Implementation . . . 19-2 19.2 Organization of the Smalltalk Mapping . . . 19-2 19.3 Glossary of Terms . . . 19-3 19.4 Implementation Constraints . . . 19-3 19.4.1 Avoiding Name Space Collisions . . . 19-3 19.4.2 Limitations on OMG IDL Types. . . 19-4 19.5 Smalltalk Implementation Requirements . . . 19-4

20. Mapping of OMG IDL to Smalltalk . . . 20-1

20.1 Mapping Summary . . . 20-1 20.2 Conversion of Names to Smalltalk Identifiers . . . 20-2 20.3 Mapping for Interfaces . . . 20-3 20.4 Memory Usage . . . 20-3 20.5 Mapping for Objects . . . 20-3 20.6 Invocation of Operations . . . 20-3 20.7 Mapping for Attributes. . . 20-4 20.7.1 Mapping for Constants . . . 20-5 20.8 Mapping for Basic Data Types . . . 20-5 20.9 Mapping for the Any Type . . . 20-7 20.10 Mapping for Enums . . . 20-7 20.11 Mapping for Struct Types. . . 20-8 20.12 Mapping for Union Types . . . 20-8 20.12.1 Implicit Binding . . . 20-9 20.12.2 Explicit Binding . . . 20-9 20.13 Mapping for Sequence Types . . . 20-10 20.14 Mapping for String Types. . . 20-10 20.15 Mapping for Array Types . . . 20-10 20.16 Mapping for Exception Types . . . 20-10 20.17 Mapping for Operations . . . 20-10

(19)

CORBA V2.0 July 1995 xvii

21. Mapping of Pseudo Objects to Smalltalk. . . 21-1

21.1 CORBA::Request . . . 21-1 21.2 CORBA::Context . . . 21-2 21.3 CORBA::Object . . . 21-3 21.4 CORBA::ORB . . . 21-3 21.5 CORBA::NamedValue . . . 21-4 21.6 CORBA::NVList . . . 21-5 Appendix F Glossary . . . 7

(20)

(21)

CORBA V2.0 July 1995 iii

Preface

0.1 About This Document

Under the terms of the collaboration between OMG and X/Open Co Ltd, this document is a candidate for endorsement by X/Open, initially as a Preliminary Specification and later as a full CAE Specification. The collaboration between OMG and X/Open Co Ltd ensures joint review and cohesive support for emerging object-based specifications.

X/Open Preliminary Specifications undergo close scrutiny through a review process at X/Open before publication and are inherently stable specifications. Upgrade to full CAE Specification, after a reasonable interval, takes place following further review by X/Open. This further review considers the implementation experience of members and the full implications of conformance and branding.

0.1.1 Object Management Group

The Object Management Group, Inc. (OMG) is an international organization supported by over 500 members, including information system vendors, software developers and users. Founded in 1989, the OMG promotes the theory and practice of object-oriented technology in software development. The organization's charter includes the

establishment of industry guidelines and object management specifications to provide a common framework for application development. Primary goals are the reusability, portability, and interoperability of object-based software in distributed, heterogeneous environments. Conformance to these specifications will make it possible to develop a heterogeneous applications environment across all major hardware platforms and operating systems.

OMG's objectives are to foster the growth of object technology and influence its direction by establishing the Object Management Architecture (OMA). The OMA provides the conceptual infrastructure upon which all OMG specifications are based.

(22)

the world's largest information system suppliers, user organizations and software companies. Its mission is to bring to users greater value from computing, through the practical implementation of open systems. X/Open’s strategy for achieving its mission is to combine existing and emerging standards into a comprehensive, integrated systems environment called the Common Applications Environment (CAE).

The components of the CAE are defined in X/Open CAE specifications. These contain, among other things, an evolving portfolio of practical application programming interfaces (APIs), which significantly enhance portability of application programs at the source code level. The APIs also enahance the interoperability of applications by providing definitions of, and references to, protocols and protocol profiles.

The X/Open specifications are also supported by an extensive set of conformance tests and by the X/Open trademark (XPG brand), which is licensed by X/Open and is carried only on products that comply with the CAE specifications.

0.2 Intended Audience

The architecture and specifications described in this manual are aimed at software designers and developers who want to produce applications that comply with OMG standards for the Object Request Broker (ORB). The benefit of compliance is, in general, to be able to produce interoperable applications that are based on distributed, interoperating objects. As defined by the Object Management Group (OMG) in the Object Management Architecture Guide, the ORB provides the mechanisms by which objects transparently make requests and receive responses. Hence, the ORB provides interoperability between applications on different machines in heterogeneous

distributed environments and seamlessly interconnects multiple object systems.

0.3 Context of CORBA

The key to understanding the structure of the CORBA architecture is the Reference Model, which consists of the following components:

• Object Request Broker, which enables objects to transparently make and receive requests and responses in a distributed environment. It is the foundation for building applications from distributed objects and for interoperability between applications in hetero- and homogeneous environments. The architecture and specifications of the Object Request Broker are described in this manual.

• Object Services, a collection of services (interfaces and objects) that support

(23)

CORBA V2.0 Associated Documents July 1995 v

• Common Facilities, a collection of services that many applications may share, but which are not as fundamental as the Object Services. For instance, a system management or electronic mail facility could be classified as a common facility.

Information about Common Facilities will be contained in CORBAfacilities:

Common Facilities, to be published in mid-1995.

• Application Objects, which are products of a single vendor on in-house development group which controls their interfaces. Application Objects

correspond to the traditional notion of applications, so they are not standardized by OMG. Instead, Application Objects constitute the uppermost layer of the Reference Model.

The Object Request Broker, then, is the core of the Reference Model. It is like a telephone exchange, providing the basic mechanism for making and receiving calls.

Combined with the Object Services, it ensures meaningful communication between CORBA-compliant applications.

(For more information about the OMG Reference Model and the OMG Object Model, refer to the Object Management Architecture Guide).

0.4 Associated Documents

The CORBA documentation set includes the following books:

• Object Management Architecture Guide defines the OMG’s technical objectives and terminology and describes the conceptual models upon which OMG standards are based. It also provides information about the policies and procedures of OMG, such as how standards are proposed, evaluated, and accepted.

• CORBA: Common Object Request Broker Architecture and Specification contains the architecture and specifications for the Object Request Broker.

• CORBAservices: Common Object Services Specification contains specifications for the object services.

• CORBAfacilities: Common Facilities will contain specifications for Common Facilites; it is currently scheduled for publication in mid-1995.

OMG collects information for each book in the documentation set by issuing Requests for Information, Requests for Proposals, and Requests for Comment and, with its membership, evaluating the responses. Specifications are adopted as standards only when representatives of the OMG membership accept them as such by vote.

To obtain books in the documentation set, or other OMG publications, refer to the enclosed subscription card or contact the Object Management Group, Inc. at:

OMG Headquarters 492 Old Connecticut Path

Framingham, MA 01701 USA

Tel: +1-508-820 4300 Fax: +1-508-820 4303

[email protected] http://www.omg.org/

(24)

Language Mappings. These divisions reflect the compliance points of CORBA, as explained in Section 0.6, “Definition of CORBA Compliance,” on page vii. In addition to this preface, CORBA: Common Object Request Broker Architecture and

Specification contains the following chapters:

Core

The Object Model describes the compuation model that underlies the CORBA architecture.

Architecture describes the overall structure of the ORB architecture and includes information about CORBA interfaces and implmentations.

OMG IDL Syntax and Semantics describes OMG interface definition language (OMG IDL), which is the language used to describe the interfaces that client objects call and object implementations provide.

The Dynamic Invocation Interface describes the DII, the client’s side of the interface that allows dynamic creation and invocation of request to objects.

The Dynamic Skeleton Interfacedescribesthe DSI, the server’s-side interface that can deliver requests from an ORB to an object implementation that does not have compile- time knowledge of the type of the object it is implementing. DSI is the server’s analogue of the client’s Dynamic Invocation Interface (DII).

Interface Repository describes the component of the ORB that manages and provides access to a collection of object definitions.

ORB Interface describes the interface to the ORB functions that do not depend on object adapters: these operations are the same for all ORBs and object

implementations.

Basic Object Adapter describes the primary interface than an implementation uses to access ORB functions.

An appendix that contains standard OMG IDL types.

Interoperability

Interoperability Overview explains the interoperability architecture and introduces the subjects pertaining to interoperability: inter-ORB bridges; general and Internet inter-ORB protocols (GIOP and IIOP); and environment-specific, inter-ORB protocols

(25)

CORBA V2.0 Definition of CORBA Compliance July 1995 vii Inter-ORB Protocols describes the general inter-ORB protocol (GIOP) and includes information about the GIOP’s goals, syntax, format, transport, and object location.

This chapter also includes information about the Internet inter-ORB protocol (IIOP).

Environment-Specific Inter-ORB Protocol (ESIOP) desribes a protocol for the OSF DCE environment. The protocol is called the DCE Environment Inter-ORB Protocol (DCE ESIOP).

An appendix containing OMG IDL tags that can identify an Object Service, a component, or a profile.

C Language Mapping

Mapping of OMG IDL to C maps OMG IDL to the C programming language.

C++ Language Mapping

C++ Mapping Overview introduces the mapping of OMG IDL to the C++

programming language.

Mapping of OMG IDL to C++ maps the constructs of OMG IDL to the C++

Mapping of Pseudo Objects to C++ maps OMG IDL pseudo objects to the C++

Server-Side Mapping explains the portability constraints for an object implementation written in C++.

The C++ language mapping also includes several appendices. One contains C++

definitions for CORBA, another contains alternate C++ mappings, and another contains C++ keywords.

Smalltalk Language Mapping

Smalltalk Mapping Overview introduces the mapping of OMG IDL to the Smalltalk programming language.

Mapping of OMG IDL to Smalltalk maps the constructs of OMG IDL to the Smalltalk programming language.

Mapping of Pseudo Objects to Smalltalk maps OMG IDL pseudo objects to Smalltalk.

0.6 Definition of CORBA Compliance

As described in the OMA Guide, OMG’s Core Object Model consists of a core and components. Likewise, the body of CORBA specifications is divided into core and component-like specifications. (The structure of this manual reflects that division.) The CORBA family of specifications are as follows:

(26)

• Mapping of OMG IDL to C programming language, as specified in Chapter 14

• Mapping of OMG IDL to C++ programming language, as specified in Chapters 15–18

• Mapping of OMG IDL to Smalltalk programming language, as specified in Chapters 19–21

Additional OMG IDL mappings will be available with future versions of CORBA.

When compliance branding machinery is in place, each of the CORBA specifications listed here will be associated with a separate branding stamp.

The minimum required for a CORBA-compliant system is adherence to the

specifications in CORBA Core and one mapping. Each additional language mapping is a separate, optional compliance point. Optional means users aren’t required to implement these points if they are unnecessary at their site, but if implemented, they must adhere to the CORBA specifications to be called CORBA-compliant. For instance, if a vendor supports C++, their ORB must comply with the OMG IDL to C++

binding specified in this manual.

Interoperability is a separate compliance point.

0.7 Typographical Conventions

The type styles shown below are used in this document to distinguish programming statements from ordinary English. However, these conventions are not used in tables or section headings, where no distinction is necessary, nor are the type styles used in text where their density would be distracting.

Helvetica bold OMG Interface Definition Language (OMG IDL) language and syntax elements

Times bold Pseudo-OMG IDL (PIDL) language elements Courier bold Programming language elements Courier bold italic Smalltalk protocol descriptions

Code examples written in PIDL and programming languages are further identified by a comment; unidentified examples are written in OMG IDL.

0.8 Acknowledgements

(27)

CORBA V2.0 Acknowledgements July 1995 ix

• IONA Technologies Ltd

• Digital Equipment Corporation

• Hewlett-Packard Company

• HyperDesk Corporation

• NCR Corporation

• Novell USG

• Object Design, Inc

• Sun Microsystems Inc

• SunSoft, Inc

In addition to the preceding contributors, the OMG would like to acknowledge Mark Linton at Silicon Graphics and Doug Lea at the State University of New York at Oswego for their work on the C++ mapping.

(28)

(29)

CORBA V2.0 July 1995 1-1

The Object Model 1

This chapter describes the concrete object model that underlies the CORBA

architecture. The model is derived from the abstract Core Object Model defined by the Object Management Group in the Object Management Architecture Guide.

(Information about the OMA Guide and other books in the CORBA documentation set is provided in this document’s preface.)

1.1 Overview

The object model provides an organized presentation of object concepts and terminology. It defines a partial model for computation that embodies the key characteristics of objects as realized by the submitted technologies. The OMG object model is abstract in that it is not directly realized by any particular technology. The model described here is a concrete object model. A concrete object model may differ from the abstract object model in several ways:

• It may elaborate the abstract object model by making it more specific, for example, by defining the form of request parameters or the language used to specify types

• It may populate the model by introducing specific instances of entities defined by the model, for example, specific objects, specific operations, or specific types

• It may restrict the model by eliminating entities or placing additional restrictions on their use

An object system is a collection of objects that isolates the requestors of services (clients) from the providers of services by a well-defined encapsulating interface. In particular, clients are isolated from the implementations of services as data

representations and executable code.

The object model first describes concepts that are meaningful to clients, including such concepts as object creation and identity, requests and operations, types and signatures.

It then describes concepts related to object implementations, including such concepts as methods, execution engines, and activation.

(30)

The object model is most specific and prescriptive in defining concepts meaningful to clients. The discussion of object implementation is more suggestive, with the intent of allowing maximal freedom for different object technologies to provide different ways of implementing objects.

There are some other characteristics of object systems that are outside the scope of the object model. Some of these concepts are aspects of application architecture, some are associated with specific domains to which object technology is applied. Such concepts are more properly dealt with in an architectural reference model. Examples of excluded concepts are compound objects, links, copying of objects, change management, and transactions. Also outside the scope of the object model is the model of control and execution.

This object model is an example of a classical object model, where a client sends a message to an object. Conceptually, the object interprets the message to decide what service to perform. In the classical model, a message identifies an object and zero or more actual parameters. As in most classical object models, a distinguished first parameter is required, which identifies the operation to be performed; the interpretation of the message by the object involves selecting a method based on the specified operation. Operationally, of course, method selection could be performed either by the object or the ORB.

1.2 Object Semantics

An object system provides services to clients. A client of a service is any entity capable of requesting the service.

This section defines the concepts associated with object semantics, that is, the concepts relevant to clients.

1.2.1 Objects

An object system includes entities known as objects. An object is an identifiable, encapsulated entity that provides one or more services that can be requested by a client.

1.2.2 Requests

Clients request services by issuing requests. A request is an event, i.e. something that occurs at a particular time. The information associated with a request consists of an operation, a target object, zero or more (actual) parameters, and an optional request

(31)

CORBA V2.0 Object Semantics July 1995 1-3

1

an invocation structure, add arguments to the invocation structure, and to issue the invocation (Refer to the C Language Mapping chapter and the Dynamic Invocation Interface chapter for descriptions of these request forms).

A value is anything that may be a legitimate (actual) parameter in a request. A value may identify an object, for the purpose of performing the request. A value that identifies an object is called an object name. More particularly, a value is an instance of an OMG IDL datatype.

An object reference is an object name that reliably denotes a particular object.

Specifically, an object reference will identify the same object each time the reference is used in a request (subject to certain pragmatic limits of space and time). An object may be denoted by multiple, distinct object references.

A request may have parameters that are used to pass data to the target object; it may also have a request context which provides additional information about the request.

A request causes a service to be performed on behalf of the client. One outcome of performing a service is returning to the client the results, if any, defined for the request.

If an abnormal condition occurs during the performance of a request, an exception is returned. The exception may carry additional return parameters particular to that exception.

The request parameters are identified by position. A parameter may be an input parameter, an output parameter, or an input-output parameter. A request may also return a single result value, as well as any output parameters.

The following semantics hold for all requests:

• Any aliasing of parameter values is neither guaranteed removed nor guaranteed to be preserved

• The order in which aliased output parameters are written is not guaranteed

• Any output parameters are undefined if an exception is returned

• The values that can be returned in an input-output parameter may be constrained by the value that was input

Descriptions of the values and exceptions that are permitted, see Types on page 1-4 and Exceptions on page 1-6.

1.2.3 Object Creation and Destruction

Objects can be created and destroyed. From a client’s point of view, there is no special mechanism for creating or destroying an object. Objects are created and destroyed as an outcome of issuing requests. The outcome of object creation is revealed to the client in the form of an object reference that denotes the new object.

(32)

1.2.4 Types

A type is an identifiable entity with an associated predicate (a single-argument mathematical function with a boolean result) defined over values. A value satisfies a type if the predicate is true for that value. A value that satisfies a type is called a member of the type.

Types are used in signatures to restrict a possible parameter or to characterize a possible result.

The extension of a type is the set of values that satisfy the type at any particular time.

An object type is a type whose members are objects (literally, values that identify objects). In other words, an object type is satisfied only by (values that identify) objects.

Constraints on the data types in this model are shown in this section.

Basic types:

• 16-bit and 32-bit signed and unsigned 2’s complement integers

• 32-bit and 64-bit IEEE floating point numbers

• Characters, as defined in ISO Latin-1 (8859.1)

• A boolean type taking the values TRUE and FALSE

• An 8-bit opaque datatype, guaranteed to not undergo any conversion during transfer between systems

• Enumerated types consisting of ordered sequences of identifiers

• A string type which consists of a variable-length array of characters; the length of the string is available at runtime

• A type “any” which can represent any possible basic or constructed type Constructed types:

• A record type (called struct), consisting of an ordered set of (name,value) pairs

• A discriminated union type, consisting of a discriminator followed by an instance of a type appropriate to the discriminator value

• A sequence type which consists of a variable-length array of a single type; the length of the sequence is available at runtime

• An array type which consists of a fixed-length array of a single type

• An interface type, which specifies the set of operations which an instance of that type must support

Values in a request are restricted to values that satisfy these type constraints. The legal values are shown in FIG. 1 on page 1-5. No particular representation for values is

(33)

CORBA V2.0 Object Semantics July 1995 1-5

1

FIG. 1 Legal Values

1.2.5 Interfaces

An interface is a description of a set of possible operations that a client may request of an object. An object satisfies an interface if it can be specified as the target object in each potential request described by the interface.

An interface type is a type that is satisfied by any object (literally, any value that identifies an object) that satisfies a particular interface.

Interfaces are specified in OMG IDL. Interface inheritance provides the composition mechanism for permitting an object to support multiple interfaces. The principal interface is simply the most-specific interface that the object supports, and consists of all operations in the transitive closure of the interface inheritance graph.

1.2.6 Operations

An operation is an identifiable entity that denotes a service that can be requested.

An operation is identified by an operation identifier. An operation is not a value.

An operation has a signature that describes the legitimate values of request parameters and returned results. In particular, a signature consists of:

• A specification of the parameters required in requests for that operation

• A specification of the result of the operation

• A specification of the exceptions that may be raised by a request for the operation and the types of the parameters accompanying them

• A specification of additional contextual information that may affect the request

• An indication of the execution semantics the client should expect from a request for the operation

Value

Object Reference Constructed Value

Basic Value Struct Sequence Union Array

Short Long UShort ULong Float Double Char String Boolean Octet Enum Any

(34)

Operations are (potentially) generic, meaning that a single operation can be uniformly requested on objects with different implementations, possibly resulting in observably different behavior. Genericity is achieved in this model via interface inheritance in IDL and the total decoupling of implementation from interface specification.

The general form for an operation signature is:

[oneway] <op_type_spec> <identifier> (param1, ..., paramL) [raises(except1,...,exceptN)] [context(name1, ..., nameM)]

where

:

• The optionaloneway keyword indicates that best-effort semantics are expected of requests for this operation; the default semantics are exactly-once if the operation successfully returns results or at-most-once if an exception is returned

• The<op_type_spec> is the type of the return result

• The<identifier> provides a name for the operation in the interface.

• The operation parameters needed for the operation; they are flagged with the modifiersin, out, orinout to indicate the direction in which the information flows (with respect to the object performing the request)

• The optionalraises expression indicates which user-defined exceptions can be signalled to terminate a request for this operation; if such an expression is not provided, no user-defined exceptions will be signalled

• The optionalcontext expression indicates which request context information will be available to the object implementation; no other contextual information is required to be transported with the request

Parameters

A parameter is characterized by its mode and its type. The mode indicates whether the value should be passed from client to server (in), from server to client (out), or both (inout). The parameter’s type constrains the possible value which may be passed in the directions dictated by the mode.

Return Result

The return result is a distinguishedout parameter.

Exceptions

An exception is an indication that an operation request was not performed successfully.

(35)

CORBA V2.0 Object Implementation July 1995 1-7

1 Contexts

A request context provides additional, operation-specific information that may affect the performance of a request.

Execution Semantics

Two styles of execution semantics are defined by the object model:

• At-most-once: if an operation request returns successfully, it was performed exactly once; if it returns an exception indication, it was performed at-most-once;

• Best-effort: a best-effort operation is a request-only operation, i.e. it cannot return any results and the requester never synchronizes with the completion, if any, of the request.

The execution semantics to be expected is associated with an operation. This prevents a client and object implementation from assuming different execution semantics.

Note that a client is able to invoke an at-most-once operation in a synchronous or deferred-synchronous manner.

1.2.7 Attributes

An interface may have attributes. An attribute is logically equivalent to declaring a pair of accessor functions: one to retrieve the value of the attribute and one to set the value of the attribute.

An attribute may be read-only, in which case only the retrieval accessor function is defined.

1.3 Object Implementation

This section defines the concepts associated with object implementation, i.e. the concepts relevant to realizing the behavior of objects in a computational system.

The implementation of an object system carries out the computational activities needed to effect the behavior of requested services. These activities may include computing the result of the request and updating the system state. In the process, additional requests may be issued.

The implementation model consists of two parts: the execution model and the construction model. The execution model describes how services are performed. The construction model describes how services are defined.

1.3.1 The Execution Model: Performing Services

A requested service is performed in a computational system by executing code that operates upon some data. The data represents a component of the state of the

computational system. The code performs the requested service, which may change the state of the system.

(36)

Code that is executed to perform a service is called a method. A method is an immutable description of a computation that can be interpreted by an execution engine.

A method has an immutable attribute called a method format that defines the set of execution engines that can interpret the method. An execution engine is an abstract machine (not a program) that can interpret methods of certain formats, causing the described computations to be performed. An execution engine defines a dynamic context for the execution of a method. The execution of a method is called a method activation.

When a client issues a request, a method of the target object is called. The input parameters passed by the requestor are passed to the method and the output parameters and return value (or exception and its parameters) are passed back to the requestor.

Performing a requested service causes a method to execute that may operate upon an object’s persistent state. If the persistent form of the method or state is not accessible to the execution engine, it may be necessary to first copy the method or state into an execution context. This process is called activation; the reverse process is called deactivation.

1.3.2 The Construction Model

A computational object system must provide mechanisms for realizing behavior of requests. These mechanisms include definitions of object state, definitions of methods, and definitions of how the object infrastructure is to select the methods to execute and to select the relevant portions of object state to be made accessible to the methods.

Mechanisms must also be provided to describe the concrete actions associated with object creation, such as association of the new object with appropriate methods.

An object implementation—or implementation, for short—is a definition that provides the information needed to create an object and to allow the object to participate in providing an appropriate set of services. An implementation typically includes, among other things, definitions of the methods that operate upon the state of an object. It also typically includes information about the intended type of the object.

(37)

CORBA V2.0 July 1995 2-1

CORBA Overview 2

The Common Object Request Broker Architecture (CORBA) is structured to allow integration of a wide variety of object systems. The motivation for some of the features may not be apparent at first, but as we discuss the range of implementations, policies, optimiza- tions, and usages we expect to encompass, the value of the flexibility becomes more clear.

FIG. 2 A Request Being Sent Through the Object Request Broker

2.1 Structure of an Object Request Broker

FIG. 2 on page 2-1 shows a request being sent by a client to an object implementation.The Client is the entity that wishes to perform an operation on the object and the Object Imple-

Client Object Implementation

ORB

Request

(38)

mentation is the code and data that actually implements the object. The ORB is responsi- ble for all of the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the ‘request. The interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect which is not reflected in the object’s interface.

FIG. 3 The Structure of Object Request Broker Interfaces

FIG. 3 on page 2-2 shows the structure of an individual Object Request Broker (ORB).

The interfaces to the ORB are shown by striped boxes, and the arrows indicate whether the ORB is called or performs an up-call across the interface.

Client Object Implementation

Dynamic Invocation

IDL Stubs

ORB Interface

Dynamic Skeleton

Object Adapter

ORB Core

Interface identical for all ORB implementations There may be multiple object adapters

There are stubs and a skeleton for each object type ORB-dependent interface

Up-call interface

Normal call interface Static IDL

Skeleton

(39)

CORBA V2.0 Structure of an Object Request Broker July 1995 2-3

2

Definitions of the interfaces to objects can be defined in two ways. Interfaces can be defined statically in an interface definition language, called the OMG Interface Definition Language (OMG IDL). This language defines the types of objects according to the operations that may be performed on them and the parameters to those operations. Alternatively, or in addition, interfaces can be added to an Interface Repository service; this service represents the components of an interface as objects, permitting runtime access to these components. In any ORB implementation, the Interface Definition Language (which may be extended beyond its definition in this document) and the Interface Repository have equivalent expressive power.

FIG. 4 A Client using the Stub or Dynamic Invocation Interface

The client performs a request by having access to an Object Reference for an object and knowing the type of the object and the desired operation to be performed. The client ini- tiates the request by calling stub routines that are specific to the object or by constructing the request dynamically (see FIG. 4 on page 2-3).

The dynamic and stub interface for invoking a request satisfy the same request semantics, and the receiver of the message cannot tell how the request was invoked.

Client

Dynamic Invocation

IDL Stubs

ORB Core

Interface identical for all ORB implementations

Request Request

(40)

FIG. 5 An Object Implementation Receiving a Request

The ORB locates the appropriate implementation code, transmits parameters and transfers control to the Object Implementation through an IDL skeleton or a dynamic skeleton (see FIG. 5 on page 2-4). Skeletons are specific to the interface and the object adapter. In performing the request, the object implementation may obtain some services from the ORB through the Object Adapter. When the request is complete, control and output values are returned to the client.

The Object Implementation may choose which Object Adapter to use. This decision is based on what kind of services the Object Implementation requires.

Object Implementation

Interface identical for all ORB implementations There may be multiple object adapters

Up-call interface

Normal call interface ORB

Interface

Dynamic Skeleton

Object Adapter

ORB Core

Static IDL Skeleton

(41)

2

FIG. 6 Interface and Implementation Repositories

FIG. 6 on page 2-5 shows how interface and implementation information is made available to clients and object implementations. The interface is defined in OMG IDL and/or in the Interface Repository; the definition is used to generate the client Stubs and the object implementation Skeletons.

The object implementation information is provided at installation time and is stored in the Implementation Repository for use during request delivery.

2.1.1 Object Request Broker

In the architecture, the ORB is not required to be implemented as a single component, but rather it is defined by its interfaces. Any ORB implementation that provides the appropriate interface is acceptable. The interface is organized into three categories:

1. Operations that are the same for all ORB implementations 2. Operations that are specific to particular types of objects

3. Operations that are specific to particular styles of object implementations Different ORBs may make quite different implementation choices, and, together with the IDL compilers, repositories, and various Object Adapters, provide a set of services to clients and implementations of objects that have different properties and qualities.

Client Object Implementation

IDL Definitions

Interface Repository

Stubs _Skeletons

Implementation Installation

Implementation

Repository

(42)

There may be multiple ORB implementations (also described as multiple ORBs) which have different representations for object references and different means of performing invocations. It may be possible for a client to simultaneously have access to two object references managed by different ORB implementations. When two ORBs are intended to work together, those ORBs must be able to distinguish their object references. It is not the responsibility of the client to do so.

The ORB Core is that part of the ORB that provides the basic representation of objects and communication of requests. CORBA is designed to support different object mechanisms, and it does so by structuring the ORB with components above the ORB Core, which provide interfaces that can mask the differences between ORB Cores.

2.1.2 Clients

A client of an object has access to an object reference for the object, and invokes operations on the object. A client knows only the logical structure of the object according to its interface and experiences the behavior of the object through invocations. Although we will generally consider a client to be a program or process initiating requests on an object, it is important to recognize that something is a client relative to a particular object. For example, the implementation of one object may be a client of other objects.

Clients generally see objects and ORB interfaces through the perspective of a language mapping, bringing the ORB right up to the programmer’s level. Clients are maximally por- table and should be able to work without source changes on any ORB that supports the desired language mapping with any object instance that implements the desired interface.

Clients have no knowledge of the implementation of the object, which object adapter is used by the implementation, or which ORB is used to access it.

2.1.3 Object Implementations

An object implementation provides the semantics of the object, usually by defining data for the object instance and code for the object’s methods. Often the implementation will use other objects or additional software to implement the behavior of the object. In some cases, the primary function of the object is to have side-effects on other things that are not objects.

A variety of object implementations can be supported, including separate servers, librar- ies, a program per method, an encapsulated application, an object-oriented database, etc.

Through the use of additional object adapters, it is possible to support virtually any style of object implementation.

Generally, object implementations do not depend on the ORB or how the client invokes

(43)

2

to the language mapping, and thus are insulated from the actual representation of them.

Two ORB implementations may differ in their choice of Object Reference representations.

The representation of an object reference handed to a client is only valid for the lifetime of that client.

All ORBs must provide the same language mapping to an object reference (usually referred to as an Object) for a particular programming language. This permits a program written in a particular language to access object references independent of the particular ORB. The language mapping may also provide additional ways to access object references in a typed way for the convenience of the programmer.

There is a distinguished object reference, guaranteed to be different from all object references, that denotes no object.

2.1.5 OMG Interface Definition Language

The OMG Interface Definition Language (OMG IDL) defines the types of objects by spec- ifying their interfaces. An interface consists of a set of named operations and the parameters to those operations. Note that although IDL provides the conceptual framework for describing the objects manipulated by the ORB, it is not necessary for there to be IDL source code available for the ORB to work. As long as the equivalent information is available in the form of stub routines or a runtime interface repository, a particular ORB may be able to function correctly.

IDL is the means by which a particular object implementation tells its potential clients what operations are available and how they should be invoked. From the IDL definitions, it is possible to map CORBA objects into particular programming languages or object systems.

2.1.6 Mapping of OMG IDL to Programming Languages

Different object-oriented or non-object-oriented programming languages may prefer to access CORBA objects in different ways. For object-oriented languages, it may be desir- able to see CORBA objects as programming language objects. Even for non-object-oriented languages, it is a good idea to hide the exact ORB representation of the object reference, method names, etc. A particular mapping of OMG IDL to a programming language should be the same for all ORB implementations. Language mapping includes definition of the language-specific data types and procedure interfaces to access objects through the ORB. It includes the structure of the client stub interface (not required for object-oriented languages), the dynamic invocation interface, the implementation skeleton, the object adapters, and the direct ORB interface.

A language mapping also defines the interaction between object invocations and the threads of control in the client or implementation. The most common mappings provide synchronous calls, in that the routine returns when the object operation completes. Addi- tional mappings may be provided to allow a call to be initiated and control returned to the program. In such cases, additional language-specific routines must be provided to syn- chronize the program’s threads of control with the object invocation.

(44)

2.1.7 Client Stubs

For the mapping of a non–object–oriented language, there will be a programming interface to the stubs for each interface type. Generally, the stubs will present access to the OMG IDL-defined operations on an object in a way that is easy for programmers to pre- dict once they are familiar with OMG IDL and the language mapping for the particular programming language. The stubs make calls on the rest of the ORB using interfaces that are private to, and presumably optimized for, the particular ORB Core. If more than one ORB is available, there may be different stubs corresponding to the different ORBs. In this case, it is necessary for the ORB and language mapping to cooperate to associate the cor- rect stubs with the particular object reference.

Object-oriented programming languages, such as C++ and Smalltalk, do not require stub interfaces.

2.1.8 Dynamic Invocation Interface

An interface is also available that allows the dynamic construction of object invocations, that is, rather than calling a stub routine that is specific to a particular operation on a particular object, a client may specify the object to be invoked, the operation to be performed, and the set of parameters for the operation through a call or sequence of calls. The client code must supply information about the operation to be performed and the types of the parameters being passed (perhaps obtaining it from an Interface Repository or other runtime source). The nature of the dynamic invocation interface may vary substantially from one programming language mapping to another.

2.1.9 Implementation Skeleton

For a particular language mapping, and possibly depending on the object adapter, there will be an interface to the methods that implement each type of object. The interface will generally be an up-call interface, in that the object implementation writes routines that conform to the interface and the ORB calls them through the skeleton.

The existence of a skeleton does not imply the existence of a corresponding client stub (clients can also make requests via the dynamic invocation interface).

It is possible to write an object adapter that does not use skeletons to invoke implementation methods. For example, it may be possible to create implementations dynamically for languages such as Smalltalk.

The Common Object Request Broker: Architecture and Specification