当前位置:首页 >> >> MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The Object Management Group, Inc.,

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The Object Management Group, Inc.,


The Common Object Request Broker: Architecture and Speci?cation

Revision 2.0 July 1995

Copyright 1995 BNR Europe Ltd Copyright 1991, 1992, 1995 by Digital Equipment Corporation Copyright 1995 Expersoft Corporation Copyright 1989, 1990, 1991, 1992, 1995 by Hewlett-Packard Company Copyright 1991, 1992, 1995 by HyperDesk Corporation Copyright 1995 IBM Corporation Copyright 1995 ICL, plc Copyright 1995 IONA Technologies Ltd Copyright 1991, 1992, 1995 by NCR Corporation Copyright 1995 Novell USG Copyright 1991,1992, 1995 by Object Design, Inc. Copyright 1991, 1992, 1995 Object Management Group, Inc. Copyright 1991, 1992, 1995 by Sun Microsystems, Inc. Copyright 1995 SunSoft, Inc BNR Europe Ltd, Expersoft Corporation, IBM Corporation, ICL plc, IONA Technologies Ltd, Digital Equipment 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 modi?ed 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 speci?cation set forth herein or having conformed any computer software to the speci?cation. NOTICE The information contained in this document is subject to change without notice. The material in this document details an Object Management Group speci?cation 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 speci?cation 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 incidental 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 designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certi?cation marks, trademarks or other special designations to indicate compliance with these materials. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright hereon may be reproduced or used in any form or by any means--graphic, electronic or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

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.

Table of Contents
0.1 About This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.1.1 Object Management Group. . . . . . . . . . . . . . . . 0.1.2 X/Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Context of CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Associated Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of this Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . De?nition of CORBA Compliance. . . . . . . . . . . . . . . . . . . . Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Object Creation and Destruction. . . . . . . . . . . . 1.2.4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.6 Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 The Execution Model: Performing Services . . . 1.3.2 The Construction Model . . . . . . . . . . . . . . . . . . iii iii iv iv iv v vi vii viii viii

0.2 0.3 0.4 0.5 0.6 0.7 0.8 1.1 1.2

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

1-1
1-1 1-2 1-2 1-2 1-3 1-4 1-5 1-5 1-7 1-7 1-7 1-8

1.3

CORBA V2.0

July 1995

iii

2. CORBA Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1

2-1

Structure of an Object Request Broker . . . . . . . . . . . . . . . . 2-1 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 De?nition 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 Example ORBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Client- and Implementation-resident ORB . . . . 2.2.2 Server-based ORB . . . . . . . . . . . . . . . . . . . . . . 2.2.3 System-based ORB . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Library-based ORB. . . . . . . . . . . . . . . . . . . . . . 2-10 2-10 2-10 2-10 2-10

2.2

2.3 2.4 2.5 2.6

Structure of a Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 Structure of an Object Implementation . . . . . . . . . . . . . . . . 2-12 Structure of an Object Adapter. . . . . . . . . . . . . . . . . . . . . . . 2-14 Example Object Adapters. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Basic Object Adapter . . . . . . . . . . . . . . . . . . . . 2.6.2 Library Object Adapter. . . . . . . . . . . . . . . . . . . 2.6.3 Object-Oriented Database Adapter . . . . . . . . . . 2-16 2-16 2-16 2-16

2.7 3.1 3.2

The Integration of Foreign Object Systems . . . . . . . . . . . . . 2-16

3. OMG IDL Syntax and Semantics. . . . . . . . . . . . . . . . . . . . .
About This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lexical Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Comments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Identi?ers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1
3-1 3-2 3-5 3-5 3-5 3-6 3-6 3-8

3.3

iv

CORBA V2.0

July 1995

3.4 3.5

OMG IDL Grammar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-9

OMG IDL Speci?cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.5.1 Module Declaration . . . . . . . . . . . . . . . . . . . . . 3-13 3.5.2 Interface Declaration . . . . . . . . . . . . . . . . . . . . 3-13 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 Constant Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 3.7.1 Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 3.7.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 Type Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 Basic Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.2 Constructed Types . . . . . . . . . . . . . . . . . . . . . . 3.8.3 Template Types. . . . . . . . . . . . . . . . . . . . . . . . . 3.8.4 Complex Declarator . . . . . . . . . . . . . . . . . . . . . 3-19 3-20 3-22 3-25 3-26 3-27 3-28 3-28 3-29 3-29

3.6 3.7

3.8

3.9

Exception Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26

3.10 Operation Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.1 Operation Attribute. . . . . . . . . . . . . . . . . . . . . . 3.10.2 Parameter Declarations. . . . . . . . . . . . . . . . . . . 3.10.3 Raises Expressions . . . . . . . . . . . . . . . . . . . . . . 3.10.4 Context Expressions . . . . . . . . . . . . . . . . . . . . .

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 De?nitions . . . . . . . . . . . 3-34 3.15.2 Object Non-Existence . . . . . . . . . . . . . . . . . . . . 3-35

4. Dynamic Invocation Interface . . . . . . . . . . . . . . . . . . . . . . .
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Common Data Structures . . . . . . . . . . . . . . . . . 4.1.2 Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Return Status and Exceptions . . . . . . . . . . . . . . Request Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 create_request . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 add_arg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deferred Synchronous Operations . . . . . . . . . . . . . . . . . . . . 4.3.1 send. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1
4-1 4-1 4-3 4-3 4-4 4-4 4-6 4-7 4-7 4-7 4-7

4.2

4.3

CORBA V2.0

July 1995

v

4.3.2 4.3.3 4.3.4 4.4

send_multiple_requests. . . . . . . . . . . . . . . . . . . get_response . . . . . . . . . . . . . . . . . . . . . . . . . . . get_next_response . . . . . . . . . . . . . . . . . . . . . .

4-8 4-9 4-9 4-10 4-10 4-11 4-11 4-11 4-12 4-12 4-13 4-14 4-15 4-15 4-15 4-16 4-16 4-16

List Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 create_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 add_item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 free_memory. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 get_count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.6 create_operation_list. . . . . . . . . . . . . . . . . . . . . Context Object Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 get_default_context . . . . . . . . . . . . . . . . . . . . . 4.6.2 set_one_value . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 set_values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 get_values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5 delete_values . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.6 create_child . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.7 delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5 4.6

Context Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

4.7 5.1 5.2 5.3

Native Data Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

5. Dynamic Skeleton Interface . . . . . . . . . . . . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explicit Request State: ServerRequest Pseudo Object . . . . .

5-1
5-2 5-2

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.2 6.3 6.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scope of an Interface Repository . . . . . . . . . . . . . . . . . . . . . Implementation Dependencies . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Managing Interface Repositories . . . . . . . . . . . Basics of the Interface Repository Interface. . . . . . . . . . . . . 6.4.1 Names and Identi?ers . . . . . . . . . . . . . . . . . . . . 6.4.2 Types and TypeCodes . . . . . . . . . . . . . . . . . . . . 6.4.3 Interface Objects. . . . . . . . . . . . . . . . . . . . . . . . 6.4.4 Structure and Navigation of Interface Objects . Interface Repository Interfaces . . . . . . . . . . . . . . . . . . . . . .

6-1
6-1 6-2 6-3 6-4 6-5 6-5 6-5 6-5 6-6 6-7

6.5

vi

CORBA V2.0

July 1995

6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.5.6 6.5.7 6.5.8 6.5.9 6.5.10 6.5.11 6.5.12 6.5.13 6.5.14 6.5.15 6.5.16 6.5.17 6.5.18 6.5.19 6.5.20 6.5.21 6.5.22 6.6

Supporting Type De?nitions . . . . . . . . . . . . . . . IRObject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IDLType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . ModuleDef . . . . . . . . . . . . . . . . . . . . . . . . . . . . ConstantDef Interface. . . . . . . . . . . . . . . . . . . . TypedefDef Interface . . . . . . . . . . . . . . . . . . . . StructDef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UnionDef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EnumDef. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AliasDef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Read Interface. . . . . . . . . . . . . . . . . . . . . . . . . . PrimitiveDef . . . . . . . . . . . . . . . . . . . . . . . . . . . StringDef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SequenceDef. . . . . . . . . . . . . . . . . . . . . . . . . . . ArrayDef. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ExceptionDef . . . . . . . . . . . . . . . . . . . . . . . . . . AttributeDef . . . . . . . . . . . . . . . . . . . . . . . . . . . OperationDef . . . . . . . . . . . . . . . . . . . . . . . . . . InterfaceDef . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-8 6-9 6-9 6-11 6-15 6-16 6-17 6-17 6-18 6-19 6-19 6-20 6-21 6-21 6-21 6-22 6-22 6-23 6-23 6-24 6-25 6-27 6-30 6-30 6-30 6-30 6-31 6-33 6-34 6-38 6-39

RepositoryIds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1 OMG IDL Format. . . . . . . . . . . . . . . . . . . . . . . 6.6.2 DCE UUID Format. . . . . . . . . . . . . . . . . . . . . . 6.6.3 LOCAL Format . . . . . . . . . . . . . . . . . . . . . . . . 6.6.4 Pragma Directives for RepositoryId . . . . . . . . . TypeCodes 6.7.1 6.7.2 6.7.3 ...................................... The TypeCode Interface . . . . . . . . . . . . . . . . . . TypeCode Constants . . . . . . . . . . . . . . . . . . . . . Creating TypeCodes . . . . . . . . . . . . . . . . . . . . .

6.7

6.8 7.1 7.2

OMG IDL for Interface Repository . . . . . . . . . . . . . . . . . . . 6-41

7. ORB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Converting Object References to Strings . . . . . . . . . . . . . . . Object Reference Operations . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Determining the Object Implementation and Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Duplicating and Releasing Copies of Object References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Nil Object References. . . . . . . . . . . . . . . . . . . .

7-1
7-1 7-2 7-3 7-3 7-4

CORBA V2.0

July 1995

vii

7.2.4 7.2.5 7.2.6 7.3 7.4 7.5 7.6 8.1 8.2

Equivalence Checking Operation . . . . . . . . . . . Probing for Object Non-Existence . . . . . . . . . . Object Reference Identity . . . . . . . . . . . . . . . . .

7-4 7-4 7-5 7-6 7-8

Overview: ORB and OA Initialization and Initial References 7-6 ORB Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OA and BOA Initialization. . . . . . . . . . . . . . . . . . . . . . . . . .

Obtaining Initial Object References . . . . . . . . . . . . . . . . . . . 7-10

8. The Basic Object Adapter. . . . . . . . . . . . . . . . . . . . . . . . . . .
Role of the Basic Object Adapter. . . . . . . . . . . . . . . . . . . . .

8-1
8-1

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 Standard OMG IDL Types . . . . . . . . . . . . . . . . . . A-1

Appendix A

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-Speci?c Inter-ORB Protocols (ESIOPs) 9-4 Relationship to Previous Versions of CORBA . . . . . . . . . . . Examples of Interoperability Solutions . . . . . . . . . . . . . . . . 9.3.1 Example 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.2 Example 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.3 Example 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.4 Interoperability Compliance . . . . . . . . . . . . . . . Motivating Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.1 ORB Implementation Diversity . . . . . . . . . . . . 9.4.2 ORB Boundaries. . . . . . . . . . . . . . . . . . . . . . . . 9.4.3 ORBs Vary in Scope, Distance, and Lifetime . . 9-4 9-4 9-5 9-5 9-5 9-5 9-8 9-8 9-8 9-9

9.2 9.3

9.4

9.5

Interoperability Design Goals . . . . . . . . . . . . . . . . . . . . . . . 9-9 9.5.1 Non-Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

viii

CORBA V2.0

July 1995

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.1 The Nature of ORB Services . . . . . . . . . . . . . . 10.2.2 ORB Services and Object Requests . . . . . . . . . 10.2.3 Selection of ORB Services . . . . . . . . . . . . . . . . 10-2 10-3 10-3 10-4

10.3 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4 10.3.1 De?nition 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 Con?gurations 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 Pro?le and Component Composition in IORs. . 10-16 10.6.4 IOR Creation and Scope . . . . . . . . . . . . . . . . . . 10-17 10.6.5 Stringi?ed 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.1 In-line Bridging . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Request-level bridging . . . . . . . . . . . . . . . . . . . 11.1.3 Collocated ORBs . . . . . . . . . . . . . . . . . . . . . . . 11-1 11-2 11-3 11-4

11.2 Proxy Creation and Management . . . . . . . . . . . . . . . . . . . . . 11-4 11.3 Interface-speci?c 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

CORBA V2.0

July 1995

ix

12. General Inter-ORB Protocol. . . . . . . . . . . . . . . . . . . . . . . . . 12-1
12.1 Goals of the General Inter-ORB Protocol . . . . . . . . . . . . . . 12-1 12.2 General Inter-ORB Protocol Overview . . . . . . . . . . . . . . . . 12.2.1 Common Data Representation (CDR) . . . . . . . 12.2.2 GIOP Message Overview . . . . . . . . . . . . . . . . . 12.2.3 GIOP Message Transfer . . . . . . . . . . . . . . . . . . 12-2 12-2 12-3 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 Pro?les . . . . . . . . . . . . . . . . . . . . . . . 12-27 12.8 OMG IDL for the GIOP and IIOP Speci?cations. . . . . . . . . 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.2 DCE Common Inter-ORB Protocol Overview . . . . . . . . . . . 13.2.1 DCE-CIOP RPC . . . . . . . . . . . . . . . . . . . . . . . . 13.2.2 DCE-CIOP Data Representation. . . . . . . . . . . . 13.2.3 DCE-CIOP Messages . . . . . . . . . . . . . . . . . . . . 13.2.4 Interoperable Object Reference (IOR) . . . . . . . 13-1 13-2 13-3 13-4 13-4

13.3 DCE-CIOP Message Transport . . . . . . . . . . . . . . . . . . . . . . 13-5 13.3.1 Pipe-based Interface . . . . . . . . . . . . . . . . . . . . . 13-5

x

CORBA V2.0

July 1995

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-1 14-2 14-2 14-2 14-2 14-2 14-3 14-3 14-4

14. C Language Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
14.1 Requirements for a Language Mapping . . . . . . . . . . . . . . . . 14.1.1 Basic Data Types . . . . . . . . . . . . . . . . . . . . . . . 14.1.2 Constructed Data Types . . . . . . . . . . . . . . . . . . 14.1.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.4 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.5 Invocation of Operations . . . . . . . . . . . . . . . . . 14.1.6 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.7 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.8 ORB Interfaces . . . . . . . . . . . . . . . . . . . . . . . . .

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

CORBA V2.0

July 1995

xi

14.8 Mapping Considerations for Constructed Types. . . . . . . . . . 14-9 14.9 Mapping for Structure Types . . . . . . . . . . . . . . . . . . . . . . . . 14-10 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-speci?c 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.1 Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.2 C++ Implementation Requirements . . . . . . . . . 15.1.3 C Data Layout Compatibility . . . . . . . . . . . . . . 15.1.4 No Implementation Descriptions . . . . . . . . . . . 15-1 15-1 15-2 15-2 15-2

15.2 Organization of the C++ Mapping . . . . . . . . . . . . . . . . . . . . 15-2

16. Mapping of OMG IDL to C++. . . . . . . . . . . . . . . . . . . . . . . 16-1
16.1 Preliminary Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1 16.1.1 Scoped Names . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

xii

CORBA V2.0

July 1995

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.1 Object Reference Types . . . . . . . . . . . . . . . . . . 16.3.2 Widening Object References . . . . . . . . . . . . . . 16.3.3 Object Reference Operations . . . . . . . . . . . . . . 16.3.4 Narrowing Object References. . . . . . . . . . . . . . 16.3.5 Nil Object Reference . . . . . . . . . . . . . . . . . . . . 16.3.6 Interface Mapping Example . . . . . . . . . . . . . . . 16-3 16-4 16-5 16-5 16-6 16-7 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

CORBA V2.0

July 1995

xiii

16.14.8 The Any Class . . . . . . . . . . . . . . . . . . . . . . . . . 16-40 16.14.9 The Any_var Class . . . . . . . . . . . . . . . . . . . . . . 16-40 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.4.1 Environment Interface . . . . . . . . . . . . . . . . . . . 17.4.2 Environment C++ Class . . . . . . . . . . . . . . . . . . 17.4.3 Differences from C-PIDL . . . . . . . . . . . . . . . . . 17.4.4 Memory Management. . . . . . . . . . . . . . . . . . . . 17.5 NamedValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.1 NamedValue Interface . . . . . . . . . . . . . . . . . . . 17.5.2 NamedValue C++ Class . . . . . . . . . . . . . . . . . . 17.5.3 Differences from C-PIDL . . . . . . . . . . . . . . . . . 17.5.4 Memory Management. . . . . . . . . . . . . . . . . . . . 17.6 NVList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6.1 NVList Interface . . . . . . . . . . . . . . . . . . . . . . . . 17.6.2 NVList C++ Class . . . . . . . . . . . . . . . . . . . . . . 17.6.3 Differences from C-PIDL . . . . . . . . . . . . . . . . . 17.6.4 Memory Management. . . . . . . . . . . . . . . . . . . . 17-3 17-4 17-4 17-4 17-4 17-5 17-5 17-5 17-5 17-5 17-6 17-6 17-6 17-7 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.8.2 Context C++ Class . . . . . . . . . . . . . . . . . . . . . . 17-13 17.8.3 Differences from C-PIDL . . . . . . . . . . . . . . . . . 17-13 17.8.4 Memory Management. . . . . . . . . . . . . . . . . . . . 17-14 17.9 Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14 17.9.1 Principal Interface . . . . . . . . . . . . . . . . . . . . . . 17-14 17.9.2 Principal C++ Class . . . . . . . . . . . . . . . . . . . . . 17-14

xiv

CORBA V2.0

July 1995

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.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping of ServerRequest to C++ . . . . . . . . . . 18.4.2 Handling Operation Parameters and Results. . . 18.4.3 Sample Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.4 Reporting Exceptions . . . . . . . . . . . . . . . . . . . . 18.4.5 Mapping of BOA’s Dynamic Implementation Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix C Appendix D Appendix E C++ De?nitions for CORBA . . . . . . . . . . . . . . . . Alternative Mappings For C++ Dialects. . . . . . . . C++ Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6 18-6 18-6 18-7 18-7 18-8 C-1 D-1 E-1

CORBA V2.0

July 1995

xv

19. Smalltalk Mapping Overview . . . . . . . . . . . . . . . . . . . . . . . . 19-1
19.1 Key Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1 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 Identi?ers . . . . . . . . . . . 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 20.18 Implicit Arguments to Operations . . . . . . . . . . . . . . . . . . . . 20-11 20.19 Argument Passing Considerations . . . . . . . . . . . . . . . . . . . . 20-11 20.20 Handling Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11 20.20.1 Exception Values . . . . . . . . . . . . . . . . . . . . . . . 20-12 20.20.2 The CORBAExceptionValue protocol . . . . . . . 20-13

xvi

CORBA V2.0

July 1995

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

CORBA V2.0

July 1995

xvii

xviii

CORBA V2.0

July 1995

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 Speci?cation and later as a full CAE Speci?cation. The collaboration between OMG and X/Open Co Ltd ensures joint review and cohesive support for emerging object-based speci?cations. X/Open Preliminary Speci?cations undergo close scrutiny through a review process at X/Open before publication and are inherently stable speci?cations. Upgrade to full CAE Speci?cation, 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 speci?cations 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 speci?cations 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 in?uence its direction by establishing the Object Management Architecture (OMA). The OMA provides the conceptual infrastructure upon which all OMG speci?cations are based.

CORBA V2.0

July 1995

iii

0.1.2 X/Open
X/Open is an independent, worldwide, open systems organization supported by most of 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 de?ned in X/Open CAE speci?cations. These contain, among other things, an evolving portfolio of practical application programming interfaces (APIs), which signi?cantly enhance portability of application programs at the source code level. The APIs also enahance the interoperability of applications by providing de?nitions of, and references to, protocols and protocol pro?les. The X/Open speci?cations 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 speci?cations.

0.2 Intended Audience
The architecture and speci?cations 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 bene?t of compliance is, in general, to be able to produce interoperable applications that are based on distributed, interoperating objects. As de?ned 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 speci?cations of the Object Request Broker are described in this manual. ? Object Services, a collection of services (interfaces and objects) that support basic functions for using and implementing objects. Services are necessary to construct any distributed application and are always independent of application domains. For example, the Life Cycle Service de?nes conventions for creating, deleting, copying, and moving objects; it does not dictate how the objects are implemented in an application. Speci?cations for Object Services are contained in CORBAservices: Common Object Services Speci?cation.

iv

CORBA V2.0

July 1995

? 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 classi?ed 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 de?nes 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 Speci?cation contains the architecture and speci?cations for the Object Request Broker. ? CORBAservices: Common Object Services Speci?cation contains speci?cations for the object services. ? CORBAfacilities: Common Facilities will contain speci?cations 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. Speci?cations 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 pubs@omg.org http://www.omg.org/

CORBA V2.0

Associated Documents

July 1995

v

0.5 Structure of this Manual
This manual is divided into the categories of Core, Interoperability, and individual Language Mappings. These divisions re?ect the compliance points of CORBA, as explained in Section 0.6, “De?nition of CORBA Compliance,” on page vii. In addition to this preface, CORBA: Common Object Request Broker Architecture and Speci?cation 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 de?nition 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 Interface describes the DSI, the server’s-side interface that can deliver requests from an ORB to an object implementation that does not have compiletime 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 de?nitions. 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-speci?c, inter-ORB protocols (ESIOPs). Interoperability Architecture introduces the framework of ORB interoperability, including information about domains; approaches to inter-ORB bridges; what it means to be compliant with ORB interoperability; and ORB Services and Requests. Inter-ORB Bridges explains how to build bridges for an implementation of interoperating ORBs.

vi

CORBA V2.0

July 1995

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-Speci?c 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 pro?le.

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++ programming language. Mapping of Pseudo Objects to C++ maps OMG IDL pseudo objects to the C++ programming language. 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++ de?nitions 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 De?nition 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 speci?cations is divided into core and component-like speci?cations. (The structure of this manual re?ects that division.) The CORBA family of speci?cations are as follows:

CORBA V2.0

De?nition of CORBA Compliance

July 1995

vii

? ? ? ?

CORBA Core, as speci?ed in Chapters 1–8 CORBA Interoperability, as speci?ed in Chapters 9–13 Mapping of OMG IDL to C programming language, as speci?ed in Chapter 14 Mapping of OMG IDL to C++ programming language, as speci?ed in Chapters 15–18 ? Mapping of OMG IDL to Smalltalk programming language, as speci?ed 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 speci?cations listed here will be associated with a separate branding stamp. The minimum required for a CORBA-compliant system is adherence to the speci?cations 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 speci?cations to be called CORBA-compliant. For instance, if a vendor supports C++, their ORB must comply with the OMG IDL to C++ binding speci?ed 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 De?nition 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 identi?ed by a comment; unidenti?ed examples are written in OMG IDL.

0.8 Acknowledgements
The following companies submitted parts of the speci?cations that were approved by the Object Management Group to become CORBA: ? BNR Europe Ltd ? Expersoft Corporation ? IBM Corporation ? ICL plc

viii

CORBA V2.0

July 1995

? ? ? ? ? ? ? ? ?

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.

CORBA V2.0

Acknowledgements

July 1995

ix

x

CORBA V2.0

July 1995

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 de?ned 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 de?nes 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 speci?c, for example, by de?ning the form of request parameters or the language used to specify types ? It may populate the model by introducing speci?c instances of entities de?ned by the model, for example, speci?c objects, speci?c operations, or speci?c 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-de?ned encapsulating interface. In particular, clients are isolated from the implementations of services as data representations and executable code. The object model ?rst 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.

CORBA V2.0

July 1995

1-1

1
The object model is most speci?c and prescriptive in de?ning 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 speci?c 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 identi?es an object and zero or more actual parameters. As in most classical object models, a distinguished ?rst parameter is required, which identi?es the operation to be performed; the interpretation of the message by the object involves selecting a method based on the speci?ed 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 de?nes 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 identi?able, 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 context. A request form is a description or pattern that can be evaluated or performed multiple times to cause the issuing of requests. As described in the OMG IDL Syntax and Semantics chapter, request forms are de?ned by particular language bindings. An alternative request form consists of calls to the dynamic invocation interface to create

1-2

CORBA V2.0

July 1995

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 identi?es 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. Speci?cally, 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, de?ned 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 identi?ed 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 unde?ned 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.

CORBA V2.0

Object Semantics

July 1995

1-3

1
1.2.4 Types
A type is an identi?able entity with an associated predicate (a single-argument mathematical function with a boolean result) de?ned over values. A value satis?es a type if the predicate is true for that value. A value that satis?es 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 satis?ed 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 ?oating point numbers ? Characters, as de?ned 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 identi?ers ? 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 ?xed-length array of a single type ? An interface type, which speci?es 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 de?ned.

1-4

CORBA V2.0

July 1995

1
FIG. 1

Legal Values Value

Object Reference

Constructed Value

Basic Value

Struct

Sequence

Union

Array

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

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 satis?es an interface if it can be speci?ed as the target object in each potential request described by the interface. An interface type is a type that is satis?ed by any object (literally, any value that identi?es an object) that satis?es a particular interface. Interfaces are speci?ed in OMG IDL. Interface inheritance provides the composition mechanism for permitting an object to support multiple interfaces. The principal interface is simply the most-speci?c 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 identi?able entity that denotes a service that can be requested. An operation is identi?ed by an operation identi?er. 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 speci?cation of the parameters required in requests for that operation ? A speci?cation of the result of the operation ? A speci?cation of the exceptions that may be raised by a request for the operation and the types of the parameters accompanying them ? A speci?cation 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

CORBA V2.0

Object Semantics

July 1995

1-5

1
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 speci?cation. The general form for an operation signature is: [oneway] <op_type_spec> <identi?er> (param1, ..., paramL) [raises(except1,...,exceptN)] [context(name1, ..., nameM)]

where:
? The optional oneway 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 <identi?er> provides a name for the operation in the interface. ? The operation parameters needed for the operation; they are ?agged with the modi?ers in, out, or inout to indicate the direction in which the information ?ows (with respect to the object performing the request) ? The optional raises expression indicates which user-de?ned exceptions can be signalled to terminate a request for this operation; if such an expression is not provided, no user-de?ned exceptions will be signalled ? The optional context 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 distinguished out parameter.

Exceptions
An exception is an indication that an operation request was not performed successfully. An exception may be accompanied by additional, exception-speci?c information. The additional, exception-speci?c information is a specialized form of record. As a record, it may consist of any of the types described in Section 1.2.4. All signatures implicitly include the standard exceptions described in Section 3.15, “Standard Exceptions,” on page 3-33.

1-6

CORBA V2.0

July 1995

1
Contexts
A request context provides additional, operation-speci?c information that may affect the performance of a request.

Execution Semantics
Two styles of execution semantics are de?ned 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 de?ned.

1.3 Object Implementation
This section de?nes 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 de?ned.

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.

CORBA V2.0

Object Implementation

July 1995

1-7

1
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 de?nes 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 de?nes 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 ?rst 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 de?nitions of object state, de?nitions of methods, and de?nitions 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 de?nition 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, de?nitions of the methods that operate upon the state of an object. It also typically includes information about the intended type of the object.

1-8

CORBA V2.0

July 1995

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 ?rst, but as we discuss the range of implementations, policies, optimizations, and usages we expect to encompass, the value of the ?exibility becomes more clear.
FIG. 2

A Request Being Sent Through the Object Request Broker

Client

Object Implementation

Request
ORB

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-

CORBA V2.0

July 1995

2-1

2
mentation is the code and data that actually implements the object. The ORB is responsible for all of the mechanisms required to ?nd 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 re?ected in the object’s interface.
FIG. 3

The Structure of Object Request Broker Interfaces

Client

Object Implementation

Dynamic Invocation

IDL Stubs

ORB Interface

Static IDL Skeleton

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
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. To make a request, the Client can use the Dynamic Invocation interface (the same interface independent of the target object’s interface) or an OMG IDL stub (the speci?c stub depending on the interface of the target object). The Client can also directly interact with the ORB for some functions. The Object Implementation receives a request as an up-call either through the OMG IDL generated skeleton or through a dynamic skeleton. The Object Implementation may call the Object Adapter and the ORB while processing a request or at other times.

Up-call interface Normal call interface

2-2

CORBA V2.0

July 1995

2
De?nitions of the interfaces to objects can be de?ned in two ways. Interfaces can be de?ned statically in an interface de?nition language, called the OMG Interface De?nition Language (OMG IDL). This language de?nes 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 De?nition Language (which may be extended beyond its de?nition in this document) and the Interface Repository have equivalent expressive power.
FIG. 4

A Client using the Stub or Dynamic Invocation Interface

Client
Request
Dynamic Invocation

IDL Stubs

Interface identical for all ORB implementations There are stubs and a skeleton for each object type ORB-dependent 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 initiates the request by calling stub routines that are speci?c 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.

Request

ORB Core

CORBA V2.0

Structure of an Object Request Broker

July 1995

2-3

2
FIG. 5

An Object Implementation Receiving a Request

Object Implementation

ORB Interface

Static IDL Skeleton

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
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 speci?c 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.

Up-call interface Normal call interface

2-4

CORBA V2.0

July 1995

2
FIG. 6

Interface and Implementation Repositories

IDL De?nitions

Implementation Installation

Interface Repository

Stubs

Implementation Repository Skeletons

Client

Object Implementation

FIG. 6 on page 2-5 shows how interface and implementation information is made available to clients and object implementations. The interface is de?ned in OMG IDL and/or in the Interface Repository; the de?nition 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 de?ned 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 speci?c to particular types of objects 3. Operations that are speci?c 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.

CORBA V2.0

Structure of an Object Request Broker

July 1995

2-5

2
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 portable 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 de?ning 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, libraries, 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 the object. Object implementations may select interfaces to ORB-dependent services by the choice of Object Adapter.

2.1.4 Object References
An Object Reference is the information needed to specify an object within an ORB. Both clients and object implementations have an opaque notion of object references according

2-6

CORBA V2.0

July 1995

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 De?nition Language
The OMG Interface De?nition Language (OMG IDL) de?nes the types of objects by specifying 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 de?nitions, 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 desirable 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-speci?c 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 de?nes 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. Additional mappings may be provided to allow a call to be initiated and control returned to the program. In such cases, additional language-speci?c routines must be provided to synchronize the program’s threads of control with the object invocation.

CORBA V2.0

Structure of an Object Request Broker

July 1995

2-7

2
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-de?ned operations on an object in a way that is easy for programmers to predict 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 correct 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 speci?c 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.

2.1.10 Dynamic Skeleton Interface
An interface is available which allows dynamic handling of object invocations. That is, rather than being accessed through a skeleton that is speci?c to a particular operation, an object’s implementation is reached through an interface that provides access to the operation name and parameters in a manner analagous to the client side’s Dynamic Invocation Interface. Purely static knowledge of those parameters may be used, or dynamic knowledge (perhaps determined through an Interface Repository) may be also used, to determine the parameters.

2-8

CORBA V2.0

July 1995

2
The implementation code must provide descriptions of all the operation parameters to the ORB, and the ORB provides the values of any input parameters for use in performing the operation. The implementation code provides the values of any output parameters, or an exception, to the ORB after performing the operation. The nature of the dynamic skeleton interface may vary substantially from one programming language mapping or object adapter to another, but will typically be an up-call interface. Dynamic skeletons may be invoked both through client stubs and through the dynamic invocation interface; either style of client request construction interface provides identical results.

2.1.11 Object Adapters
An object adapter is the primary way that an object implementation accesses services provided by the ORB. There are expected to be a few object adapters that will be widely available, with interfaces that are appropriate for speci?c kinds of objects. Services provided by the ORB through an Object Adapter often include: generation and interpretation of object references, method invocation, security of interactions, object and implementation activation and deactivation, mapping object references to implementations, and registration of implementations. The wide range of object granularities, lifetimes, policies, implementation styles, and other properties make it dif?cult for the ORB Core to provide a single interface that is convenient and ef?cient for all objects. Thus, through Object Adapters, it is possible for the ORB to target particular groups of object implementations that have similar requirements with interfaces tailored to them.

2.1.12 ORB Interface
The ORB Interface is the interface that goes directly to the ORB which is the same for all ORBs and does not depend on the object’s interface or object adapter. Because most of the functionality of the ORB is provided through the object adapter, stubs, skeleton, or dynamic invocation, there are only a few operations that are common across all objects. These operations are useful to both clients and implementations of objects.

2.1.13 Interface Repository
The Interface Repository is a service that provides persistent objects that represent the IDL information in a form available at runtime. The Interface Repository information may be used by the ORB to perform requests. Moreover, using the information in the Interface Repository, it is possible for a program to encounter an object whose interface was not known when the program was compiled, yet, be able to determine what operations are valid on the object and make an invocation on it. In addition to its role in the functioning of the ORB, the Interface Repository is a common place to store additional information associated with interfaces to ORB objects. For example, debugging information, libraries of stubs or skeletons, routines that can format or browse particular kinds of objects, etc., might be associated with the Interface Repository.

CORBA V2.0

Structure of an Object Request Broker

July 1995

2-9

2
2.1.14 Implementation Repository
The Implementation Repository contains information that allows the ORB to locate and activate implementations of objects. Although most of the information in the Implementation Repository is speci?c to an ORB or operating environment, the Implementation Repository is the conventional place for recording such information. Ordinarily, installation of implementations and control of policies related to the activation and execution of object implementations is done through operations on the Implementation Repository. In addition to its role in the functioning of the ORB, the Implementation Repository is a common place to store additional information associated with implementations of ORB objects. For example, debugging information, administrative control, resource allocation, security, etc., might be associated with the Implementation Repository.

2.2 Example ORBs
There are a wide variety of ORB implementations possible within the Common ORB Architecture. This section will illustrate some of the different options. Note that a particular ORB might support multiple options and protocols for communication.

2.2.1 Client- and Implementation-resident ORB
If there is a suitable communication mechanism present, an ORB can be implemented in routines resident in the clients and implementations. The stubs in the client either use a location-transparent IPC mechanism or directly access a location service to establish communication with the implementations. Code linked with the implementation is responsible for setting up appropriate databases for use by clients.

2.2.2 Server-based ORB
To centralize the management of the ORB, all clients and implementations can communicate with one or more servers whose job it is to route requests from clients to implementations. The ORB could be a normal program as far as the underlying operating system is concerned, and normal IPC could be used to communicate with the ORB.

2.2.3 System-based ORB
To enhance security, robustness, and performance, the ORB could be provided as a basic service of the underlying operating system. Object references could be made unforgeable, reducing the expense of authentication on each request. Because the operating system could know the location and structure of clients and implementations, it would be possible for a variety of optimizations to be implemented, for example, avoiding marshalling when both are on the same machine.

2.2.4 Library-based ORB
For objects that are light-weight and whose implementations can be shared, the implementation might actually be in a library. In this case, the stubs could be the actual methods.

2-10

CORBA V2.0

July 1995

2
This assumes that it is possible for a client program to get access to the data for the objects and that the implementation trusts the client not to damage the data.

2.3 Structure of a Client
A client of an object has an object reference that refers to that object. An object reference is a token that may be invoked or passed as a parameter to an invocation on a different object. Invocation of an object involves specifying the object to be invoked, the operation to be performed, and parameters to be given to the operation or returned from it. The ORB manages the control transfer and data transfer to the object implementation and back to the client. In the event that the ORB cannot complete the invocation, an exception response is provided. Ordinarily, a client calls a routine in its program that performs the invocation and returns when the operation is complete. Clients access object-type-speci?c stubs as library routines in their program (see FIG. 7 on page 2-12). The client program thus sees routines callable in the normal way in its programming language. All implementations will provide a language-speci?c data type to use to refer to objects, often an opaque pointer. The client then passes that object reference to the stub routines to initiate an invocation. The stubs have access to the object reference representation and interact with the ORB to perform the invocation. (See Chapter 14 for additional, general information on language mapping of object references.)

CORBA V2.0

Structure of a Client

July 1995

2-11

2
FIG. 7

The Structure of a Typical Client

Client Program
Language-dependent object references

ORB object references

Dynamic Invocation Interface

Stubs for Interface A

Stubs for Interface B

An alternative set of library code is available to perform invocations on objects, for example when the object was not de?ned at compile time. In that case, the client program provides additional information to name the type of the object and the method being invoked, and performs a sequence of calls to specify the parameters and initiate the invocation. Clients most commonly obtain object references by receiving them as output parameters from invocations on other objects for which they have references. When a client is also an implementation, it receives object references as input parameters on invocations to objects it implements. An object reference can also be converted to a string that can be stored in ?les or preserved or communicated by different means and subsequently turned back into an object reference by the ORB that produced the string.

2.4 Structure of an Object Implementation
An object implementation provides the actual state and behavior of an object. The object implementation can be structured in a variety of ways. Besides de?ning the methods for the operations themselves, an implementation will usually de?ne procedures for activating and deactivating objects and will use other objects or non-object facilities to make the object state persistent, to control access to the object, as well as to implement the methods.

2-12

CORBA V2.0

July 1995

2
The object implementation (see FIG. 8 on page 2-13) interacts with the ORB in a variety of ways to establish its identity, to create new objects, and to obtain ORB-dependent services. It primarily does this via access to an Object Adapter, which provides an interface to ORB services that is convenient for a particular style of object implementation.
FIG. 8

The Structure of a Typical Object Implementation

Object Implementation
Methods for Interface A
Object data

Up-call to

Met

hod

ORB object references Library br Routines

Skeleton for Interface A

Dynamic Skeleton

Object adapter routines

Because of the range of possible object implementations, it is dif?cult to be de?nitive about how in general an object implementation is structured. See the Basic Object Adapter chapter for the structure of object implementations that use the Basic Object Adapter. When an invocation occurs, the ORB Core, object adapter, and skeleton arrange that a call is made to the appropriate method of the implementation. A parameter to that method speci?es the object being invoked, which the method can use to locate the data for the object. Additional parameters are supplied according to the skeleton de?nition. When the method is complete, it returns, causing output parameters or exception results to be transmitted back to the client. When a new object is created, the ORB may be noti?ed so that the it knows where to ?nd the implementation for that object. Usually, the implementation also registers itself as

CORBA V2.0

Structure of an Object Implementation

July 1995

2-13

2
implementing objects of a particular interface, and speci?es how to start up the implementation if it is not already running. Most object implementations provide their behavior using facilities in addition to the ORB and object adapter. For example, although the Basic Object Adapter provides some persistent data associated with an object, that relatively small amount of data is typically used as an identi?er for the actual object data stored in a storage service of the object implementation’s choosing. With this structure, it is not only possible for different object implementations to use the same storage service, it is also possible for objects to choose the service that is most appropriate for them.

2.5 Structure of an Object Adapter
An object adapter (see FIG. 9 on page 2-15) is the primary means for an object implementation to access ORB services such as object reference generation. An object adapter exports a public interface to the object implementation, and a private interface to the skeleton. It is built on a private ORB-dependent interface. Object adapters are responsible for the following functions: ? ? ? ? ? ? Generation and interpretation of object references Method invocation Security of interactions Object and implementation activation and deactivation Mapping object references to the corresponding object implementations registration of implementations

These functions are performed using the ORB Core and any additional components necessary. Often, an object adapter will maintain its own state to accomplish its tasks. It may be possible for a particular object adapter to delegate one or more of its responsibilities to the Core upon which it is constructed. As shown in FIG. 9 on page 2-15, the Object Adapter is implicitly involved in invocation of the methods, although the direct interface is through the skeletons. For example, the Object Adapter may be involved in activating the implementation or authenticating the request.

2-14

CORBA V2.0

July 1995

2
FIG. 9

The Structure of a Typical Object Adapter

Object Implementation
Interface A Methods Interface B Methods

Dynamic Skeleton

Interface A Skeleton

Interface B Skeleton

Object Adapter Interface

ORB Core
The Object Adapter de?nes most of the services from the ORB that the Object Implementation can depend on. Different ORBs will provide different levels of service and different operating environments may provide some properties implicitly and require others to be added by the Object Adapter. For example, it is common for Object Implementations to want to store certain values in the object reference for easy identi?cation of the object on an invocation. If the Object Adapter allows the implementation to specify such values when a new object is created, it may be able to store them in the object reference for those ORBs that permit it. If the ORB Core does not provide this feature, the Object Adapter would record the value in its own storage and provide it to the implementation on an invocation. With Object Adapters, it is possible for an Object Implementation to have access to a service whether or not it is implemented in the ORB Core—if the ORB Core provides it, the adapter simply provides an interface to it; if not, the adapter must implement it on top of the ORB Core. Every instance of a particular adapter must provide the same interface and service for all the ORBs it is implemented on. It is also not necessary for all Object Adapters to provide the same interface or functionality. Some Object Implementations have special requirements, for example, an object-oriented database system may wish to implicitly register its many thousands of objects without doing individual calls to the Object Adapter. In such a case, it would be impractical and unnecessary for the object adapter to maintain any per-object state. By using an object adapter interface that is tuned towards such object implementations, it is possible to take advantage of particular ORB Core details to provide the most effective access to the ORB.

CORBA V2.0

Structure of an Object Adapter

July 1995

2-15

2
2.6 Example Object Adapters
There are a variety of possible object adapters. However, since the object adapter interface is something that object implementations depend on, it is desirable that there be as few as practical. Most object adapters are designed to cover a range of object implementations, so only when an implementation requires radically different services or interfaces should a new object adapter be considered. In this section, we describe three object adapters that might be useful.

2.6.1 Basic Object Adapter
This speci?cation de?nes an object adapter that can be used for most ORB objects with conventional implementations. (See the Basic Object Adapter chapter for more information.) For this object adapter, implementations are generally separate programs. It allows there to be a program started per method, a separate program for each object, or a shared program for all instances of the object type. It provides a small amount of persistent storage for each object, which can be used as a name or identi?er for other storage, for access control lists, or other object properties. If the implementation is not active when an invocation is performed, the BOA will start one.

2.6.2 Library Object Adapter
This object adapter is primarily used for objects that have library implementations. It accesses persistent storage in ?les, and does not support activation or authentication, since the objects are assumed to be in the clients program.

2.6.3 Object-Oriented Database Adapter
This adapter uses a connection to an object-oriented database to provide access to the objects stored in it. Since the OODB provides the methods and persistent storage, objects may be registered implicitly and no state is required in the object adapter.

2.7 The Integration of Foreign Object Systems
The Common ORB Architecture is designed to allow interoperation with a wide range of object systems (see FIG. 10 on page 2-17). Because there are many existing object systems, a common desire will be to allow the objects in those systems to be accessible via the ORB. For those object systems that are ORBs themselves, they may be connected to other ORBs through the mechanisms described in chapters 9, 10, 11, 12, and 13 in this manual.

2-16

CORBA V2.0

July 1995

2
FIG. 10

Different Ways to Integrate Foreign Object Systems

Object system as a BOA object implementation

Object system as an implementation with a special-purpose object adapter Special-purpose Adapter

Basic Object Adapter

ORB Core
Gateway

Object system as another ORB interoperating via a gateway

For object systems that simply want to map their objects into ORB objects and receive invocations through the ORB, one approach is to have those object systems appear to be implementations of the corresponding ORB objects. The object system would register its objects with the ORB and handle incoming requests, and could act like a client and perform outgoing requests. In some cases, it will be impractical for another object system to act like a BOA object implementation. An object adapter could be designed for objects that are created in conjunction with the ORB and that are primarily invoked through the ORB. Another object system may wish to create objects without consulting the ORB, and might expect most invocations to occur within itself rather than through the ORB. In such a case, a more appropriate object adapter might allow objects to be implicitly registered when they are passed through the ORB.

CORBA V2.0

The Integration of Foreign Object Systems

July 1995

2-17

2

2-18

CORBA V2.0

July 1995

OMG IDL Syntax and Semantics

3

The OMG Interface De?nition Language is the language used to describe the interfaces that client objects call and object implementations provide. An interface de?nition written in OMG IDL completely de?nes the interface and fully speci?es each operation’s parameters. An OMG IDL interface provides the information needed to develop clients that use the interface’s operations. Clients are not written in OMG IDL, which is purely a descriptive language, but in languages for which mappings from OMG IDL concepts have been de?ned. The mapping of an OMG IDL concept to a client language construct will depend on the facilities available in the client language. For example, an OMG IDL exception might be mapped to a structure in a language that has no notion of exception, or to an exception in a language that does. The binding of OMG IDL concepts to the C, C++, and Smalltalk languages are described in this manual. Bindings from OMG IDL to additional programming languages will be added to future versions of COBRA. OMG IDL obeys the same lexical rules as C++1, although new keywords are introduced to support distribution concepts. It also provides full support for standard C++ preprocessing features. The OMG IDL speci?cation is expected to track relevant changes to C++ introduced by the ANSI standardization effort.

3.1 About This Chapter
The description of OMG IDL’s lexical conventions is presented in “Lexical Conventions” on page 3-2. A description of OMG IDL preprocessing is presented in “Preprocessing” on page 3-8. The scope rules for identi?ers in an OMG IDL speci?cation are described in “CORBA Module” on page 3-31.
1.Ellis, Margaret A. and Bjarne Stroustrup, The Annotated C++ Reference Manual, AddisonWesley Publishing Company, Reading, Massachusetts, 1990, ISBN 0-201-51459-1

CORBA V2.0

July 1995

3-1

3
The OMG IDL grammar is a subset of the proposed ANSI C++ standard, with additional constructs to support the operation invocation mechanism. OMG IDL is a declarative language. It supports C++ syntax for constant, type, and operation declarations; it does not include any algorithmic structures or variables. The grammar is presented in “OMG IDL Grammar” on page 3-9. OMG IDL-speci?c pragmas (those not de?ned for C++) may appear anywhere in a speci?cation; the textual location of these pragmas may be semantically constrained by a particular implementation. A source ?le containing interface speci?cations written in OMG IDL must have an “.idl” extension. The ?le orb.idl, which contains OMG IDL type de?nitions and is available on every ORB implementation, is described in Appendix A. This chapter describes OMG IDL semantics and gives the syntax for OMG IDL grammatical constructs. The description of OMG IDL grammar uses a syntax notation that is similar to Extended Backus-Naur format (EBNF); Figure 1 on page 3-2 lists the symbols used in this format and their meaning.
TABLE 1. IDL

EBNF Format
Meaning Is de?ned to be Alternatively Non-terminal Literal The preceding syntactic unit can be repeated zero or more times The preceding syntactic unit can be repeated one or more times The enclosed syntactic units are grouped as a single syntactic unit The enclosed syntactic unit is optional—may occur zero or one time

Symbol ::= | <text> “text” * + {} []

3.2 Lexical Conventions
This section2 presents the lexical conventions of OMG IDL. It de?nes tokens in an OMG IDL speci?cation and describes comments, identi?ers, keywords, and literals—integer, character, and ?oating point constants and string literals. An OMG IDL speci?cation logically consists of one or more ?les. A ?le is conceptually translated in several phases. The ?rst phase is preprocessing, which performs ?le inclusion and macro substitution. Preprocessing is controlled by directives introduced by lines having # as the ?rst character other than white space. The result of preprocessing is a sequence of tokens. Such a sequence of tokens, that is, a ?le after preprocessing, is called a translation unit.

2.This section is an adaptation of The Annotated C++ Reference Manual, Chapter 2; it differs in the list of legal keywords and punctuation.

3-2

CORBA V2.0

July 1995

3
OMG IDL uses the ISO Latin-1 (8859.1) character set. This character set is divided into alphabetic characters (letters), digits, graphic characters, the space (blank) character and formatting characters. Figure 2 on page 3-3 shows the OMG IDL alphabetic characters; upper- and lower-case equivalencies are paired.
TABLE 2. The

114 Alphabetic Characters (Letters)
Description Upper/Lower-case A Upper/Lower-case B Upper/Lower-case C Upper/Lower-case D Upper/Lower-case E Upper/Lower-case F Upper/Lower-case G Upper/Lower-case H Upper/Lower-case I Upper/Lower-case J Upper/Lower-case K Upper/Lower-case L Upper/Lower-case M Upper/Lower-case N Upper/Lower-case O Upper/Lower-case P Upper/Lower-case Q Upper/Lower-case R Upper/Lower-case S Upper/Lower-case T Upper/Lower-case U Upper/Lower-case V Upper/Lower-case W Upper/Lower-case X Upper/Lower-case Y Upper/Lower-case Z ?? ?ò ?ó ?? ?? ?? ?? ?ù ?ú ?? ?ü Char. ?à ?á ?? ?? ?? ?? ?? ?? ?è ?é ?ê ?? ?ì ?í ?? ?? Description Upper/Lower-case A with grave accent Upper/Lower-case A with acute accent Upper/Lower-case A with circum?ex accent Upper/Lower-case A with tilde Upper/Lower-case A with diaeresis Upper/Lower-case A with ring above Upper/Lower-case dipthong A with E Upper/Lower-case C with cedilla Upper/Lower-case E with grave accent Upper/Lower-case E with acute accent Upper/Lower-case E with circum?ex accent Upper/Lower-case E with diaeresis Upper/Lower-case I with grave accent Upper/Lower-case I with acute accent Upper/Lower-case I with circum?ex accent Upper/Lower-case I with diaeresis Upper/Lower-case Icelandic eth Upper/Lower-case N with tilde Upper/Lower-case O with grave accent Upper/Lower-case O with acute accent Upper/Lower-case O with circum?ex accent Upper/Lower-case O with tilde Upper/Lower-case O with diaeresis Upper/Lower-case O with oblique stroke Upper/Lower-case U with grave accent Upper/Lower-case U with acute accent Upper/Lower-case U with circum?ex accent Upper/Lower-case U with diaeresis Upper/Lower-case Y with acute accent Upper/Lower-case Icelandic thorn ? ? Lower-case German sharp S Lower-case Y with diaeresis

Char. Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt Uu Vv Ww Xx Yy Zz

CORBA V2.0

Lexical Conventions

July 1995

3-3

3
Figure 3 on page 3-4 lists the decimal digit characters.
TABLE 3. Decimal

Digits

0123456789

Figure 4 on page 3-4 shows the graphic characters.
TABLE 4. The

65 Graphic Characters
Description exclamation point double quote number sign dollar sign percent sign ampersand apostrophe left parenthesis right parenthesis asterisk plus sign comma hyphen, minus sign period, full stop solidus colon semicolon less-than sign equals sign greater-than sign question mark commercial at left square bracket reverse solidus right square bracket circum?ex low line, underscore grave left curly bracket vertical line right curly bracket tilde ? × ÷ ? ? ? ±
2 3

Char. ! " # $ % & ’ ( ) * + , . / : ; < = > ? @ [ \ ] ^ _ ‘ { | } ~

Char. ? ? ? ¤ ? § ¨ ? ? ? ?

Description inverted exclamation mark cent sign pound sign currency sign yen sign broken bar section/paragraph sign diaeresis copyright sign feminine ordinal indicator left angle quotation mark not sign soft hyphen registered trade mark sign macron ring above, degree sign plus-minus sign superscript two superscript three acute micro pilcrow middle dot cedilla superscript one masculine ordinal indicator right angle quotation mark vulgar fraction 1/4 vulgar fraction 1/2 vulgar fraction 3/4 inverted question mark multiplication sign division sign

? ? ? ? ?
1

? ?

3-4

CORBA V2.0

July 1995

3
The formatting characters are shown in Figure 5 on page 3-5.
TABLE 5. The

Formatting Characters
Abbreviation BEL BS HT NL, LF VT FF CR ISO 646 Octal Value 007 010 011 012 013 014 015

Description alert backspace horizontal tab newline vertical tab form feed carriage return

3.2.1 Tokens
There are ?ve kinds of tokens: identi?ers, keywords, literals, operators, and other separators. Blanks, horizontal and vertical tabs, newlines, formfeeds, and comments (collective, “white space”), as described below, are ignored except as they serve to separate tokens. Some white space is required to separate otherwise adjacent identi?ers, keywords, and constants. If the input stream has been parsed into tokens up to a given character, the next token is taken to be the longest string of characters that could possibly constitute a token.

3.2.2 Comments
The characters /* start a comment, which terminates with the characters */. These comments do not nest. The characters // start a comment, which terminates at the end of the line on which they occur. The comment characters //, /*, and */ have no special meaning within a // comment and are treated just like other characters. Similarly, the comment characters // and /* have no special meaning within a /* comment. Comments may contain alphabetic, digit, graphic, space, horizontal tab, vertical tab, form feed and newline characters.

3.2.3 Identi?ers
An identi?er is an arbitrarily long sequence of alphabetic, digit, and underscore (“_”) characters. The ?rst character must be an alphabetic character. All characters are signi?cant. Identi?ers that differ only in case collide and yield a compilation error. An identi?er for a de?nition must be spelled consistently (with respect to case) throughout a speci?cation. When comparing two identi?ers to see if they collide: ? Upper- and lower-case letters are treated as the same letter. Figure 2 on page 3-3 de?nes the equivalence mapping of upper- and lower-case letters.

CORBA V2.0

Lexical Conventions

July 1995

3-5

3
? The comparison does not take into account equivalences between digraphs and pairs of letters (e.g., “?” and “ae” are not considered equivalent) or equivalences between accented and non-accented letters (e.g., “?” and “A” are not considered equivalent). ? All characters are signi?cant. There is only one namespace for OMG IDL identi?ers. Using the same identi?er for a constant and an interface, for example, produces a compilation error.

3.2.4 Keywords
The identi?ers listed in Figure 6 on page 3-6 are reserved for use as keywords, and may not be used otherwise.
TABLE 6. Keywords

any attribute boolean case char const context

default double enum exception FALSE ?oat in

inout interface long module Object octet oneway

out raises readonly sequence short string struct

switch TRUE typedef unsigned union void

Keywords obey the rules for identi?ers (see Section 3.2.3) and must be written exactly as shown in the above list. For example, “boolean” is correct; “Boolean” produces a compilation error. OMG IDL speci?cations use the characters shown in Figure 7 on page 3-6 as punctuation.
TABLE 7. Punctuation

Characters
} \ : | , ^ = & + * / ( % ) ~ < > [ ]

; '

{ "

In addition, the tokens listed in Figure 8 on page 3-6 are used by the preprocessor.
TABLE 8. Preprocessor

Tokens
! || &&

#

##

3.2.5 Literals
This ? ? ? ? section describes the following literals: Integer Character Floating-point String

3-6

CORBA V2.0

July 1995

3
Integer Literals
An integer literal consisting of a sequence of digits is taken to be decimal (base ten) unless it begins with 0 (digit zero). A sequence of digits starting with 0 is taken to be an octal integer (base eight). The digits 8 and 9 are not octal digits. A sequence of digits preceded by 0x or 0X is taken to be a hexadecimal integer (base sixteen). The hexadecimal digits include a or A through f or F with decimal values ten through ?fteen, respectively. For example, the number twelve can be written 12, 014, or 0XC.

Character Literals
A character literal is one or more characters enclosed in single quotes, as in ’x’. Character literals have type char. A character is an 8-bit quantity with a numerical value between 0 and 255 (decimal). The value of a space, alphabetic, digit or graphic character literal is the numerical value of the character as de?ned in the ISO Latin-1 (8859.1) character set standard (See Figure 2 on page 3-3, Figure 3 on page 3-4, and Figure 4 on page 3-4). The value of a null is 0. The value of a formatting character literal is the numerical value of the character as de?ned in the ISO 646 standard (See Figure 5 on page 3-5). The meaning of all other characters is implementation-dependent. Nongraphic characters must be represented using escape sequences as de?ned below in Figure 9 on page 3-7. Note that escape sequences must be used to represent single quote and backslash characters in character literals.
TABLE 9. Escape

Sequences
Escape Sequence \n \t \v \b \r \f \a \\ \? \' \" \ooo \xhh

Description newline horizontal tab vertical tab backspace carriage return form feed alert backslash question mark single quote double quote octal number hexadecimal number

If the character following a backslash is not one of those speci?ed, the behavior is unde?ned. An escape sequence speci?es a single character.

CORBA V2.0

Lexical Conventions

July 1995

3-7

3
The escape \ooo consists of the backslash followed by one, two, or three octal digits that are taken to specify the value of the desired character. The escape \xhh consists of the backslash followed by x followed by one or two hexadecimal digits that are taken to specify the value of the desired character. A sequence of octal or hexadecimal digits is terminated by the ?rst character that is not an octal digit or a hexadecimal digit, respectively. The value of a character constant is implementation dependent if it exceeds that of the largest char.

Floating-point Literals
A ?oating-point literal consists of an integer part, a decimal point, a fraction part, an e or E, and an optionally signed integer exponent. The integer and fraction parts both consist of a sequence of decimal (base ten) digits. Either the integer part or the fraction part (but not both) may be missing; either the decimal point or the letter e (or E) and the exponent (but not both) may be missing.

String Literals
A string literal is a sequence of characters (as de?ned in “Character Literals” on page 3-7) surrounded by double quotes, as in "...". Adjacent string literals are concatenated. Characters in concatenated strings are kept distinct. For example, "\xA" "B" contains the two characters '\xA' and 'B' after concatenation (and not the single hexadecimal character '\xAB'). The size of a string literal is the number of character literals enclosed by the quotes, after concatenation. The size of the literal is associated with the literal. Within a string, the double quote character " must be preceded by a \. A string literal may not contain the character '\0'.

3.3 Preprocessing
OMG IDL preprocessing, which is based on ANSI C++ preprocessing, provides macro substitution, conditional compilation, and source ?le inclusion. In addition, directives are provided to control line numbering in diagnostics and for symbolic debugging, to generate a diagnostic message with a given token sequence, and to perform implementation-dependent actions (the #pragma directive). Certain prede?ned names are available. These facilities are conceptually handled by a preprocessor, which may or may not actually be implemented as a separate process.

3-8

CORBA V2.0

July 1995

3
Lines beginning with # (also called “directives”) communicate with this preprocessor. White space may appear before the #. These lines have syntax independent of the rest of OMG IDL; they may appear anywhere and have effects that last (independent of the OMG IDL scoping rules) until the end of the translation unit. The textual location of OMG IDL-speci?c pragmas may be semantically constrained. A preprocessing directive (or any line) may be continued on the next line in a source ?le by placing a backslash character (“\”), immediately before the newline at the end of the line to be continued. The preprocessor effects the continuation by deleting the backslash and the newline before the input sequence is divided into tokens. A backslash character may not be the last character in a source ?le. A preprocessing token is an OMG IDL token ( Section 3.2.1), a ?le name as in a #include directive, or any single character, other than white space, that does not match another preprocessing token. The primary use of the preprocessing facilities is to include de?nitions from other OMG IDL speci?cations. Text in ?les included with a #include directive is treated as if it appeared in the including ?le. A complete description of the preprocessing facilities may be found in The Annotated C++ Reference Manual, Chapter 16. The #pragma directive that is used to include RepositoryIds is described in Section 6.6, “RepositoryIds,” on page 6-30.

3.4 OMG IDL Grammar
(1) (2) <speci?cation> <de?nition> ::= <de?nition>+ ::= | | | | <type_dcl> “;” <const_dcl> “;” <except_dcl> “;” <interface> “;” <module> “;”

(3) (4) (5) (6) (7) (8) (9)

<module> <interface> <interface_dcl> <forward_dcl>

::= “module” <identi?er> “{“ <de?nition>+ “}” ::= <interface_dcl> | <forward_dcl> ::= <interface_header> “{” <interface_body> “}” ::= “interface” <identi?er>

<interface_header>::= “interface” <identi?er> [ <inheritance_spec> ] <interface_body> ::= <export>* <export> ::= | | | | <type_dcl> “;” <const_dcl> “;” <except_dcl> “;” <attr_dcl> “;” <op_dcl> “;”

(10)

<inheritance_spec>::= “:” <scoped_name> { “,” <scoped_name> }?

CORBA V2.0

OMG IDL Grammar

July 1995

3-9

3
(11) <scoped_name> ::= <identi?er> | “::” <identi?er> | <scoped_name> “::” <identi?er> ::= “const” <const_type> <identi?er> “=” <const_exp> ::= | | | | | <integer_type> <char_type> <boolean_type> <?oating_pt_type> <string_type> <scoped_name>

(12) (13)

<const_dcl> <const_type>

(14) (15) (16) (17) (18)

<const_exp> <or_expr> <xor_expr> <and_expr> <shift_expr>

::= <or_expr> ::= <xor_expr> | <or_expr> “|” <xor_expr> ::= <and_expr> | <xor_expr> “^” <and_expr> ::= <shift_expr> | <and_expr> “&” <shift_expr> ::= <add_expr> | <shift_expr> “>>” <add_expr> | <shift_expr> “<<” <add_expr> ::= <mult_expr> | <add_expr> “+” <mult_expr> | <add_expr> “-” <mult_expr> ::= | | | <unary_expr> <mult_expr> “*” <unary_expr> <mult_expr> “/” <unary_expr> <mult_expr> “%” <unary_expr>

(19)

<add_expr>

(20)

<mult_expr>

(21) (22)

<unary_expr>

::= <unary_operator> <primary_expr> | <primary_expr>

<unary_operator> ::= “-” | “+” | “~” <primary_expr> ::= <scoped_name> | <literal> | “(” <const_exp> “)” ::= | | | | <integer_literal> <string_literal> <character_literal> <?oating_pt_literal> <boolean_literal>

(23)

(24)

<literal>

(25) (26)

<boolean_literal> ::= “TRUE” | “FALSE” <positive_int_const>::=<const_exp>

3-10

CORBA V2.0

July 1995

3
(27) <type_dcl> ::= | | | “typedef” <type_declarator> <struct_type> <union_type> <enum_type>

(28) (29) (30)

<type_declarator> ::= <type_spec> <declarators> <type_spec> ::= <simple_type_spec> | <constr_type_spec>

<simple_type_spec>::=<base_type_spec> | <template_type_spec> | <scoped_name> <base_type_spec> ::= | | | | | <?oating_pt_type> <integer_type> <char_type> <boolean_type> <octet_type> <any_type>

(31)

(32) (33)

<template_type_spec>::=<sequence_type> | <string_type> <constr_type_spec>::=<struct_type> | <union_type> | <enum_type> <declarators> <declarator> ::= <declarator> { “,” <declarator> }? ::= <simple_declarator> | <complex_declarator>

(34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47)

<simple_declarator>::=<identi?er> <complex_declarator>::=<array_declarator> <?oating_pt_type> ::= “?oat” | “double” <integer_type> <signed_int> ::= <signed_int> | <unsigned_int> ::= <signed_long_int> | <signed_short_int>

<signed_long_int> ::= “long” <signed_short_int>::= “short” <unsigned_int> ::= <unsigned_long_int> | <unsigned_short_int>

<unsigned_long_int>::=“unsigned” “long” <unsigned_short_int>::=“unsigned” “short” <char_type> <boolean_type> ::= “char” ::= “boolean”

CORBA V2.0

OMG IDL Grammar

July 1995

3-11

3
(48) (49) (50) (51) (52) (53) (54) <octet_type> <any_type> <struct_type> <member_list> <member> <union_type> ::= “octet” ::= “any” ::= “struct” <identi?er> “{” <member_list> “}” ::= <member>+ ::= <type_spec> <declarators> “;” ::= “union” <identi?er> “switch” “(” <switch_type_spec> “)” “{” <switch_body> “}”

<switch_type_spec>::=<integer_type> | <char_type> | <boolean_type> | <enum_type> | <scoped_name> <switch_body> <case> <case_label> <element_spec> <enum_type> <enumerator> ::= <case>+ ::= <case_label>+ <element_spec> “;” ::= “case” <const_exp> “:” | “default” “:” ::= <type_spec> <declarator> ::= “enum” <identi?er> “{” <enumerator> { “,” <enumerator> }? “}” ::= <identi?er>

(55) (56) (57) (58) (59) (60) (61) (62) (63) (64) (65) (66) (67) (68) (69) (70) (71) (72)

<sequence_type> ::= “sequence” “<” <simple_type_spec> “,”<positive_int_const>“>” | “sequence” “<” <simple_type_spec> “>” <string_type> ::= “string” “<” <positive_int_const> “>” | “string”

<array_declarator>::= <identi?er> <?xed_array_size>+ <?xed_array_size>::= “[” <positive_int_const> “]” <attr_dcl> <except_dcl> <op_dcl> <op_attribute> <op_type_spec> ::= [ “readonly” ] “attribute” <param_type_spec> <simple_declarator> { “,” <simple_declarator> }* ::= “exception” <identi?er> “{“ <member>* “}” ::= [ <op_attribute> ] <op_type_spec> <identi?er> <parameter_dcls> [ <raises_expr> ] [ <context_expr> ] ::= “oneway” ::= <param_type_spec> | “void”

<parameter_dcls> ::= “(” <param_dcl> { “,” <param_dcl> }? “)” | “(” “)” <param_dcl> ::= <param_attribute> <param_type_spec> <simple_declarator>

<param_attribute> ::= “in” | “out” | “inout”

3-12

CORBA V2.0

July 1995

3
(73) (74) (75) <raises_expr> <context_expr> ::= “raises” “(” <scoped_name> { “,” <scoped_name> }? “)” ::= “context” “(” <string_literal> { “,” <string_literal> }? “)”

<param_type_spec>::=<base_type_spec> | <string_type> | <scoped_name>

3.5 OMG IDL Speci?cation
An OMG IDL speci?cation consists of one or more type de?nitions, constant de?nitions, exception de?nitions, or module de?nitions. The syntax is: <speci?cation>::= <de?nition>+ <de?nition> ::= | | | | <type_dcl> “;” <const_dcl> “;” <except_dcl> “;” <interface> “;” <module> “;”

See “Constant Declaration” on page 3-17, “Type Declaration” on page 3-19, and , “Exception Declaration” on page 3-26, respectively, for speci?cations of <const_dcl>, <type_dcl>, and <except_dcl>.

3.5.1 Module Declaration
A module de?nition satis?es the following syntax: <module> ::= “module” <identi?er> “{“ <de?nition>+ “}”

The module construct is used to scope OMG IDL identi?ers; see “CORBA Module” on page 3-31 for details.

3.5.2 Interface Declaration
An interface de?nition satis?es the following syntax: <interface> ::= <interface_dcl> | <forward_dcl>

<interface_dcl>::= <interface_header> “{” <interface_body> “}” <forward_dcl> ::= “interface” <identi?er> <interface_header>::=“interface” <identi?er> [ <inheritance_spec> ] <interface_body>::=<export>* <export> ::= <type_dcl> “;” | <const_dcl> “;”

CORBA V2.0

OMG IDL Speci?cation

July 1995

3-13

3
| | | <except_dcl> “;” <attr_dcl> “;” <op_dcl> “;”

Interface Header
The interface header consists of two elements: ? The interface name. The name must be preceded by the keyword interface, and consists of an identi?er that names the interface. ? An optional inheritance speci?cation. The inheritance speci?cation is described in the next section. The <identi?er> that names an interface de?nes a legal type name. Such a type name may be used anywhere an <identi?er> is legal in the grammar, subject to semantic constraints as described in the following sections. Since one can only hold references to an object, the meaning of a parameter or structure member which is an interface type is as a reference to an object supporting that interface. Each language binding describes how the programmer must represent such interface references.

Inheritance Speci?cation
The syntax for inheritance is as follows: <inheritance_spec>::= “:” <scoped_name> {“,” <scoped_name>}* <scoped_name>::= <identi?er> | “::” <identi?er> | <scoped_name> “::” <identi?er> Each <scoped_name> in an <inheritance_spec> must denote a previously de?ned interface. See “Inheritance” on page 3-15 for the description of inheritance.

Interface Body
The interface body contains the following kinds of declarations: ? Constant declarations, which specify the constants that the interface exports; constant declaration syntax is described in “Constant Declaration” on page 3-17. ? Type declarations, which specify the type de?nitions that the interface exports; type declaration syntax is described in “Type Declaration” on page 3-19. ? Exception declarations, which specify the exception structures that the interface exports; exception declaration syntax is described in “Exception Declaration” on page 3-26. ? Attribute declarations, which specify the associated attributes exported by the interface; attribute declaration syntax is described in “Attribute Declaration” on page 3-30.

3-14

CORBA V2.0

July 1995

3
? Operation declarations, which specify the operations that the interface exports and the format of each, including operation name, the type of data returned, the types of all parameters of an operation, legal exceptions which may be returned as a result of an invocation, and contextual information which may affect method dispatch; operation declaration syntax is described in “Operation Declaration” on page 3-27. Empty interfaces are permitted (that is, those containing no declarations). Some implementations may require interface-speci?c pragmas to precede the interface body.

Forward Declaration
A forward declaration declares the name of an interface without de?ning it. This permits the de?nition of interfaces that refer to each other. The syntax consists simply of the keyword interface followed by an <identi?er> that names the interface. The actual de?nition must follow later in the speci?cation. Multiple forward declarations of the same interface name are legal.

3.6 Inheritance
An interface can be derived from another interface, which is then called a base interface of the derived interface. A derived interface, like all interfaces, may declare new elements (constants, types, attributes, exceptions, and operations). In addition, unless rede?ned in the derived interface, the elements of a base interface can be referred to as if they were elements of the derived interface. The name resolution operator (“::”) may be used to refer to a base element explicitly; this permits reference to a name that has been rede?ned in the derived interface. A derived interface may rede?ne any of the type, constant, and exception names which have been inherited; the scope rules for such names are described in “CORBA Module” on page 3-31. An interface is called a direct base if it is mentioned in the <inheritance_spec> and an indirect base if it is not a direct base but is a base interface of one of the interfaces mentioned in the <inheritance_spec>. An interface may be derived from any number of base interfaces. Such use of more than one direct base interface is often called multiple inheritance. The order of derivation is not signi?cant. An interface may not be speci?ed as a direct base interface of a derived interface more than once; it may be an indirect base interface more than once. Consider the following example: interface A { ... } interface B: A { ... } interface C: A { ... } interface D: B, C { ... }

CORBA V2.0

Inheritance

July 1995

3-15

3
The relationships between these interfaces is shown in Figure 11 on page 3-16. This “diamond” shape is legal.
FIGURE 11.

Legal Multiple Inheritance Example

A

B

C

D

Reference to base interface elements must be unambiguous. Reference to a base interface element is ambiguous if the expression used refers to a constant, type, or exception in more than one base interface. (It is currently illegal to inherit from two interfaces with the same operation or attribute name, or to rede?ne an operation or attribute name in the derived interface.) Ambiguities can be resolved by qualifying a name with its interface name (that is, using a <scoped_name>). References to constants, types, and exceptions are bound to an interface when it is de?ned i.e., replaced with the equivalent global <scoped_name>s. This guarantees that the syntax and semantics of an interface are not changed when the interface is a base interface for a derived interface. Consider the following example: const long L = 3; interface A { void f (in ?oat s[L]); }; interface B { const long L = 4; }; interface C: B, A {}// what is f()’s signature? The early binding of constants, types, and exceptions at interface de?nition guarantees that the signature of operation f in interface C is void f(in ?oat s[3]);

// s has 3 ?oats

3-16

CORBA V2.0

July 1995

3
which is identical to that in interface A. This rule also prevents rede?nition of a constant, type, or exception in the derived interface from affecting the operations and attributes inherited from a base interface. Interface inheritance causes all identi?ers in the closure of the inheritance tree to be imported into the current naming scope. A type name, constant name, enumeration value name, or exception name from an enclosing scope can be rede?ned in the current scope. An attempt to use an ambiguous name without quali?cation is a compilation error. Operation names are used at runtime by both the stub and dynamic interfaces. As a result, all operations that might apply to a particular object must have unique names. This requirement prohibits rede?ning an operation name in a derived interface, as well as inheriting two operations with the same name. Note – It is anticipated that future revisions of the language may relax this rule in some way, perhaps allowing overloading or providing some means to distinguish operations with the same name.

3.7 Constant Declaration
This section describes the syntax for constant declarations.

3.7.1 Syntax
The syntax for a constant declaration is: <const_dcl> ::= “const” <const_type> <identi?er> “=” <const_exp> <integer_type> <char_type> <boolean_type> <?oating_pt_type> <string_type> <scoped_name>

<const_type> ::= | | | | | <const_exp> <or_expr> <xor_expr> <and_expr> <shift_expr>

::= <or_expr> ::= <xor_expr> | <or_expr> “|” <xor_expr> ::= <and_expr> | <xor_expr> “^” <and_expr> ::= <shift_expr> | <and_expr> “&” <shift_expr> ::= <add_expr> | <shift_expr> “>>” <add_expr> | <shift_expr> “<<” <add_expr>

CORBA V2.0

Constant Declaration

July 1995

3-17

3
<add_expr> ::= <mult_expr> | <add_expr> “+” <mult_expr> | <add_expr> “-” <mult_expr> ::= | | | <unary_expr> <mult_expr> “*” <unary_expr> <mult_expr> “/” <unary_expr> <mult_expr> “%” <unary_expr>

<mult_expr>

<unary_expr> ::= <unary_operator> <primary_expr> | <primary_expr> <unary_operator>::=“-” | “+” | “~” <primary_expr>::= <scoped_name> | <literal> | “(” <const_exp> “)” <literal> ::= | | | | <integer_literal> <string_literal> <character_literal> <?oating_pt_literal> <boolean_literal>

<boolean_literal>::=“TRUE” | “FALSE” <positive_int_const>::=<const_exp>

3.7.2 Semantics
The <scoped_name> in the <const_type> production must be a previously de?ned name of an <integer_type>, <char_type>, <boolean_type>, <?oating_pt_type>, or <string_type> constant. No in?x operator can combine an integer and a ?oat. In?x operators are not applicable to types other than integer and ?oat. An integer constant expression is evaluated as unsigned long unless it contains a negated integer literal or the name of an integer constant with a negative value. In the latter case, the constant expression is evaluated as signed long. The computed value is coerced back to the target type in constant initializers. It is an error if the computed value exceeds the precision of the target type. It is an error if any intermediate value exceeds the range of the evaluated-as type (long or unsigned long). All ?oating-point literals are double, all ?oating-point constants are coerced to double, and all ?oating-point expressions are computed as doubles. The computed double value is coerced back to the target type in constant initializers. It is an error if this coercion fails or if any intermediate values (when evaluating the expression) exceed the range of double.

3-18

CORBA V2.0

July 1995

3
Unary (+ –) and binary (* / + –) operators are applicable in ?oating-point expressions. Unary (+ – ~) and binary (* / % + – << >> & | ^) operators are applicable in integer expressions. The “~” unary operator indicates that the bit-complement of the expression to which it is applied should be generated. For the purposes of such expressions, the values are 2’s complement numbers. As such, the complement can be generated as follows:

long

–(value+1) (2**32 – 1) – value

unsigned long

The “%” binary operator yields the remainder from the division of the ?rst expression by the second. If the second operand of “%” is 0, the result is unde?ned; otherwise (a/b)*b + a%b is equal to a. If both operands are nonnegative, then the remainder is nonnegative; if not, the sign of the remainder is implementation dependent. The “<<”binary operator indicates that the value of the left operand should be shifted left the number of bits speci?ed by the right operand, with 0 ?ll for the vacated bits. The right operand must be in the range 0 <= right operand < 32. The “>>” binary operator indicates that the value of the left operand should be shifted right the number of bits speci?ed by the right operand, with 0 ?ll for the vacated bits. The right operand must be in the range 0 <= right operand < 32. The “&” binary operator indicates that the logical, bitwise AND of the left and right operands should be generated. The “|” binary operator indicates that the logical, bitwise OR of the left and right operands should be generated. The “^” binary operator indicates that the logical, bitwise EXCLUSIVE-OR of the left and right operands should be generated.

<positive_int_const> must evaluate to a positive integer constant.

3.8 Type Declaration
OMG IDL provides constructs for naming data types; that is, it provides C languagelike declarations that associate an identi?er with a type. OMG IDL uses the typedef keyword to associate a name with a data type; a name is also associated with a data type via the struct, union, and enum declarations; the syntax is: <type_dcl> ::= | | | “typedef” <type_declarator> <struct_type> <union_type> <enum_type>

<type_declarator>::=<type_spec> <declarators>

CORBA V2.0

Type Declaration

July 1995

3-19

3
For type declarations, OMG IDL de?nes a set of type speci?ers to represent typed values. The syntax is as follows: <type_spec> ::= <simple_type_spec> | <constr_type_spec>

<simple_type_spec>::=<base_type_spec> | <template_type_spec> | <scoped_name> <base_type_spec>::=<?oating_pt_type> | <integer_type> | <char_type> | <boolean_type> | <octet_type> | <any_type> <template_type_spec>::=<sequence_type> | <string_type> <constr_type_spec>::=<struct_type> | <union_type> | <enum_type> <declarators> ::= <declarator> { “,” <declarator> }? <declarator> ::= <simple_declarator> | <complex_declarator>

<simple_declarator>::=<identi?er> <complex_declarator>::=<array_declarator> The <scoped_name> in <simple_type_spec> must be a previously de?ned type. As seen above, OMG IDL type speci?ers consist of scalar data types and type constructors. OMG IDL type speci?ers can be used in operation declarations to assign data types to operation parameters. The next sections describe basic and constructed type speci?ers.

3.8.1 Basic Types
The syntax for the supported basic types is as follows: <?oating_pt_type>::=“?oat” | “double” <integer_type>::= <signed_int> | <unsigned_int> <signed_int> ::= <signed_long_int> | <signed_short_int>

<signed_long_int>::=“long”

3-20

CORBA V2.0

July 1995

3
<signed_short_int>::=“short” <unsigned_int>::= <unsigned_long_int> | <unsigned_short_int> <unsigned_long_int>::=“unsigned” “long” <unsigned_short_int>::=“unsigned” “short” <char_type> ::= “char”

<boolean_type>::= “boolean” <octet_type> <any_type> ::= “octet” ::= “any”

Each OMG IDL data type is mapped to a native data type via the appropriate language mapping. Conversion errors between OMG IDL data types and the native types to which they are mapped can occur during the performance of an operation invocation. The invocation mechanism (client stub, dynamic invocation engine, and skeletons) may signal an exception condition to the client if an attempt is made to convert an illegal value. The standard exceptions which are to be signalled in such situations are de?ned in “Standard Exceptions” on page 3-33.

Integer Types
OMG IDL supports long and short signed and unsigned integer data types. long represents the range -2 31 .. 231 - 1 while unsigned long represents the range 0 .. 232 - 1. short represents the range -2 15 .. 215 - 1, while unsigned short represents the range 0 .. 216 - 1.

Floating-Point Types
OMG IDL ?oating-point types are ?oat and double. The ?oat type represents IEEE single-precision ?oating point numbers; the double type represents IEEE double-precision ?oating point numbers.The IEEE ?oating point standard speci?cation (IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Std 754-1985) should be consulted for more information on the precision afforded by these types. Implementations that do not fully support the value set of the IEEE 754 ?oating-point standard must completely specify their deviance from the standard.

Char Type
OMG IDL de?nes a char data type consisting of 8-bit quantities. The ISO Latin-1 (8859.1) character set standard de?nes the meaning and representation of all possible graphic characters (i.e., the space, alphabetic, digit and graphic characters de?ned in Figure 2 on page 3-3, Figure 3 on page 3-4, and Figure 4 on page 3-4). The meaning and representation of the null and formatting characters

CORBA V2.0

Type Declaration

July 1995

3-21

3
(see Figure 5 on page 3-5) is the numerical value of the character as de?ned in the ASCII (ISO 646) standard. The meaning of all other characters is implementationdependent. During transmission, characters may be converted to other appropriate forms as required by a particular language binding. Such conversions may change the representation of a character but maintain the character’s meaning. For example, a character may be converted to and from the appropriate representation in international character sets.

Boolean Type
The boolean data type is used to denote a data item that can only take one of the values TRUE and FALSE.

Octet Type
The octet type is an 8-bit quantity that is guaranteed not to undergo any conversion when transmitted by the communication system.

Any Type
The any type permits the speci?cation of values that can express any OMG IDL type.

3.8.2 Constructed Types
The constructed types are: <constr_type_spec>::=<struct_type> | <union_type> | <enum_type> Although it is syntactically possible to generate recursive type speci?cations in OMG IDL, such recursion is semantically constrained. The only permissible form of recursive type speci?cation is through the use of the sequence template type. For example, the following is legal: struct foo { long value; sequence<foo> chain; } See “Sequences” on page 3-25 for details of the sequence template type.

Structures
The structure syntax is:

3-22

CORBA V2.0

July 1995

3
<struct_type> ::= “struct” <identi?er> “{” <member_list> “}” <member_list> ::= <member>+ <member> ::= <type_spec> <declarators> “;”

The <identi?er> in <struct_type> de?nes a new legal type. Structure types may also be named using a typedef declaration. Name scoping rules require that the member declarators in a particular structure be unique. The value of a struct is the value of all of its members.

Discriminated Unions
The discriminated union syntax is: <union_type> ::= “union” <identi?er> “switch” “(” <switch_type_spec> “)” “{” <switch_body> “}” <switch_type_spec>::=<integer_type> | <char_type> | <boolean_type> | <enum_type> | <scoped_name> <switch_body>::= <case>+ <case> ::= <case_label>+ <element_spec> “;”

<case_label> ::= “case” <const_exp> “:” | “default” “:” <element_spec>::=<type_spec> <declarator> OMG IDL unions are a cross between the C union and switch statements. IDL unions must be discriminated; that is, the union header must specify a typed tag ?eld that determines which union member to use for the current instance of a call. The <identi?er> following the union keyword de?nes a new legal type. Union types may also be named using a typedef declaration. The <const_exp> in a <case_label> must be consistent with the <switch_type_spec>. A default case can appear at most once. The <scoped_name> in the <switch_type_spec> production must be a previously de?ned integer, char, boolean or enum type.

CORBA V2.0

Type Declaration

July 1995

3-23

3
Case labels must match or be automatically castable to the de?ned type of the discriminator. The complete set of matching rules are shown in Figure 10 on page 3-24.
TABLE 10. Case

Label Matching
Matched By any integer value in the value range of long any integer value in the value range of short any integer value in the value range of unsigned long any integer value in the value range of unsigned short char TRUE or FALSE any enumerator for the discriminator enum type

Discriminator Type long short unsigned long unsigned short char boolean enum

Name scoping rules require that the element declarators in a particular union be unique. If the <switch_type_spec> is an <enum_type>, the identi?er for the enumeration is in the scope of the union; as a result, it must be distinct from the element declarators. It is not required that all possible values of the union discriminator be listed in the <switch_body>. The value of a union is the value of the discriminator together with one of the following: ? If the discriminator value was explicitly listed in a case statement, the value of the element associated with that case statement; ? If a default case label was speci?ed, the value of the element associated with the default case label; ? No additional value. Access to the discriminator and the related element is language-mapping dependent.

Enumerations
Enumerated types consist of ordered lists of identi?ers. The syntax is: <enum_type> ::= “enum” <identi?er> “{” <enumerator> { “,” <enumerator> }? “}” <enumerator> ::= <identi?er> A maximum of 232 identi?ers may be speci?ed in an enumeration; as such, the enumerated names must be mapped to a native data type capable of representing a maximally-sized enumeration. The order in which the identi?ers are named in the speci?cation of an enumeration de?nes the relative order of the identi?ers. Any language mapping which permits two enumerators to be compared or de?nes

3-24

CORBA V2.0

July 1995

3
successor/predecessor functions on enumerators must conform to this ordering relation. The <identi?er> following the enum keyword de?nes a new legal type. Enumerated types may also be named using a typedef declaration.

3.8.3 Template Types
The template types are: <template_type_spec>: :=<sequence_type> | <string_type>

Sequences
OMG IDL de?nes the sequence type sequence. A sequence is a one-dimensional array with two characteristics: a maximum size (which is ?xed at compile time) and a length (which is determined at run time). The syntax is: <sequence_type> ::=“sequence” “<” <simple_type_spec> “,” <positive_int_const> “>” | “sequence” “<” <simple_type_spec> “>” The second parameter in a sequence declaration indicates the maximum size of the sequence. If a positive integer constant is speci?ed for the maximum size, the sequence is termed a bounded sequence. Prior to passing a bounded sequence as a function argument (or as a ?eld in a structure or union), the length of the sequence must be set in a language-mapping dependent manner. After receiving a sequence result from an operation invocation, the length of the returned sequence will have been set; this value may be obtained in a language-mapping dependent manner. If no maximum size is speci?ed, size of the sequence is unspeci?ed (unbounded). Prior to passing such a sequence as a function argument (or as a ?eld in a structure or union), the length of the sequence, the maximum size of the sequence, and the address of a buffer to hold the sequence must be set in a language-mapping dependent manner. After receiving such a sequence result from an operation invocation, the length of the returned sequence will have been set; this value may be obtained in a languagemapping dependent manner. A sequence type may be used as the type parameter for another sequence type. For example, the following: typedef sequence< sequence<long> > Fred; declares Fred to be of type “unbounded sequence of unbounded sequence of long”. Note that for nested sequence declarations, white space must be used to separate the two “>” tokens ending the declaration so they are not parsed as a single “>>” token.

CORBA V2.0

Type Declaration

July 1995

3-25

3
Strings
OMG IDL de?nes the string type string consisting of all possible 8-bit quantities except null. A string is similar to a sequence of char. As with sequences of any type, prior to passing a string as a function argument (or as a ?eld in a structure or union), the length of the string must be set in a language-mapping dependent manner. The syntax is: <string_type>: :=“string” “<” <positive_int_const> “>” | “string” The argument to the string declaration is the maximum size of the string. If a positive integer maximum size is speci?ed, the string is termed a bounded string; if no maximum size is speci?ed, the string is termed an unbounded string. Strings are singled out as a separate type because many languages have special built-in functions or standard library functions for string manipulation. A separate string type may permit substantial optimization in the handling of strings compared to what can be done with sequences of general types.

3.8.4 Complex Declarator
Arrays
OMG IDL de?nes multidimensional, ?xed-size arrays. An array includes explicit sizes for each dimension. The syntax for arrays is: <array_declarator> ::=<identi?er> <?xed_array_size>+ <?xed_array_size> ::=“[” <positive_int_const> “]” The array size (in each dimension) is ?xed at compile time. When an array is passed as a parameter in an operation invocation, all elements of the array are transmitted. The implementation of array indices is language mapping speci?c; passing an array index as a parameter may yield incorrect results.

3.9 Exception Declaration
Exception declarations permit the declaration of struct-like data structures which may be returned to indicate that an exceptional condition has occurred during the performance of a request. The syntax is as follows: <except_dcl> : :=“exception” <identi?er> “{“ <member>* “}”

3-26

CORBA V2.0

July 1995

3
Each exception is characterized by its OMG IDL identi?er, an exception type identi?er, and the type of the associated return value (as speci?ed by the <member>s in its declaration. If an exception is returned as the outcome to a request, then the value of the exception identi?er is accessible to the programmer for determining which particular exception was raised. If an exception is declared with members, a programmer will be able to access the values of those members when an exception is raised. If no members are speci?ed, no additional information is accessible when an exception is raised. A set of standard exceptions is de?ned corresponding to standard runtime errors which may occur during the execution of a request. These standard exceptions are documented in “Standard Exceptions” on page 3-33.

3.10 Operation Declaration
Operation declarations in OMG IDL are similar to C function declarations. The syntax is: <op_dcl> ::= [ <op_attribute> ] <op_type_spec> <identi?er> <parameter_dcls> [ <raises_expr> ] [ <context_expr> ]

<op_type_spec>::=<param_type_spec> | “void” An operation declaration consists of: ? An optional operation attribute that speci?es which invocation semantics the communication system should provide when the operation is invoked. Operation attributes are described in “Operation Attribute” on page 3-28. ? The type of the operation’s return result; the type may be any type which can be de?ned in OMG IDL. Operations that do not return a result must specify the void type. ? An identi?er that names the operation in the scope of the interface in which it is de?ned. ? A parameter list that speci?es zero or more parameter declarations for the operation. Parameter declaration is described in “Parameter Declarations” on page 3-28. ? An optional raises expression which indicates which exceptions may be raised as a result of an invocation of this operation. Raises expressions are described in Section “Raises Expressions” on page 3-29. ? An optional context expression which indicates which elements of the request context may be consulted by the method that implements the operation. Context expressions are described in “Context Expressions” on page 3-29. Some implementations and/or language mappings may require operation-speci?c pragmas to immediately precede the affected operation declaration.

CORBA V2.0

Operation Declaration

July 1995

3-27

3
3.10.1 Operation Attribute
The operation attribute speci?es which invocation semantics the communication service must provide for invocations of a particular operation. An operation attribute is optional. The syntax for its speci?cation is as follows: <op_attribute> ::= “oneway” When a client invokes an operation with the oneway attribute, the invocation semantics are best-effort, which does not guarantee delivery of the call; best-effort implies that the operation will be invoked at most once. An operation with the oneway attribute must not contain any output parameters and must specify a void return type. An operation de?ned with the oneway attribute may not include a raises expression; invocation of such an operation, however, may raise a standard exception. If an <op_attribute> is not speci?ed, the invocation semantics is at-most-once if an exception is raised; the semantics are exactly-once if the operation invocation returns successfully.

3.10.2 Parameter Declarations
Parameter declarations in OMG IDL operation declarations have the following syntax: <parameter_dcls>::=“(” <param_dcl> { “,” <param_dcl> }? “)” | “(” “)” <param_dcl> ::= <param_attribute> <param_type_spec> <simple_declarator>

<param_attribute>::=“in” | “out” | “inout” <param_type_spec>::=<base_type_spec> | <string_type> | <scoped_name>

A parameter declaration must have a directional attribute that informs the communication service in both the client and the server of the direction in which the parameter is to be passed. The directional attributes are: ? in - the parameter is passed from client to server. ? out - the parameter is passed from server to client. ? inout - the parameter is passed in both directions. It is expected that an implementation will not attempt to modify an in parameter. The ability to even attempt to do so is language-mapping speci?c; the effect of such an action is unde?ned.

3-28

CORBA V2.0

July 1995

3
If an exception is raised as a result of an invocation, the values of the return result and any out and inout parameters are unde?ned. When an unbounded string or sequence is passed as an inout parameter, the returned value cannot be longer than the input value.

3.10.3 Raises Expressions
A raises expression speci?es which exceptions may be raised as a result of an invocation of the operation. The syntax for its speci?cation is as follows: <raises_expr> ::= “raises” “(” <scoped_name> { “,” <scoped_name> }? “)”

The <scoped_name>’s in the raises expression must be previously defined exceptions. In addition to any operation-speci?c exceptions speci?ed in the raises expression, there are a standard set of exceptions that may be signalled by the ORB. These standard exceptions are described in “Standard Exceptions” on page 3-33. However, standard exceptions may not be listed in a raises expression. The absence of a raises expression on an operation implies that there are no operation-speci?c exceptions. Invocations of such an operation are still liable to receive one of the standard exceptions.

3.10.4 Context Expressions
A context expression speci?es which elements of the client’s context may affect the performance of a request by the object. The syntax for its speci?cation is as follows: <context_expr>::= “context” “(” <string_literal> { “,” <string_literal> }? “)” The runtime system guarantees to make the value (if any) associated with each <string_literal> in the client’s context available to the object implementation when the request is delivered. The ORB and/or object is free to use information in this request context during request resolution and performance. The absence of a context expression indicates that there is no request context associated with requests for this operation. Each string_literal is an arbitrarily long sequence of alphabetic, digit, period (“.”), underscore (“_”), and asterisk (“*”) characters. The ?rst character of the string must be an alphabetic character. An asterisk may only be used as the last character of the string. Some implementations may use the period character to partition the name space. The mechanism by which a client associates values with the context identi?ers is described in the Dynamic Invocation Interface chapter.

CORBA V2.0

Operation Declaration

July 1995

3-29

3
3.11 Attribute Declaration
An interface can have attributes as well as operations; as such, attributes are de?ned as part of an interface. An attribute de?nition 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. The syntax for attribute declaration is: <attr_dcl> ::=[ “readonly” ] “attribute” <param_type_spec> <simple_declarator> { “,” <simple_declarator> }*

The optional readonly keyword indicates that there is only a single accessor function—the retrieve value function. Consider the following example: interface foo { enum material_t {rubber, glass}; struct position_t { ?oat x, y; }; attribute ?oat radius; attribute material_t material; readonly attribute position_t position; ??? }; The attribute declarations are equivalent to the following pseudo-speci?cation fragment: ??? ?oat _get_radius (); void _set_radius (in ?oat r); material_t _get_material (); void _set_material (in material_t m); position_t _get_position (); ??? The actual accessor function names are language-mapping speci?c. The C, C++, and Smalltalk mappings are described in separate chapters. The attribute name is subject to OMG IDL’s name scoping rules; the accessor function names are guaranteed not to collide with any legal operation names speci?able in OMG IDL. Attribute operations return errors by means of standard exceptions. Attributes are inherited. An attribute name cannot be rede?ned to be a different type. See “CORBA Module” on page 3-31 for more information on rede?nition constraints and the handling of ambiguity.

3-30

CORBA V2.0

July 1995

3
3.12 CORBA Module
In order to prevent names de?ned in the CORBA speci?cation from clashing with names in programming languages and other software systems, all names de?ned in CORBA are treated as if they were de?ned within a module named CORBA. In an OMG IDL speci?cation, however, OMG IDL keywords such as Object must not be preceded by a “CORBA::” pre?x. Other interface names such as TypeCode are not OMG IDL keywords, so they must be referred to by their fully scoped names (e.g., CORBA::TypeCode) within an OMG IDL speci?cation.

3.13 Names and Scoping
An entire OMG IDL ?le forms a naming scope. In addition, the following kinds of de?nitions form nested scopes: ? module ? interface ? structure ? union ? operation ? exception Identi?ers for the following kinds of de?nitions are scoped: ? types ? constants ? enumeration values ? exceptions ? interfaces ? attributes ? operations An identi?er can only be de?ned once in a scope. However, identi?ers can be rede?ned in nested scopes. An identi?er declaring a module is considered to be de?ned by its ?rst occurrence in a scope. Subsequent occurrences of a module declaration within the same scope reopen the module allowing additional de?nitions to be added to it. Due to possible restrictions imposed by future language bindings, OMG IDL identi?ers are case insensitive; that is, two identi?ers that differ only in the case of their characters are considered rede?nitions of one another. However, all references to a de?nition must use the same case as the de?ning occurrence. (This allows natural mappings to case-sensitive languages.) Type names de?ned in a scope are available for immediate use within that scope. In particular, see “Constructed Types” on page 3-22 on cycles in type de?nitions.

CORBA V2.0

CORBA Module

July 1995

3-31

3
A name can be used in an unquali?ed form within a particular scope; it will be resolved by successively searching farther out in enclosing scopes. Once an unquali?ed name is used in a scope, it cannot be rede?ned—i.e. if one has used a name de?ned in an enclosing scope in the current scope, one cannot then rede?ne a version of the name in the current scope. Such rede?nitions yield a compilation error. A quali?ed name (one of the form <scoped-name>::<identi?er>) is resolved by ?rst resolving the quali?er <scoped-name> to a scope S, and then locating the de?nition of <identi?er> within S. The identi?er must be directly de?ned in S or (if S is an interface) inherited into S. The <identi?er> is not searched for in enclosing scopes. When a quali?ed name begins with “::”, the resolution process starts with the ?le scope and locates subsequent identi?ers in the quali?ed name by the rule described in the previous paragraph. Every OMG IDL de?nition in a ?le has a global name within that ?le. The global name for a de?nition is constructed as follows. Prior to starting to scan a ?le containing an OMG IDL speci?cation, the name of the current root is initially empty (“”) and the name of the current scope is initially empty (“”). Whenever a module keyword is encountered, the string “::” and the associated identi?er are appended to the name of the current root; upon detection of the termination of the module, the trailing “::” and identi?er are deleted from the name of the current root. Whenever an interface, struct, union, or exception keyword is encountered, the string “::” and the associated identi?er are appended to the name of the current scope; upon detection of the termination of the interface, struct, union, or exception, the trailing “::” and identi?er are deleted from the name of the current scope. Additionally, a new, unnamed, scope is entered when the parameters of an operation declaration are processed; this allows the parameter names to duplicate other identi?ers; when parameter processing has completed, the unnamed scope is exited. The global name of an OMG IDL de?nition is the concatenation of the current root, the current scope, a “::”, and the <identi?er>, which is the local name for that de?nition. Note that the global name in an OMG IDL ?les corresponds to an absolute ScopedName in the Interface Repository. (See “Supporting Type De?nitions” on page 6-8.) Inheritance produces shadow copies of the inherited identi?ers; that is, it introduces names into the derived interface, but these names are considered to be semantically the same as the original de?nition. Two shadow copies of the same original (as results from the diamond shape in Figure 11 on page 3-16) introduce a single name into the derived interface and don’t con?ict with each other. Inheritance introduces multiple global OMG IDL names for the inherited identi?ers. Consider the following example:

3-32

CORBA V2.0

July 1995

3
interface A { exception E { long L; }; void f() raises(E); }; interface B: A { void g() raises(E); }; In this example, the exception is known by the global names ::A::E and ::B::E.

Ambiguity can arise in speci?cations due to the nested naming scopes. For example: interface A { typedef string<128> string_t; }; interface B { typedef string<256> string_t; }; interface C: A, B { attribute string_t Title;/* AMBIGUOUS!!! */ }; The attribute declaration in C is ambiguous, since the compiler does not know which string_t is desired. Ambiguous declarations yield compilation errors.

3.14 Differences from C++
The OMG IDL grammar, while attempting to conform to the C++ syntax, is somewhat more restrictive. The current restrictions are as follows: ? A function return type is mandatory. ? A name must be supplied with each formal parameter to an operation declaration. ? A parameter list consisting of the single token void is not permitted as a synonym for an empty parameter list. ? Tags are required for structures, discriminated unions, and enumerations. ? Integer types cannot be de?ned as simply int or unsigned; they must be declared explicitly as short or long. ? char cannot be quali?ed by signed or unsigned keywords.

3.15 Standard Exceptions
This section presents the standard exceptions de?ned for the ORB. These exception identi?ers may be returned as a result of any operation invocation, regardless of the interface speci?cation. Standard exceptions may not be listed in raises expressions.

CORBA V2.0

Differences from C++

July 1995

3-33

3
In order to bound the complexity in handling the standard exceptions, the set of standard exceptions should be kept to a tractable size. This constraint forces the de?nition of equivalence classes of exceptions rather than enumerating many similar exceptions. For example, an operation invocation can fail at many different points due to the inability to allocate dynamic memory. Rather than enumerate several different exceptions corresponding to the different ways that memory allocation failure causes the exception (during marshalling, unmarshalling, in the client, in the object implementation, allocating network packets, ...), a single exception corresponding to dynamic memory allocation failure is de?ned. Each standard exception includes a minor code to designate the subcategory of the exception; the assignment of values to the minor codes is left to each ORB implementation. Each standard exception also includes a completion_status code which takes one of the values {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}. These have the following meanings:

COMPLETED_YES The object implementation has completed processing prior to the
exception being raised.

COMPLETED_NO The object implementation was never initiated prior to the exception being raised.

COMPLETED_MAYBE The status of implementation completion is indeterminate.

3.15.1 Standard Exceptions De?nitions
The standard exceptions are de?ned below.

3-34

CORBA V2.0

July 1995

3
#de?ne ex_body {unsigned long minor; completion_status completed;} enum completion_status {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}; enum exception_type {NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION}; exception UNKNOWN exception BAD_PARAM // the unknown exception // an invalid parameter was // passed exception NO_MEMORY ex_body; // dynamic memory allocation // failure exception IMP_LIMIT ex_body; // violated implementation limit exception COMM_FAILURE ex_body; // communication failure exception INV_OBJREF ex_body; // invalid object reference exception NO_PERMISSION ex_body; // no permission for attempted op. exception INTERNAL ex_body; // ORB internal error exception MARSHAL ex_body; // error marshalling param/result exception INITIALIZE ex_body; // ORB initialization failure exception NO_IMPLEMENT ex_body; // operation implementation // unavailable exception BAD_TYPECODE ex_body; // bad typecode exception BAD_OPERATION ex_body; // invalid operation exception NO_RESOURCES ex_body; // insuf?cient resources for req. exception NO_RESPONSE ex_body; // response to req. not yet // available exception PERSIST_STORE ex_body; // persistent storage failure exception BAD_INV_ORDER ex_body; // routine invocations out of order exception TRANSIENT ex_body; // transient failure - reissue // request exception FREE_MEM ex_body; // cannot free memory exception INV_IDENT ex_body; // invalid identi?er syntax exception INV_FLAG ex_body; // invalid ?ag was speci?ed exception INTF_REPOS ex_body; // error accessing interface // repository exception BAD_CONTEXT ex_body; // error processing context object exception OBJ_ADAPTER ex_body; // failure detected by object // adapter exception DATA_CONVERSION ex_body; // data conversion error exception OBJECT_NOT_EXIST ex_body; // non-existent object, delete // reference ex_body; ex_body;

3.15.2 Object Non-Existence
This standard system exception is raised whenever an invocation on a deleted object was performed. It is an authoritative “hard” fault report. Anyone receiving it is allowed (even expected) to delete all copies of this object reference and to perform other appropriate “?nal recovery” style procedures.

CORBA V2.0

Standard Exceptions

July 1995

3-35

3
Bridges forward this exception to clients, also destroying any records they may hold (for example, proxy objects used in reference translation). The clients could in turn purge any of their own data structures.

3-36

CORBA V2.0

July 1995

Dynamic Invocation Interface
4.1 Overview

4

The ORB Dynamic Invocation interface allows dynamic creation and invocation of requests to objects. A client using this interface to send a request to an object obtains the same semantics as a client using the operation stub generated from the type speci?cation. A request consists of an object reference, an operation, and a list of parameters. The ORB applies the implementation-hiding (encapsulation) principle to requests. In the Dynamic Invocation interface, parameters in a request are supplied as elements of a list. Each element is an instance of a NamedValue (see “Common Data Structures” on page 4-1). Each parameter is passed in its native data form. Parameters supplied to a request may be subject to run-time type checking upon request invocation. Parameters must be supplied in the same order as the parameters de?ned for the operation in the Interface Repository. All types de?ned in this chapter are part of the CORBA module. When referenced in OMG IDL, the type names must be pre?xed by “CORBA::”.

4.1.1 Common Data Structures
The type NamedValue is a well-known data type in OMG IDL. It can be used either as a parameter type directly or as a mechanism for describing arguments to a request. The type NVList is a pseudo-object useful for constructing parameter lists. The types are described in OMG IDL and C, respectively, as:

CORBA V2.0

July 1995

4-1

4
typedef unsigned long Flags; struct NamedValue { Identi?er name; // argument name any argument; // argument long len; // length/count of argument value Flags arg_modes;// argument mode ?ags }; CORBA_NamedValue * CORBA_NVList; /* C */

NamedValue and Flags are de?ned in the CORBA module.
The NamedValue and NVList structures are used in the request operations to describe arguments and return values. They are also used in the context object routines to pass lists of property names and values. Despite the above declaration for NVList, the NVList structure is partially opaque and may only be created by using the ORB create_list operation. A named value includes an argument name, argument value (as an any), length of the argument, and a set of argument mode ?ags. When named value structures are used to describe arguments to a request, the names are the argument identi?ers speci?ed in the OMG IDL de?nition for a speci?c operation. As described in Section 14.7, “Mapping for Basic Data Types,” on page 14-8, an any consists of a TypeCode and a pointer to the data value. The TypeCode is a wellknown opaque type that can encode a description of any type speci?able in OMG IDL. A full description of TypeCodes is Section 14.7, “Mapping for Basic Data Types,” on page 14-8. For most datatypes, len is the actual number of bytes that the value occupies. For object references, len is 1. TABLE 11. on page 4-2 shows the length of data values for the C language binding. The behavior of a NamedValue is unde?ned if the len value is inconsistent with the TypeCode.
TABLE 11. C

Type Lengths
Length (X) sizeof (CORBA_short) sizeof (CORBA_unsigned_short) sizeof (CORBA_long) sizeof (CORBA_unsigned_long) sizeof (CORBA_?oat) sizeof (CORBA_double) sizeof (CORBA_char) sizeof (char) sizeof (CORBA_octet) strlen (string) /* does NOT include ‘\0’ byte! */

Data type: X short unsigned short long unsigned long ?oat double char boolean octet string

4-2

CORBA V2.0

July 1995

4
TABLE 11. C

Type Lengths (Continued)
Length (X) sizeof (CORBA_enum) sizeof (U) sizeof (S) 1 Length (T1) * N Length (T2) * V /* V is the actual, dynamic, number of elements */

Data type: X enum E {}; union U { } ; struct S { }; Object array N of type T1 sequence V of type T2

The arg_modes ?eld is de?ned as a bitmask (long) and may contain the following ?ag values: CORBA::ARG_IN the associated value is an input only argument CORBA::ARG_OUT the associated value is an output only argument CORBA::ARG_INOUT the associated value is an in/out argument These ?ag values identify the parameter passing mode for arguments. Additional ?ag values have speci?c meanings for request and list routines, and are documented with their associated routines. All other bits are reserved. The high-order 16 bits are reserved for implementationspeci?c ?ags.

4.1.2 Memory Usage
The values for output argument data types that are unbounded strings or unbounded sequences are returned as pointers to dynamically allocated memory are shown in Table 21 . In order to facilitate the freeing of all “out-arg memory”, the request routines provide a mechanism for grouping, or keeping track of, this memory. If so speci?ed, out-arg memory is associated with the argument list passed to the create request routine. When the list is deleted the associated out-arg memory will automatically be freed. If the programmer chooses not to associate out-arg memory with an argument list, the programmer is responsible for freeing each out parameter using CORBA_free(), which is discussed in Section 14.17, “Argument Passing Considerations,” on page 14-17

4.1.3 Return Status and Exceptions
In the Dynamic Invocation interface, many routines return a Status result, which is intended as a status code. Status is de?ned in the CORBA modules as: typedef unsigned long Status;

CORBA V2.0

Overview

July 1995

4-3

4
Conforming CORBA implementations are not required to return this status code; instead, the de?nition typedef void Status; is a conforming implementation (in which case no status code result is returned, except in the usual inout Environment argument). Implementations are required to specify which Status behavior is supported.

4.2 Request Operations
The request operations are de?ned in terms of the Request pseudo-object. The Request routines use the NVList de?nition de?ned in the preceding section.

module CORBA { interface Request { Status add_arg ( in Identi?er in TypeCode in void in long in Flags ); Status invoke ( in Flags ); Status delete (); Status send ( in Flags ); Status get_response ( in Flags ); }; }; name, arg_type, * value, len, arg_?ags invoke_?ags // PIDL // argument name // argument datatype // argument value to be added // length/count of argument value // argument ?ags // invocation ?ags

invoke_?ags// invocation ?ags response_?ags // response ?ags

4.2.1 create_request
Because it creates a pseudo-object, this operation is de?ned in the Object interface (see “Object Reference Operations” on page 7-2 for the complete interface de?nition). The create_request operation is performed on the Object which is to be invoked.

4-4

CORBA V2.0

July 1995

4
Status create_request ( in Context ctx, in Identi?er operation, in NVList arg_list, inout NamedValue result, out Request request, in Flags req_?ags ); // PIDL // context object for operation // intended operation on object // args to operation // operation result // newly created request // request ?ags

This operation creates an ORB request. The actual invocation occurs by calling invoke or by using the send / get_response calls. The operation name speci?ed on create_request is the same operation identi?er that is speci?ed in the OMG IDL de?nition for this operation. In the case of attributes, it is the name as constructed following the rules speci?ed in the ServerRequest interface as described in the DSI in Section 5.2 The arg_list, if speci?ed, contains a list of arguments (input, output, and/or input/output) which become associated with the request. If arg_list is omitted (speci?ed as NULL), the arguments (if any) must be speci?ed using the add_arg call below. Arguments may be associated with a request by passing in an argument list or by using repetitive calls to add_arg. One mechanism or the other may be used for supplying arguments to a given request; a mixture of the two approaches is not supported. If speci?ed, the arg_list becomes associated with the request; until the invoke call has completed (or the request has been deleted), the ORB assumes that arg_list (and any values it points to) remains unchanged. When specifying an argument list, the value and len for each argument must be speci?ed. An argument’s datatype, name, and usage ?ags (i.e., in, out, inout) may also be speci?ed; if so indicated, arguments are validated for datatype, order, name, and usage correctness against the set of arguments expected for the indicated operation. An implementation of the request services may relax the order constraint (and allow arguments to be speci?ed out of order) by doing ordering based upon argument name. The context properties associated with the operation are passed to the object implementation. The object implementation may not modify the context information passed to it. The operation result is placed in the result argument after the invocation completes. The req_?ags argument is de?ned as a bitmask (long) that may contain the following ?ag values: CORBA::OUT_LIST_MEMORYIndicates that any out-arg memory is associated with the argument list (NVList). Setting the OUT_LIST_MEMORY ?ag controls the memory allocation mechanism for out-arg memory (output arguments, for which memory is dynamically allocated). If OUT_LIST_MEMORY is speci?ed, an argument list must also have been speci?ed on

CORBA V2.0

Request Operations

July 1995

4-5

4
the create_request call. When output arguments of this type are allocated, they are associated with the list structure. When the list structure is freed (see below), any associated out-arg memory is also freed. If OUT_LIST_MEMORY is not speci?ed, then each piece of out-arg memory remains available until the programmer explicitly frees it with procedures provided by the language mappings (See Section 14.17, “Argument Passing Considerations,” on page 14-17; Section 17.6, “NVList,” on page 17-6; and Section 20.19, “Argument Passing Considerations,” on page 20-11.)

4.2.2 add_arg
Status add_arg ( in Identi?er in TypeCode in void in long in Flags ); name, arg_type, * value, len, arg_?ags // PIDL // argument name // argument datatype // argument value to be added // length/count of argument value // argument ?ags

add_arg incrementally adds arguments to the request.
For each argument, minimally its value and len must be speci?ed. An argument’s datatype, name, and usage ?ags (i.e in, out, inout) may also be speci?ed. If so indicated, arguments are validated for datatype, order, name, and usage correctness against the set of arguments expected for the indicated operation. An implementation of the request services may relax the order constraint (and allow arguments to be speci?ed out of order) by doing ordering based upon argument name. The arguments added to the request become associated with the request and are assumed to be unchanged until the invoke has completed (or the request has been deleted). Arguments may be associated with a request by specifying them on the create_request call or by adding them via calls to add_arg. Using both methods for specifying arguments, for the same request, is not currently supported. In addition to the argument modes de?ned in Section 4.1.1, arg_?ags may also take the ?ag value:IN_COPY_VALUE. The argument passing ?ags de?ned in Section 4.1.1 may be used here to indicate the intended parameter passing mode of an argument. If the IN_COPY_VALUE ?ag is set, a copy of the argument value is made and used instead. This ?ag is ignored for inout and out arguments.

4-6

CORBA V2.0

July 1995

4
4.2.3 invoke
Status invoke ( in Flags ); // PIDL invoke_?ags // invocation ?ags

This operation calls the ORB, which performs method resolution and invokes an appropriate method. If the method returns successfully, its result is placed in the result argument speci?ed on create_request.

4.2.4 delete
Status delete ( ); // PIDL

This operation deletes the request. Any memory associated with the request (i.e. by using the IN_COPY_VALUE ?ag) is also freed.

4.3 Deferred Synchronous Operations
4.3.1 send
Status send ( in Flags ); // PIDL invoke_?ags // invocation ?ags

send initiates an operation according to the information in the Request. Unlike invoke, send returns control to the caller without waiting for the operation to ?nish. To determine when the operation is done, the caller must use the get_response or get_next_response operations described below. The out parameters and return
value must not be used until the operation is done. Although it is possible for some standard exceptions to be raised by the send operation, there is no guarantee that all possible errors will be detected. For example, if the object reference is not valid, send might detect it and raise an exception, or might return before the object reference is validated, in which case the exception will be raised when get_response is called. If the operation is de?ned to be oneway or if INV_NO_RESPONSE is speci?ed, then get_response does not need to be called. In such cases, some errors might go unreported, since if they are not detected before send returns there is no way to inform the caller of the error. The following invocation ?ags are currently de?ned for send: CORBA::INV_NO_RESPONSE Indicates that the invoker does not intend to wait for a response, nor does it expect any of the output arguments (in/out and out) to be updated. This option may be speci?ed even if the operation has n

赞助商链接
更多相关文档:

国际贸易中用到的单词

all other warra nties, express or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose. ...

保密协议(单位之间签订)

for such actions is received -1- by the Party that owns the object. Neither...S ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ...

DMN3009SFG替代型号AON7426_图文

BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION...

AOD240替代型号DMTH4004LK3

BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION...

Representations, Warranties and Undertakings

warranties, express or implied, including the implied warranties of merchantability, non-infringement, interoperability, and fitness for a particular purpose. 本...

c++ 编译器for aix的详细安装

implied warranties of merchantability and fitness for a particular purpose. The...0514-518 Cannot access the CuDv object class in the device ---configuration...

AON5802A替代型号DMG5802LFX

BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION...

AO4822A替代型号DMN3018SSD

BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION...

AO3401A替代型号DMG3401LSN

BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION...

AOD407替代型号DMP6180SK3_图文

BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION...

更多相关标签:
网站地图

文档资料共享网 nexoncn.com copyright ©right 2010-2020。
文档资料共享网内容来自网络,如有侵犯请联系客服。email:zhit325@126.com