ISO/IEC 19500-2:2012

INTERNATIONAL ISO/IEC
STANDARD 19500-2
Second edition
2012-04-15
Information technology — Object
Management Group — Common Object
Request Broker Architecture (CORBA) —
Part 2:
Interoperability
Technologies de l'information — OMG (Object Management Group) —
CORBA (Common Object Request Broker Architecture) —
Partie 2: Interopérabilité
Reference number
©
ISO/IEC 2012
©  ISO/IEC 2012
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 2012 – All rights reserved

Table of Contents
Foreword .ix
Introduction .xi
1 Scope . 1
2 Conformance and Compliance . 1
2.1 Unreliable Multicast . 2
3 Normative References . 2
3.1 Other Specifications . 3
4 Terms and definitions . 3
4.1 Recommendations | International Standards. 4
4.2 Terms Defined in this Part of ISO/IEC 19500. 4
4.3 Keywords for Requirment statements . 5
5 Symbols (and abbreviated terms) . 6
6 Interoperability Overview . 7
6.1 General. 7
6.2 Elements of Interoperability . 7
6.2.1 ORB Interoperability Architecture .7
6.2.2 Inter-ORB Bridge Support .7
6.2.3 General Inter-ORB Protocol (GIOP) .8
6.2.4 Internet Inter-ORB Protocol (IIOP)® .8
6.2.5 Environment-Specific Inter-ORB Protocols (ESIOPs) .9
6.3 Relationship to Previous Versions of CORBA . 9
6.4 Examples of Interoperability Solutions . 10
6.4.1 Example 1 .10
6.4.2 Example 2 .10
© ISO/IEC 2012 - All rights reserved    iii

6.4.3 Example 3 .10
6.4.4 Interoperability Compliance .10
6.5 Motivating Factors . 13
6.5.1 ORB Implementation Diversity .13
6.5.2 ORB Boundaries .13
6.5.3 ORBs Vary in Scope, Distance, and Lifetime .13
6.6 Interoperability Design Goals. 14
6.6.1 Non-Goals .14
7 ORB Interoperability Architecture . 15
7.1 Overview. 15
7.1.1 Domains .15
7.1.2 Bridging Domains .15
7.2 ORBs and ORB Services. 16
7.2.1 The Nature of ORB Services .16
7.2.2 ORB Services and Object Requests .16
7.2.3 Selection of ORB Services .17
7.3 Domains. 17
7.3.1 Definition of a Domain .18
7.3.2 Mapping Between Domains: Bridging .19
7.4 Interoperability Between ORBs. 19
7.4.1 ORB Services and Domains .19
7.4.2 ORBs and Domains .20
7.4.3 Interoperability Approaches .20
7.4.4 Policy-Mediated Bridging .22
7.4.5 Configurations of Bridges in Networks .22
7.5 Object Addressing . 23
7.5.1 Domain-relative Object Referencing .24
7.5.2 Handling of Referencing Between Domains .24
7.6 An Information Model for Object References. 25
7.6.1 What Information Do Bridges Need? .25
7.6.2 Interoperable Object References: IORs .25
7.6.3 IOR Profiles .26
7.6.4 Standard IOR Profiles .28
7.6.5 IOR Components .29
7.6.6 Standard IOR Components .29
7.6.7 Profile and Component Composition in IORs .31
7.6.8 IOR Creation and Scope .32
7.6.9 Stringified Object References .32
iv © ISO/IEC 2012 - All rights reserved

7.6.10 Object URLs .33
7.7 Service Context . 37
7.7.1 Standard Service Contexts .38
7.7.2 Service Context Processing Rules .40
7.8 Coder/Decoder Interfaces . 40
7.8.1 Codec Interface .40
7.8.2 Codec Factory .42
7.9 Feature Support and GIOP Versions. 43
7.10 Code Set Conversion . 45
7.10.1 Character Processing Terminology .45
7.10.2 Code Set Conversion Framework .48
7.10.3 Mapping to Generic Character Environments .54
7.10.4 Example of Generic Environment Mapping .56
7.10.5 Relevant OSFM Registry Interfaces .56
8 Building Inter-ORB Bridges . 63
8.1 Introduction. 63
8.2 In-Line and Request-Level Bridging . 63
8.2.1 In-line Bridging .64
8.2.2 Request-level Bridging .64
8.2.3 Collocated ORBs .65
8.3 Proxy Creation and Management. 66
8.4 Interface-specific Bridges and Generic Bridges . 66
8.5 Building Generic Request-Level Bridges. 66
8.6 Bridging Non-Referencing Domains . 67
8.7 Bootstrapping Bridges . 68
9 General Inter-ORB Protocol . 69
9.1 Overview. 69
9.2 Goals of the General Inter-ORB Protocol . 69
9.3 GIOP Overview. 69
9.3.1 Common Data Representation (CDR) .70
9.3.2 GIOP Message Overview .70
9.3.3 GIOP Message Transfer .71
9.4 CDR Transfer Syntax . 71
© ISO/IEC 2012 - All rights reserved    v

9.4.1 Primitive Types .72
9.4.2 OMG IDL Constructed Types .77
9.4.3 Encapsulation .79
9.4.4 Value Types .80
9.4.5 Pseudo-Object Types .87
9.4.6 Object References .93
9.4.7 Abstract Interfaces .93
9.5 GIOP Message Formats. 93
9.5.1 GIOP Message Header .94
9.5.2 Request Message .96
9.5.3 Reply Message .99
9.5.4 CancelRequest Message .102
9.5.5 LocateRequest Message .103
9.5.6 LocateReply Message .104
9.5.7 CloseConnection Message .106
9.5.8 MessageError Message .106
9.5.9 Fragment Message .106
9.6 GIOP Message Transport. 107
9.6.1 Connection Management .108
9.6.2 Message Ordering .109
9.7 Object Location. 110
9.8 Internet Inter-ORB Protocol (IIOP). 111
9.8.1 TCP/IP Connection Usage .111
9.8.2 IIOP IOR Profiles .112
9.8.3 IIOP IOR Profile Components .114
9.9 Bi-Directional GIOP . 115
9.9.1 Bi-directional IIOP .117
9.10 Bi-directional GIOP policy. 118
9.11 OMG IDL. 118
9.11.1 GIOP Module .118
9.11.2 IIOP Module .123
9.11.3 BiDirPolicy Module .124
10 Secure Interoperability . 125
10.1 Overview. 125
10.1.1 Assumptions .126
10.2 Protocol Message Definitions . 127
10.2.1 The Security Attribute Service Context Element .127
vi © ISO/IEC 2012 - All rights reserved

10.2.2 SAS context_data Message Body Types .127
10.2.3 Authorization Token Format .132
10.2.4 Client Authentication Token Format .133
10.2.5 Identity Token Format .135
10.2.6 Principal Names and Distinguished Names .136
10.3 Security Attribute Service Protocol . 137
10.3.1 Compound Mechanisms .137
10.3.2 Session Semantics .141
10.3.3 TSS State Machine .143
10.3.4 CSS State Machine .146
10.3.5 ContextError Values and Exceptions .149
10.4 Transport Security Mechanisms . 150
10.4.1 Transport Layer Interoperability .150
10.4.2 Transport Mechanism Configuration .150
10.5 Interoperable Object References. 151
10.5.1 Target Security Configuration .151
10.5.2 Client-side Mechanism Selection .160
10.5.3 Client-Side Requirements and Location Binding .161
10.5.4 Server Side Consideration .162
10.6 Conformance Levels. 162
10.6.1 Conformance Level 0 .162
10.6.2 Conformance Level 1 .163
10.6.3 Conformance Level 2 .163
10.6.4 Stateful Conformance .164
10.7 Sample Message Flows and Scenarios . 164
10.7.1 Confidentiality, Trust in Server, and Trust in Client Established
in the Connection .165
10.7.2 Confidentiality and Trust in Server Established in the Connection -
Stateless Trust in Client Established in Service Context .167
10.7.3 Confidentiality, Trust in Server, and Trust in Client Established in
the Connection Stateless Trust Association Established in Service
Context .169
10.7.4 Confidentiality, Trust in Server, and Trust in Client Established in the
Connection - Stateless Forward Trust Association Established in
Service Context .172
10.8 References . 173
10.9 IDL . 174
10.9.1 Module GSSUP - Username/Password GSSAPI Token Formats .174
10.9.2 Module CSI - Common Secure Interoperability .175
10.9.3 Module CSIIOP - CSIv2 IOR Component Tag Definitions .179
© ISO/IEC 2012 - All rights reserved    vii

11 Unreliable Multicast Inter-ORB Protocol .183
11.1 Introduction. 183
11.1.1 Purpose .183
11.1.2 MIOP Packet .183
11.1.3 Packet Collection .183
11.1.4 PacketHeader .184
11.1.5 Joining an IP/Multicast Group .185
11.1.6 Quality Of Service .186
11.1.7 Delivery Requirements .186
11.2 MIOP Object Model . 186
11.2.1 Definition .186
11.2.2 Unreliable IP/Multicast Profile Body (UIPMC_ProfileBody) .187
11.2.3 Group IOR .188
11.2.4 Extending PortableServer::POA to include Group Operations .190
11.2.5 MIOP Gateway .194
11.2.6 Multicast Group Manager .194
11.2.7 MIOP URL .210
11.3 Request Issues. 211
11.3.1 GIOP Request Message Compatibility .211
11.3.2 MIOP Request Efficiency .211
11.3.3 Client Use Cases .212
11.3.4 Server Use Cases .213
11.4 Consolidated IDL . 213
11.4.1 OMG IDL .213
Annex A - Legal Information. 221
Annex B - Acknowledgements . 225
viii © ISO/IEC 2012 - All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has the right
to be represented on that committee. International organizations, governmental and non-governmental, in liaison with
ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all
matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the
technical committees are circulated to the member bodies for voting. Publication as an International Standard requires
approval by at least 75 % of the member 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
shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 19500-2 was prepared by Technical Committee ISO/IEC JTC1, Information technology, in collaboration with the
Object Management Group (OMG), following the submission and processing as a Publicly Available Specification (PAS)
of the OMG Common Object Request Broker Architecture (CORBA) specification Part 2 Version 3.1 CORBA
Interoperability.
ISO/IEC 19500-2 is related to:
• 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:1997, Information Technology - Open Distributed
Processing - Interface Definition Language
• ISO/IEC 19500-2, Information Technology - Open Distributed Processing - CORBA Specification Part 1:
CORBA Interfaces
• ISO/IEC 19500-3, Information Technology - Open Distributed Processing - CORBA Specification Part 3:
CORBA Components
ISO/IEC 19500 consists of the following parts, under the general title Information technology - Open distributed
processing - CORBA specification:
• Part 1: CORBA Interfaces
• Part 2: CORBA Interoperability
• Part 3: CORBA Components
© ISO/IEC 2012 - All rights reserved    ix

It is the common core of the CORBA specification. Optional parts of CORBA, such as mappings to particular
programming languages, Real-time CORBA extensions, and the minimum CORBA profile for embedded systems are
documented in the other specifications that together comprise the complete CORBA specification. Please visit the
CORBA download page at http://www.omg.org/technology/documents/corba_spec_catalog.htm to find the complete
CORBA specification set.
Apart from this Foreword, the text of this International Standard is identical with that for the OMG specification for
CORBA, v3.1.1, Part 2.
x © ISO/IEC 2012 - All rights reserved

ISO/IEC 19500-2:2012(E)
Introduction
The rapid growth of distributed processing has led to a need for a coordinating framework for this standardization and
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.
RM-ODP Part 2 (ISO/IEC 10746-2) defines the foundational concepts and modeling framework for describing distributed
systems. The scopes and objectives of the RM-ODP Part 2 and the UML, while related, are not the same and, in a number
of cases, the RM-ODP Part 2 and the UML specification use the same term for concepts which are related but not
identical (e.g., interface). Nevertheless, a specification using the Part 2 modeling concepts can be expressed using UML
with appropriate extensions (using stereotypes, tags, and constraints).
RM-ODP Part 3 (ISO/IEC 10746-3) specifies a generic architecture of open distributed systems, expressed using the
foundational concepts and framework defined in Part 2. Given the relation between UML as a modeling language and Part
3 of the RM-ODP standard, it is easy to show that UML is suitable as a notation for the individual viewpoint
specifications defined by the RM-ODP.
This International Standard for CORBA Interfaces is a standard for the technology specification of an ODP system. It
defines a technology to provide the infrastructure required to support functional distribution of an ODP system, specifying
functions required to manage physical distribution, communications, processing and storage, and the roles of different
technology objects in supporting those functions.
Context of CORBA
The key to understanding the structure of the CORBA architecture is the Reference Model, which consists of the
following components:
• Object Request Broker, which enables objects to transparently make and receive requests and responses in a
distributed environment. It is the foundation for building applications from distributed objects and for
interoperability between applications in hetero- and homogeneous environments. The architecture and
specifications of the Object Request Broker are described in this manual.
• Object Services, a collection of services (interfaces and objects) that support 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 defines conventions for creating, deleting, copying,
and moving objects; it does not dictate how the objects are implemented in an application. Specifications for
Object Services are contained in CORBAservices: Common Object Services Specification.
• Common Facilities, a collection of services that many applications may share, but which are not as fundamental
as the Object Services. For instance, a system management or electronic mail facility could be classified as a
common facility. Information about Common Facilities will be contained in CORBAfacilities: Common
Facilities Architecture.
• Application Objects, which are products of a single vendor on in-house development group that 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.
© ISO/IEC 2012 - All rights reserved    xi

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.
The architecture and specifications described in this standard are aimed at software designers and developers who want to
produce applications that comply with OMG specifications for the Object Request Broker (ORB), or this standard (ISO/
IEC 19500). The benefit of compliance is, in general, to be able to produce interoperable applications that are based on
distributed, interoperating objects. 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.
This Part of this International Standard includes a non-normative annex.
xii        © ISO/IEC 2012 - All rights reserved

INTERNATIONAL STANDARD                                           ISO/IEC 19500-2:2012(E)
Information technology - Object Management Group
Common Object Request Broker Architecture (CORBA), Interoperability
1Scope
This part of ISO/IEC 19500 specifies a comprehensive, flexible approach to supporting networks of objects that are
distributed across and managed by multiple, heterogeneous CORBA-compliant Object Request Brokers (ORBs). The
approach to inter-ORB operation is universal, because elements can be combined in many ways to satisfy a very broad
range of needs.
This part of ISO/IEC 19500 covers the specification of:
• ORB interoperability architecture
• Inter-ORB bridge support
• 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.
• 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).
• The CORBA Security Attribute Service (SAS) protocol and its use within the CSIv2 architecture to address the
requirements of CORBA security for interoperable authentication, delegation, and privileges.
This part of ISO/IEC 19500 provides a widely implemented and used particularization of ITU-T Rec. X.931 | ISO/IEC
14752. Open Distributed Processing - Protocol Support for Computational Interactions. It supports interoperability and
location transparency in ODP systems.
2 Conformance and Compliance
An ORB is considered to be interoperability-compliant when it meets the following requirements:
• In the CORBA Core part, standard APIs are provided by an ORB to enable the construction of request-level inter-ORB
bridges. APIs are defined by the Dynamic Invocation Interface, the Dynamic Skeleton Interface, and by the object
identity operations described in the Interface Repository clause of this book.
• An Internet Inter-ORB Protocol (IIOP) (explained in the Building Inter-ORB Bridges clause) defines a transfer syntax
and message formats (described independently as the General Inter-ORB Protocol), and defines how to transfer
messages via TCP/IP connections. The IIOP can be supported natively or via a halfbridge.
Support for additional Environment Specific Inter-ORB Protocols (ESIOPs) and other proprietary protocols is optional in
an interoperability-compliant system. However, any implementation that chooses to use the other protocols defined by the
CORBA interoperability specifications must adhere to those specifications to be compliant with CORBA interoperability.
Figure 6.2 on page 12 shows examples of interoperable ORB domains that are CORBA-compliant. These compliance
points support a range of interoperability solutions. For example, the standard APIs may be used to construct “half
bridge” to the IIOP, relying on another “half bridge” to connect to another ORB. The standard APIs also support
© ISO/IEC 2012 - All rights reserved       1

construction of “full bridges,” without using the Internet IOP to mediate between separated bridge components. ORBs
may also use the Internet IOP internally. In addition, ORBs may use GIOP messages to communicate over other network
protocol families (such as Novell or OSI), and provide transport-level bridges to the IIOP.
The GIOP is described separately from the IIOP to allow future specifications to treat it as an independent compliance
point.
2.1 Unreliable Multicast
Summary of Optional Verses Mandatory Interfaces
An interface to an MIOP gateway should be considered an optional interface within the MIOP specification.
Proposed Compliance Points
The MIOP specification is a single, optional compliance point within the CORBA Core specification.
Changes to Other OMG Specifications
This part of ISO/IEC 19500 contains an extension to the IOP module.
module IOP {
const ProfileId TAG_UIPMC = 3;
const ComponentId TAG_GROUP = 39;
const ComponnetId TAG_GROUP_IIOP = 40
};
3 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.
• ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Open Distributed Processing - Reference Model:
Foundations
• ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Open Distributed Processing - Reference Model:
Architecture
• ITU-T Recommendation X.920 (1999) | ISO/IEC 10750:1999, Open Distributed Processing - Interface Definition
Language
• ITU-T Recommendation X.931(2000) | ISO/IEC 14752:2000, 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:1993 Information Technology - Universal Multiple-Octect coded character set (UCS) - Part 1:
Architecture and Basic Multilingual Plane
2        © ISO/IEC 2012 - All rights reserved

• ISO/IEC 10646-1: 1993/Amd 1:1996 Transformation Format for 16 planes of group 00 (UTF - 16)
• ISO/IEC 10646-1: 1993/Amd 2:1996 UCS Transformation Format 8 (UTF - 8)
• ISO/IEC 19500-1: 2011 Open Distributed Processing - CORBA Specification Part 1: CORBA Interfaces,
pas/2011-08-07
3.1 Other Specifications
• STD 007 (also, RFC 793), Transmission Control Protocol, J. Postel, Internet Engineering Task Force, Sept. 1981
• 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.
• [JAV2I]Object Management Group, “Java to IDL,” available from http://www.omg.org/spec/JAV2I/1.4
• [CORBASEC]Object Management Group, “Security Service,” available from http://www.omg.org/spec/SEC/
• [ASMOTS]Object Management Group, “Additional Structuring Mechanisms for the OTS,” available from http://
www.omg.org/spec/OTS/
• [TRANS]Object Management Group, “Transaction Service,” available from http://www.omg.org/spec/TRANS/
• [FIREWALL]Object Management Group, “CORBA Firewall Traversal Specification,” available from http://
www.omg.org/members/cgi-bin/doc?ptc/04-04-05.pdf
• [SCCP] Object Management Group, “CORBA / TC Interworking and SCCP-Inter ORB Protocol (SCCP),” available
from http://www.omg.org/spec/SCCP
• [FTCORBA] Object Management Group, “Fault Tolerant Corba,” clause 23 of CORBA 3.0.3, available from http://
www.omg.org/cgi-bin/doc?formal/2004-03-01
• [RTCORBA] Object Management Group, “Real-Time CORBA, version 1.2,” available from http://www.omg.org/
spec/RT/
• [WATM] Object Management Group, “Wireless Access and Telecom Mobility in CORBA, Version 1.2,” available
from http://www.omg.org/spec/WATM/
• [DCOMI] Object Management Group, “Interoperability with non-CORBA Systems” clause 20 of CORBA 3.0.3,
available from http://www.omg.org/cgi-bin/doc?formal/2004-03-01
• [TSAS] Object Management Group, “Telecommunications Service Access and Subscription Specification,” available
from http://www.omg.org/spec/TSAS/
• IETF RFC2119, “Key words for use in RFCs to Indicate Requirement Levels,” S. Bradner, March 1997 (http://ietf.org/
rfc/rfc2119)
© ISO/IEC 2012 - All rights reserved    3

4 Terms and Definitions
For the purposes of this document, the following terms and definitions apply.
4.1 Recommendations | International Standards
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.902 | ISO/IEC
10746-2:
• behavior
• interface
• instance
• object
• service
• state
• transparency
• type
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.903 | ISO/IEC
10746-3:
• operation
• stub
4.2 Terms Defined in this Part of ISO/IEC 19500
adapter Same as object adapter.
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.
client The code or process that invokes an operation on an object.
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.)
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.
dynamic invocation Constructing and issuing a request whose signature is possibly not known until run-time.
dynamic skeleton An interface-independent kind of skeleton, used by servers to handle requests whose
signatures are possibly not known until run-time.
4        © ISO/IEC 2012 - All rights reserved

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.
interface repository A storage place for interface information.
interface type A type satisfied by any object that satisfies a particular interface.
interoperability The ability for two or more ORBs to cooperate to deliver requests to the proper object.
Interoperating ORBs appear to a client to be a single ORB.
language binding or The means and conventions by which a programmer writing in a specific programming
mapping language accesses ORB capabilities.
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.
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.
object implementation Same as implementation.
object reference A value that unambiguously identifies an object. Object references are never reused to
identify another object.
objref An abbreviation for object reference
ORB core The ORB component which moves a request from a client to the appropriate adapter
for the target object.
request A message issued by a client to cause a service to be performed.
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.
server A process implementing one or more operations on one or more objects.
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.
skeleton The object-interface-specific ORB component which assists an object adapter in passing
requests to particular methods.
synchronous request A request where the client pauses to wait for completion of the request. Contrast with
deferred synchronous request and one-way request.
value Any entity that may be a possible actual parameter in a request. Values that serve to
identify objects are called object references.
4.3 Keywords for Requirment statements
The keywords “must,” “must not,” “shall,” “shall not,” “should,” “should not,” and “may” in this International Standard
are to be interpreted as described in IETF RFC 2119.
© ISO/IEC 2012 - All rights reserved    5

5 Symbols (and abbreviated terms)
For the purposes of this International Standard, the following abbreviations apply:
ADT Abstract Data Type
CSIv2 Common Secure Interoperability, version 2
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
ESIOP Environment Specific Inter-ORB Protocol
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
SAS Security Attribute Service
SCCS Server Conversion Code Sets
SMIR Server Makes It Right
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
6        © ISO/IEC 2012 - All rights reserved

6 Interoperability Overview
6.1 General
ORB interoperability specifies a comprehensive, flexible approach to supporting networks of objects that are distributed
across and managed by multiple, heterogeneous CORBA-compliant ORBs. The approach to “interORBability” is
universal because its elements can be combined in many ways to satisfy a very broad range of needs.
6.2 Elements of Interoperability
The elements of interoperability are as follows:
• ORB interoperability architecture
• Inter-ORB bridge support
• General and Internet Inter-ORB Protocols (GIOPs and IIOPs)
In addition, the architecture accommodates Environment Specific Inter-ORB Protocols (ESIOPs) that are optimized for
particular environments such as DCE.
6.2.1 ORB Interoperability Architecture
The ORB Interoperability Architecture provides a conceptual framework for defining the elements of interoperability and
for identifying its compliance points. It also characterizes new mechanisms and specifies conventions necessary to
achieve interoperability between independently produced ORBs.
Specifically, the architecture introduces the concepts of immediate and mediated bridging of ORB domains. The Internet
Inter-ORB Protocol (IIOP) forms the common basis for broad-scope mediated bridging. The inter-ORB bridge support
can be used to implement both immediate bridges and to build “half-bridges” to mediated bridge domains.
By use of bridging techniques, ORBs can interoperate without knowing any details of that ORB’s implementation, such
as what particular IPC
...