ISO/IEC 19500-2:2003

INTERNATIONAL ISO/IEC
STANDARD 19500-2
First edition
2003-04-01
Information technology — Open
Distributed Processing —
Part 2:
General Inter-ORB Protocol
(GIOP)/Internet Inter-ORB Protocol (IIOP)
Technologies de l'information — Traitement réparti ouvert —
Partie 2: «General Inter-ORB Protocol (GIOP)/Internet Inter-ORB
Protocol (IIOP)»
Reference number
©
ISO/IEC 2003
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2003 — All rights reserved

1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Identical Recommendations | International Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Other Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Recommendations | International Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2 Other Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1 adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.2 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.3 client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.4 data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.5 domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.6 dynamic invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.7 dynamic skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.8 implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.9 interface repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.10 ORB core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.11 repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.12 request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.13 results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.14 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.15 signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.16 skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.17 synchronous request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.18 interface type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.19 interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.20 language binding or mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.21 method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.22 object adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.23 object implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.24 object reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.25 objref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.26 value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Introduction to GIOP/IIOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 ORB Interoperability Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2 Bridging Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
ª ISO/IEC 2003 - All rights reserved iii

5.2 ORBs and ORB Services 7
5.2.1 The Nature of ORB Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2 ORB Services and Object Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.3 Selection of ORB Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1 Definition of a Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.2 Mapping Between Domains: Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4 Interoperability Between ORBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4.1 ORB Services and Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4.2 ORBs and Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4.3 Interoperability Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4.4 Policy-Mediated Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.5 Configurations of Bridges in Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5 Object Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5.1 Domain-relative Object Referencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5.2 Handling of Referencing Between Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.6 An Information Model for Object References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
5.6.1  What Information Do Bridges Need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6.2 Interoperable Object References: IORs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6.3 Standard IOR Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.6.4 Profile and Component Composition in IORs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6.5 IOR Creation and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.6.6 Stringified Object References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.6.7 Object Service Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.7 Code Set Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.7.1 Character Processing Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.7.2 Code Set Conversion Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.7.3 Mapping to Generic Character Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.8 Example of Generic Environment Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.8.1 Generic Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.8.2 Interoperation and Generic Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.9 Relevant OSFM Registry Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.9.1 Character and Code Set Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
5.9.2 Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6 General Inter-ORB Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1 Goals of the General Inter-ORB Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.1 GIOP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.1.2 Common Data Representation (CDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
iv ª ISO/IEC 2003 - All rights reserved

6.1.3 GIOP Message Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.4 GIOP Message Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2 CDR Transfer Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.1 Primitive Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.2 OMG IDL Constructed Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.3 Value Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.4 Pseudo-Object Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.5 Object References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2.6 Abstract Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3 GIOP Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.1 GIOP Message Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3.2 Request Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3.3 Reply Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3.4 CancelRequest Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.5 LocateRequest Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.6 LocateReply Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.7 CloseConnection Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3.8 MessageError Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.9 Fragment Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4 GIOP Message Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4.1 Connection Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4.2 Message Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.5 Object Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.6 Internet Inter-ORB Protocol (IIOP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.6.1 TCP/IP Connection Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.6.2 IIOP IOR Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.6.3 IIOP IOR Profile Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.7 Bi-Directional GIOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.7.1 Bi-Directional IIOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.8 Bi-directional GIOP policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.9 OMG IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.9.1 GIOP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.9.2 IIOP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.9.3 BiDirPolicy Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
ª ISO/IEC 2003 - All rights reserved v

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 19500-2 was prepared by the Object Management Group (OMG) and was adopted, under the PAS
procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval
by national bodies of ISO and IEC.
ISO/IEC 19500 consists of the following parts, under the general title Information technology — Open
Distributed Processing:
 Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP)
NOTE Other parts will be added in the future.

vi © ISO/IEC 2003 — All rights reserved

Introduction
The rapid growth of distributed processing has lead to a need for a coordinating framework for the standardization of
Open Distributed Processing (ODP). ITU-T Recommendations X.901-904 | ISO/IEC 10746, the Reference Model of
Open Distributed Processing (RM-ODP) provides such a framework. It defines an architecture within which support
of distribution, interoperability and portability can be integrated.
Within the framework provided by the RM-ODP, ITU-T Rec. X.931 | ISO/IEC 14752, ODP - Protocol Support for
Computational Interactions, defines how interactions between computational objects in a computational specification
of a system relate to protocol support for those interactions in an engineering specification of that system.
Annex A to ITU-T Rec. X.931 | ISO/IEC 14752 defines a mapping to the General Inter-ORB Protocol (GIOP) and
the Internet Inter-ORB Protocol (IIOP) which are specified by this International Standard.
GIOP is the base for all interoperability and support for all object request broker (ORB) functionality in the Common
Object Request Broker Architecture (CORBA) specified by the Object Management Group (OMG). IIOP is the
mapping of GIOP for the Internet.
Note: This document is technically aligned with the OMG CORBA GIOP and IIOP specifications.
ª ISO/IEC 2003 - All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 19500-2:2003(E)
Information technology — Open Distributed Processing —
Part 2:
General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol
(IIOP)
1 Scope
This standard specifies the General Inter-ORB Protocol (GIOP) for object request broker (ORB) interoperability.
GIOP can be mapped onto any connection-oriented transport protocol that meets a minimal set of assumptions
defined by this standard.
This standard also defines the Internet Inter-ORB Protocol (IIOP), a specific mapping of the GIOP which runs
directly over connections that use the Internet Protocol and the Transmission Control Protocol (TCP/IP connections).
This standard provides a widely implemented and used particularization of ITU-T Rec. X.931 | ISO/IEC 14752, Information
technology — Open Distributed Processing — Protocol support for computational interactions. It supports interoperability
and location transparency in ODP systems.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
2.1 Identical Recommendations | International Standards
• ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Information technology — Open Distributed
Processing — Reference Model: Foundations
• ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Information technology — Open Distributed
Processing — Reference Model: Architecture
• ITU-T Recommendation X.920 (1997) | ISO/IEC 14750:1999, Information technology — Open Distributed
Processing — Interface Definition Language
• ISO/IEC 14752:2000, Information technology — Open Distributed Processing — Protocol support for
computational interactions
• ISO/IEC 8859-1: 1998, Information technology — 8-bit single-byte coded graphic character sets — Part 1:
Latin alphabet No. 1
• ISO/IEC 10646-1:2000, Information technology — Universal Multiple-Octect Coded Character Set (UCS) —
Part 1: Architecture and Basic Multilingual Plane
ª ISO/IEC 2003 - All rights reserved 1

2.2 Other Specifications
• CORBA 2.3 - The Common Object Request Broker: Architecture and Specification, Revision 2.3, Object
Management Group, June 1999 (OMG Doc Number: Formal/98-12-01, ftp://ftp.omg.org/pub/docs/for-
mal/98-12-01.pdf)
• CORBAservices: Common Object Services Specification, Object Management Group, December 1998
(OMG Doc Number: Formal/98-12-09, ftp://ftp.omg.org/pub/docs/formal/98-12-09.pdf)
TM
• Java to IDL Language Mapping, Object Management Group, July 1999 (OMG Doc Number:
Formal/99-07-59, ftp://ftp.omg.org/pub/docs/formal/99-07-59.pdf)
• STD 007 (also, RFC 793), Transmission Control Protocol, J. Postel, Internet Engineering Task Force, Sept.
• STD 005 (also, RFC 791), Internet Protocol, J. Postel, Internet Engineering Task Force, Sept. 1981
• OSF Character and Code Set Registry, OSF DCE FRC 40.1 (Public Version), S. (Martin) O’Donnell, June
1994.
• RPC Runtime Support For I18N Characters — Functional Specification, OSF DCE SIG RFC 41.2, M.
Romagna, R. Mackey, November 1994.
3 Definitions
For the purposes of this International Standard, the following definitions apply:
3.1 Recommendations | International Standards
This International Standard makes use of the following terms defined in ITU-T Rec. X.902 | ISO/IEC 10746-2:
behavior
interface
instance
object
state
type
This International Standard makes use of the following terms defined in ITU-T Rec. X.903 | ISO/IEC 10746-3:

operation
stub
2 ª ISO/IEC 2003 - All rights reserved

3.2 Other Specifications
3.2.1 adapter
Same as object adapter.
3.2.2 Attribute
An identifiable association between an object and a value. An attribute A is made visable to clients as a pair of
operations: get_A and set_A. Readonly attributes only generate a get operation.
3.2.3 client
The code or process that invokes an operation on an object.
3.2.4 data type
A categorization of values operation arguments, typically covering both behavior and representation (i.e., the
traditional no-OO programming language notion of type.)
3.2.5 domain
A concept important to interoperability, it is a distinct scope, within which common characteristics are exhibited,
common rules observed, and over which a distribution transparency is preserved.
3.2.6 dynamic invocation
Constructing and issuing a request whose signature is possibly not known until run-time.
3.2.7 dynamic skeleton
An interface-independent kind of skeleton, used by servers to handle requests whose signatures are possibly not
known until run-time.
3.2.8 implementation
A definition that provides the information needed to create an object and allow the object to participate in providing
an appropriate set of services. An implementation typically includes a description of the data structure used to
represent the core state associated with an object, as well as definitions of the methods that access that data structure.
It will also typically include information about the intended interface of the object.
3.2.9 interface repository
A storage place for interface information.
3.2.10 ORB core
The ORB component which moves a request from a client to the appropriate adapter for the target object.
ª ISO/IEC 2003 - All rights reserved 3

3.2.11 repository
See interface repository and implementation repository.
3.2.12 request
A client issues a request to cause a service to be perfomed. A request consists of an operation and zero or more actual
parameters.
3.2.13 results
The information returned to the client, which may include values as well as status information indicating that
exceptional conditions were raised in attempting to perform the requested service.
3.2.14 server
A process implementing one or more operations on one or more objects.
3.2.15 signature
Defines the parameters of a given operation including their number order, data types, and passing mode; the results if
any; and the possible outcomes (normal vs. exceptional) that might occur.
3.2.16 skeleton
The object-interface-specific ORB component which assists an object adapter in passing requests to particular
methods.
3.2.17 synchronous request
A request where the client pauses to wiat for completion of the request. Contrast with deferred synchronous request
and one-way request.
3.2.18 interface type
A type satisfied by any object that satisfies a particular interface.
3.2.19 interoperability
The ability for tow or more ORBs to cooperate to deliver requests to the proper object. Interoperating ORBs appear to
a client to be a single ORB.
3.2.20 language binding or mapping
The means and conventions by which a programmer writing in a specific programming language accesses ORB
capabilities.
3.2.21 method
An implementation of an operation. Code that may be executed to perform a requested service. Methods associated
with an object may be structured into one or more programs.
4 ª ISO/IEC 2003 - All rights reserved

3.2.22 object adapter
The ORB component which provides object reference, activation, and state related services to an object
implementation. There may be different adapters provided for different kinds of implementations.
3.2.23 object implementation
Same as implementation.
3.2.24 object reference
A value that unambiguously identifies an object. Object references are never reused to identify another object.
3.2.25 objref
An abbreviation for object reference.
3.2.26 value
Any entity that may be a possible actual parameter in a request. Values that serve to identify objects are called object
references.
3.3 Abbreviations
For the purposes of this International Standard, the following abbreviations apply:
ADT Abstract Data Type
CCCS Client Conversion Code Sets
CCS Conversion Code Sets
CDR Common Data Representation
CMIR Client Makes it Right
CNCS Client Native Code Set
CORBA Common Object Request Broker Architecture
DCE Distributed Computing Environment
OMG Object Management Group
GIOP General Inter-ORB Protocol
IDL Interface Definition Language
IIOP Internet Inter-ORB Protocol
IOR Interoperable Object Reference
ORB Object Request Broker
SCCS Server Conversion Code Sets
SMIR Server Makes It Right
ª ISO/IEC 2003 - All rights reserved 5

SNCS Server Native Code Set
TCS Transmission Code Set
TCS-C Char Transmission Code Set
TCS-W Wchar Transmission Code Set
VSCID Vender Service Context codeset ID
4 Introduction to GIOP/IIOP
This standard specifies the General Inter-ORB Protocol (GIOP) for object request broker (ORB) interoperability.
GIOP can be mapped onto any connection-oriented transport protocol that meets a minimal set of assumptions. This
standard also defines a specific mapping of the GIOP which runs directly over TCP/IP connections, called the
Internet Inter-ORB Protocol (IIOP). The IIOP must be supported by conforming networked ORB products regardless
of other aspects of its implementation. Such support does not require using it internally; conforming ORBs may also
provide bridges to this protocol.
A definition of interoperability material necessary for the protocol is in clause 5; the definition of GIOP/IIOP is in
clause 6. This standard is technically aligned with sections 13 and 15 of CORBA 2.3.
5 ORB Interoperability Architecture
For the purposes of this standard interoperability is defined as the ability for a client on ORB A to invode an IDL-
defined operation on an object on ORB B, where ORB A and ORB B are independently developed. It further
identifies general requirements including in particular:
• Ability for two vendors’ ORBs to interoperate without prior knowledge of each other’s implementations;
• Support of all ORB functionality;
• Preservation of content and semantics of ORB-specific information across ORB boundaries (for example,
security).
In effect, the requirement is for invocations between client and server objects to be independent of whether they are
on the same or different ORBs, and not to mandate fundamental modifications to existing ORB products.
5.1 Overview
5.1.1 Domains
The CORBA Object Model identifies various distribution transparencies that must be supported within a single ORB
environment, such as location transparency. Elements of ORB functionality often correspond directly to such
transparencies. Interoperability can be viewed as extending transparencies to span multiple ORBs.
In this architecture a domain is a distinct scope, within which certain common characteristics are exhibited and
common rules are observed over which a distribution transparency is preserved. Thus, interoperability is
fundamentally involved with transparently crossing such domain boundaries.
Domains tend to be either administrative or technological in nature, and need not correspond to the boundaries of an
ORB installation. Administrative domains include naming domains, trust groups, resource management domains and
other “run-time” characteristics of a system. Technology domains identify common protocols, syntaxes and similar
6 ª ISO/IEC 2003 - All rights reserved

“build-time” characteristics. In many cases, the need for technology domains derives from basic requirements of
administrative domains.
Within a single ORB, most domains are likely to have similar scope to that of the ORB itself: common object
references, network addresses, security mechanisms, and more. However, it is possible for there to be multiple
domains of the same type supported by a given ORB: internal representation on different machine types, or security
domains. Conversely, a domain may span several ORBs: similar network addresses may be used by different ORBs,
type identifiers may be shared.
5.1.2 Bridging Domains
The abstract architecture describes ORB interoperability in terms of the translation required when an object request
traverses domain boundaries. Conceptually, a mapping or bridging mechanism resides at the boundary between the
domains, transforming requests expressed in terms of one domain’s model into the model of the destination domain.
The concrete architecture identifies two approaches to inter-ORB bridging:
• At application level, allowing flexibility and portability.
• At ORB level, built into the ORB itself.
5.2 ORBs and ORB Services
The ORB Core is that part of the ORB which provides the basic representation of objects and the communication of
requests. The ORB Core therefore supports the minimum functionality to enable a client to invoke an operation on a
server object, with (some of) the distribution transparencies required by CORBA.
An object request may have implicit attributes which affect the way in which it is communicated - though not the way
in which a client makes the request. These attributes include security, transactional capabilities, recovery, and
replication. These features are provided by “ORB Services,” which will in some ORBs be layered as internal services
over the core, or in other cases be incorporated directly into an ORB’s core. It is an aim of this specification to allow
for new ORB Services to be defined in the future, without the need to modify or enhance this architecture.
Within a single ORB, ORB services required to communicate a request will be implemented and (implicitly) invoked
in a private manner. For interoperability between ORBs, the ORB services used in the ORBs, and the correspondence
between them, must be identified.
5.2.1 The Nature of ORB Services
ORB Services are invoked implicitly in the course of application-level interactions. ORB Services range from
fundamental mechanisms such as reference resolution and message encoding to advanced features such as support for
security, transactions, or replication.
An ORB Service is often related to a particular transparency. For example, message encoding – the marshaling and
unmarshaling of the components of a request into and out of message buffers – provides transparency of the
representation of the request. Similarly, reference resolution supports location transparency. Some transparencies,
such as security, are supported by a combination of ORB Services and Object Services while others, such as
replication, may involve interactions between ORB Services themselves.
ORB Services differ from Object Services in that they are positioned below the application and are invoked
transparently to the application code. However, many ORB Services include components which correspond to
conventional Object Services in that they are invoked explicitly by the application.
ª ISO/IEC 2003 - All rights reserved 7

Security is an example of service with both ORB Service and normal Object Service components, the ORB
components being those associated with transparently authenticating messages and controlling access to objects
while the necessary administration and management functions resemble conventional Object Services.
5.2.2 ORB Services and Object Requests
Interoperability between ORBs extends the scope of distribution transparencies and other request attributes to span
multiple ORBs. This requires the establishment of relationships between supporting ORB Services in the different
ORBs.
In order to discuss how the relationships between ORB Services are established, it is necessary to describe an abstract
view of how an operation invocation is communicated from client to server object.
1. The client generates an operation request, using a reference to the server object, explicit parameters, and an
implicit invocation context. This is processed by certain ORB Services on the client path.
2. On the server side, corresponding ORB Services process the incoming request, transforming it into a form
directly suitable for invoking the operation on the server object.
3. The server object performs the requested operation.
4. Any result of the operation is returned to the client in a similar manner.
The correspondence between client-side and server-side ORB Services need not be one-to-one and in some
circumstances may be far more complex. For example, if a client application requests an operation on a replicated
server, there may be multiple server-side ORB service instances, possibly interacting with each other.
In other cases, such as security, client-side or server-side ORB Services may interact with Object Services such as
authentication servers.
5.2.3 Selection of ORB Services
The ORB Services used are determined by:
• Static properties of both client and server objects; for example, whether a server is replicated.
• Dynamic attributes determined by a particular invocation context; for example, whether a request is trans-
actional.
• Administrative policies (e.g., security).
Within a single ORB, private mechanisms (and optimizations) can be used to establish which ORB Services are
required and how they are provided. Service selection might in general require negotiation to select protocols or
protocol options. The same is true between different ORBs: it is necessary to agree which ORB Services are used,
and how each transforms the request. Ultimately, these choices become manifest as one or more protocols between
the ORBs or as transformations of requests.
In principle, agreement on the use of each ORB Service can be independent of the others and, in appropriately
constructed ORBs, services could be layered in any order or in any grouping. This potentially allows applications to
specify selective transparencies according to their requirements, although at this time CORBA provides no way to
penetrate its transparencies.
A client ORB must be able to determine which ORB Services must be used in order to invoke operations on a server
object. Correspondingly, where a client requires dynamic attributes to be associated with specific invocations, or
administrative policies dictate, it must be possible to cause the appropriate ORB Services to be used on client and
8 ª ISO/IEC 2003 - All rights reserved

server sides of the invocation path. Where this is not possible - because, for example, one ORB does not support the
full set of services required - either the interaction cannot proceed or it can only do so with reduced facilities or
transparencies.
5.3 Domains
From a computational viewpoint, the OMG Object Model identifies various distribution transparencies which ensure
that client and server objects are presented with a uniform view of a heterogeneous distributed system. From an
engineering viewpoint, however, the system is not wholly uniform. There may be distinctions of location and
possibly many others such as processor architecture, networking mechanisms and data representations. Even when a
single ORB implementation is used throughout the system, local instances may represent distinct, possibly optimized
scopes for some aspects of ORB functionality.
Representation Representation
Reference Reference
Networking
Security
Figure 1 - Different Kinds of Domains can Coexist
Interoperability, by definition, introduces further distinctions, notably between the scopes associated with each ORB.
To describe both the requirements for interoperability and some of the solutions, this architecture introduces the
concept of domains to describe the scopes and their implications.
Informally, a domain is a set of objects sharing a common characteristic or abiding by common rules. It is a powerful
modelling concept which can simplify the analysis and description of complex systems. There may be many types of
domains (e.g., management domains, naming domains, language domains, and technology domains).
5.3.1 Definition of a Domain
Domains allow partitioning of systems into collections of components which have some characteristic in common. In
this architecture a domain is a scope in which a collection of objects, said to be members of the domain, is associated
with some common characteristic; any object for which the association does not exist, or is undefined, is not a
member of the domain. A domain can be modelled as an object and may be itself a member of other domains.
It is the scopes themselves and the object associations or bindings defined within them which characterize a domain.
This information is disjoint between domains. However, an object may be a member of several domains, of similar
kinds as well as of different kinds, and so the sets of members of domains may overlap.
The concept of a domain boundary is defined as the limit of the scope in which a particular characteristic is valid or
meaningful. When a characteristic in one domain is translated to an equivalent in another domain, it is convenient to
consider it as traversing the boundary between the two domains.
Domains are generally either administrative or technological in nature. Examples of domains related to ORB
interoperability issues are:
• Referencing domain – the scope of an object reference
• Representation domain – the scope of a message transfer syntax and protocol
ª ISO/IEC 2003 - All rights reserved 9

• Network addressing domain – the scope of a network address
• Network connectivity domain – the potential scope of a network message
• Security domain – the extent of a particular security policy
• Type domain – the scope of a particular type identifier
• Transaction domain – the scope of a given transaction service
Domains can be related in two ways: containment, where a domain is contained within another domain, and
federation, where two domains are joined in a manner agreed to and set up by their administrators.
5.3.2 Mapping Between Domains: Bridging
Interoperability between domains is only possible if there is a well-defined mapping between the behaviors of the
domains being joined. Conceptually, a mapping mechanism or bridge resides at the boundary between the domains,
transforming requests expressed in terms of one domain’s model into the model of the destination domain. Note that
the use of the term “bridge” in this context is conceptual and refers only to the functionality which performs the
required mappings between distinct domains. There are several implementation options for such bridges and these are
discussed elsewhere.
For full interoperability, it is essential that all the concepts used in one domain are transformable into concepts in
other domains with which interoperability is required, or that if the bridge mechanism filters such a concept out,
nothing is lost as far as the supported objects are concerned. In other words, one domain may support a superior
service to others, but such a superior functionality will not be available to an application system spanning those
domains.
A special case of this requirement is that the object models of the two domains need to be compatible. This
specification assumes that b
...