Final Report (NKS)

8/2/2019 Final Report (NKS)

1/25

1

ABSTRACT

The Common Object Request Broker Architecture (CORBA) is a standard developed by the

Object Management Group (OMG) to provide interoperability among distributed objects.CORBA is the world's leading middleware solution enabling the exchange of information,

independent of hardware platforms, programming languages, and operating systems. CORBA

is essentially a design specification for an Object Request Broker (ORB), where an ORB

provides the mechanism required for distributed objects to communicate with one another,

whether locally or on remote devices, written in different languages, or at different locations

on a network.The CORBA Interface Definition Language, or IDL, allows the development of

language and location-independent interfaces to distributed objects. Using CORBA,

application components can communicate with one another no matter where they are located,

or who has designed them. CORBA provides the location transparency to be able to execute

these applications.CORBA is often described as a "software bus" because it is a software-

based communications interface through which objects are located and accessed.A

cornerstone of the CORBA standards is the Interface Definition Language. IDL is the OMG

standard for defining language-neutral APIs and provides the platform-independent

delineation of the interfaces of distributed objects. The ability of the CORBA environments

to provide consistency between clients and servers in heterogeneous environments begins

with a standardized definition of the data and operations constituting the client/server

interface. This standardization mechanism is the IDL, and is used by CORBA to describe the

interfaces of objects. IDL defines the modules, interfaces and operations for the applications

and is not considered a programming language. The various programming languages, such as

Ada, C++, or Java, supply the implementation of the interface via standardized IDL

mappings.

The basic steps for CORBA development can be seen in the illustration below. This

illustration provides an overview of how the IDL is translated to the corresponding language

(in this example, C++), mapped to the source code, compiled, and then linked with the ORB

library, resulting in the client and server implementation.


2/25

2

Chapter 1

Introduction

This chapter provides an inside view of CORBA with details of its different elements such as

the CORBA reference object model and the Object Management Architecture (OMA). It also

goes into details on some of the major elements of the CORBA architecture: Object Request

Broker (ORB), Interface Definition Language (IDL), Interface and Implementation

Repositories, and object adaptors. We show how object binding works in CORBA

environments, and this is done by using either transient or persistent object references. At the

end of the chapter, the CORBA technologies are compared with related technologies (e.g.,

DCE, DCOM and RMI).

The explosion of growth in the computing industry has developed an increasingly

pronounced need for the sharing of computing resources. The days where we had a stand-alone desktop, the use of which depends on the local applications installed are gone, and

distributed computing is here. Users want access to information stored in remote systems, and

mechanisms which allow this facility are becoming prolific. CORBA, an acronym for

Common Object Request Broker Architecture, is a standard adopted by the OMG (Object

Management Group) to enable interoperability between applications in heterogeneous

distributed environments, without regard for where they are located. Other solutions to the

distributed integration problem are Microsofts DCOM (Distributed Component Object

Model), and DCE (Distributed Computing Environment). This book focuses on the technical

details of CORBA technology because it provides open communication between different

systems and does this in a standard manner. We believe that this standard may help vendors,

developers and researchers in providing acceptable solutions to the problems related to

software interoperability. This is the main reason for choosing to describe CORBA and

explaining in more technical detail the issues and solutions related to this technology. OMG

is a group of vendors who jointly developed a common way to interact with distributed

objects. The group was founded in April 1989 by twelve commercial vendors: IBM, BNR

Europe Ltd., Expersoft Corp., ICL plc., Iona Technologies Ltd., DEC, Hewlett-Packard,

Hyper Desk Corp., NCR, Novell USG, Object Design Inc., and SunSoft. Since its formation,

the OMG has grown to more than 600 members whose goal is to provide a common

architectural framework, across heterogeneous hardware platforms and operating systems, forinter-communication of application objects. For that, they released specifications for the

Common Object Request Broker Architecture (CORBA) [70] and other related technologies.

The CORBA architecture is to be vendor, platform and language neutral. The Interface

Definition Language (IDL), as the specification language for the interfaces of objects, is the

glue. CORBA is an open distributed object computing infrastructure. Its objective is to

automate many common network programming tasks such as object registration, location,

and activation; request demultiplexing; framing and error-handling; parameter marshalling

and un-marshalling; and operation dispatching. This automation of what are usually

networking functions is done with a software intermediary called the Object Request Broker(ORB). It sits on the host between the data and the application layer (i.e., one level lower than


3/25

3

the application layerlevel 7 in the OSI model) and it handles, in a transparent manner,

request messages from clients (which can be user or server objects) and servers (i.e.,

implementations which provide specific services). The first implementations of the ORBs

under the CORBA 1 specifications were not concerned with representing objects in a

meaningful way outside of the boundary of the ORB. The CORBA 2 specifications addressinteroperability at a higher level, that is, object representation across the boundaries of ORBs.

By implementing interoperability, the boundaries of a given ORB need not limit the scope of

an application. The CORBA paradigm is based on a combination of two existing

methodologies. The first, distributed clientserver computing is based in part on message-

passing systems most commonly found in UNIX-based environments. The second

methodology is object-oriented programming. An ORB plays the role of an object-oriented

remote procedure call (RPC) application program interface. It provides common services,

such as basic messaging and an RPC-type communication between clients and servers,

directory services, meta-description, and location and host transparency. CORBA is based ona peer-to-peer communication model and supports both asynchronous and a limited version

of asynchronous communications. Location transparency refers to the fact that clients do not

need to be aware of where the servers are located. ORBs are responsible for finding these

servers, based on information contained within client requests (such as references). Host

transparency is maintained within CORBA where ORBs can access and make calls to

different CORBA objects on various machines. If a client application (process) is running on

one host, then that hosts ORB is able to locate data in a different place on that host or on a

different machine altogether. This is achieved largely through the different repositories (e.g.,

interface and implementation repositories) and the information contained within object

references. The presence of object-orientedmethodology in CORBA is the result of necessity,

not of choice. Object-oriented programming is merely a different, convenient way to explain

and develop a program, and the adoption of an object-oriented approach is motivated by the

desire for software development with reusable components that interact with one another

through well-defined interfaces. In CORBA, three basic features of object-oriented

programming are used. First, polymorphism among objects is allowed. The ORB makes

different (interface of) objects and their associated implementations independent and reusable

by different applications. Second, encapsulation is utilized. Each client application knows

nothing about the implementation it accesses; it merely makes requests of the respective

objects through the ORB, and the object retrieves the data for the application. Third, data

inheritance is provided. If one description of an object is designed to interface with an ORB,

any object derived from that parent object will preserve its parents interface. A CORBA

object has an interface and an implementation. The interface is not bound to a specific

implementation programming language, but is instead written in a special-purpose Interface

Definition Language (IDL), which, in turn, translates to different constructs in the different

implementation languages via language mappings. This makes it possible to call an object

implementation written in a given language (e.g., COBOL) from a client program written in

another language (e.g., Smalltalk). As per the CORBA 2.0 standard, the ORBs from different

vendors are able to interoperate, because the CORBA 2.0 specifies the protocols that shouldbe used for ORB-to-ORB communication. The most common CORBA protocol is the IIOP


4/25

4

(Internet Inter-ORB Protocol) which is a specialized version of GIOP (General Inter-ORB

Protocol).In summary; CORBA provides several advantages over existing distributed

systems. From the software development point of view, developers can use CORBA to

distribute applications across clientserver networks. Instead of having hundreds of

thousands of lines of code running on computers with dumb terminals, smaller, more robustapplications that communicate between file servers and workstations are now necessary.

CORBA keeps the distribution of applications simple; a plug-and play architecture is used to

distribute the clientserver applications. The programmer then can write applications that

work independently across platforms and networks. CORBA also enables integration of

different software applications without a need to rely on low-level communication facilities.

Other benefits of CORBA are:

It interworks well with different middlewares, including Microsoft distributed system(DCOM).

The CORBA Services provide a set of optional extensions that address areas that thecore itself cannot address: for example, transactions, naming, events, and trading. It is

integrated with other technologies, such as databases, reliable messaging systems,

threads, and user interface generation systems.

It applies to many different vertical markets. The core level is applicable to all ofthese, and specialized implementations can be provided in areas such as real time and

embedded systems. The upper layers, both the CORBA services and the CORBA

facilities, can be applied differently in the various vertical markets. The OMG has set

up a number of active special interest groups to address these special needs.

It supports both static and dynamic usage. The dynamic parts are more difficult, butthey need to be used only by a subset of CORBA programmers.

IDL is mapped separately to each programming language, so usage of each languageis natural; for example, in object-oriented languages the normal steps for

implementing and using classes still apply.

There is an agreed protocol in phase, IIOP, for facilitating communication betweenORBs. It is a well-established and widely adopted standard that is written and

maintained by an open procedure.


5/25

5

Chapter 2

Object Model

2.1 Overview

The object model provides an organized presentation of object concepts and terminology. It

defines a partial model for computation that embodies the key characteristics of objects as

realized by the submitted technologies. The OMG object model is abstract in that it is not

directly realized by any particular technology. The model described here is a concreteobject

model. A concrete object model may differ from the abstract object model in several ways:

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

It may populatethe model by introducing specific instances of entities defined by themodel, for example, specific objects, specific operations, or specific types. It may restrict the model by eliminating entities or placing additional restrictions on

their use.

An object system is a collection of objects that isolates the requestors of services (clients)

from the providers of services by a well-defined encapsulating interface. In particular, clients

are isolated from the implementations of services as data representations and executable

code. The object model first describes concepts that are meaningful to clients, including such

concepts as object creation and identity, requests and operations, types and signatures. It then

describes concepts related to object implementations, including such concepts as methods,

execution engines, and activation. The object model is most specific and prescriptive in

defining concepts meaningful to clients. The discussion of object implementation is moresuggestive, with the intent of allowing maximal freedom for different object technologies to

provide different ways of implementing objects. There are some other characteristics of

object systems that are outside the scope of the object model. Some of these concepts are

aspects of application architecture; some are associated with specific domains to which object

technology is applied. Such concepts are more properly dealt with in an architectural

reference model. Examples of excluded concepts are compound objects, links, copying of

objects, change management, and transactions. Also outside the scope of the object model are

the details of control structure: the object model does not say whether clients and/or servers

are single threaded or multi-threaded, and does not specify how event loops are programmed

nor how threads are created, destroyed, or synchronized. This object model is an example of a

classical object model, where a client sends a message to an object. Conceptually, the object

interprets the message to decide what service to perform. In the classical model, a message

identifies an object and zero or more actual parameters. As in most classical object models, a

distinguished first parameter is required, which identifies the operation to be performed; the

interpretation of the message by the object involves selecting a method based on the specified

operation. Operationally, of course, method selection could be performed either by the object

or the ORB.

2.2 Object Semantics


6/25

6

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

requesting the service. This section defines the concepts associated with object semantics,

that is, the concepts relevant to clients.

Objects

An object system includes entities known as objects. An objectis an identifiable, ncapsulated

entity that provides one or more services that can be requested by a client.

Requests

Clients request services by issuing requests. The term requestis broadly used to refer to the

entire sequence of causally related events that transpires between a client initiating it and the

last event causally associated with that initiation. For example:

the client receives the final response associated with that requestfrom the server, the server carries out the associated operation in case of a one-way request, or the sequence of events associated with the requestterminates in a failure of some sort.

The initiation of a Request is an event.

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 formis 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 defined by

particular language bindings. An alternative request form consists of calls to the dynamic

invocation interface to create an invocation structure, add arguments to the invocation

structure, and to issue the invocation (refer to 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. More particularly, a value is an instance of an OMG IDL data type.There are non-object values, as well as values that reference objects. An object reference is a

value that reliably denotes a particular object. Specifically, an object reference will identify

the same object each time the reference is used in a request (subject to certain pragmatic

limits of space and time). An object may be denoted by multiple, distinct object references. A

request may have parameters that are used to pass data to the target object; it may also have a

request context that provides additional information about the request. A request context is a

mapping from strings to strings. A request causes a service to be performed on behalf of the

client. One possible outcome of performing a service is returning to the client the results, if

any, defined for the request. If an abnormal condition occurs during the performance of a

request, an exception isreturned. The exception may carry additional return parameters

particular to that exception. The request parameters are identified by position. A parametermay be an input parameter, an output parameter, or an input-output parameter. A request may

also return a single return result value, as well as the results stored into the output and input-

output parameters. The following semantics hold for all requests:

Any aliasing of parameter values is neither guaranteed removed nor guaranteed to bepreserved.

The order in which aliased output parameters are written is not guaranteed. The return result and the values stored into the output and input-output parameters are

undefined if an exception is returned.


7/25

7

Object Creation and Destruction

Objects can be created and destroyed. From a clients 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.

Types

A type is an identifiable entity with an associated predicate (a single-argument mathematical

function with a boolean result) defined over entities. An entity satisfies a type if the predicate

is true for that entity. An entity that satisfies a type is called a member of the type. Types are

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

extension of a type is the set of entities that satisfy the type at any particular time. An object

type is a type whose members are object references. In other words, an object type is satisfied

only by object references. Constraints on the data types in this model are shown in this

section.

Basic types

16-bit, 32-bit, and 64-bit signed and unsigned 2s complement integers. Single-precision (32-bit), double-precision (64-bit), and double-extended (a mantissa

of at least 64 bits, a sign bit and an exponent of at least 15 bits) IEEE floating point

numbers.

Fixed-point decimal numbers of up to 31 significant digits.

Characters, as defined in ISO Latin-1 (8859.1) and other single- or multi-bytecharacter sets.

A Boolean type taking the values TRUE and FALSE. An 8-bit opaque detectable, guaranteed to not undergo any conversion during transfer

between systems.

Enumerated types consisting of ordered sequences of identifiers.Constructed types

A record type (called struct), which consists of an ordered set of (name, value) pairs.

A discriminated union type, which consists of a discriminator (whose exact value isalways available) 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 lengthof the sequence is available at run-time.

An array type, which consists of a fixed-shape multidimensional array of a singletype.

An interface type, which specifies the set of operations that an instance of that typemust support.

A value type, which specifies state as well as a set of operations that an instance ofthat type must support.

Entities in a request are restricted to values that satisfy these type constraints. The legalentities are shown in. No particular representation for entities is defined.


8/25

8

Figure 1-1 Legal Values

Interfaces

An interface is a description of a set of possible operations that a client may request of anobject, through that interface. It provides a syntactic description of how a service provided by

an object supporting this interface, is accessed via this set of operations. An object satisfies

an interface if it provides its service through the operations of the interface according to the

specification of the operations.

The interface typefor a given interface is an object type, such that an object reference will

satisfy the type, if and only if the referent object also satisfies the interface. Interfaces are

specified in OMG IDL. Interface inheritance provides the composition mechanism for

permitting an object to support multiple interfaces. The principalinterfaceis simply the most-

specific interface that the object supports, and consists of all operations in the transitive

closure of the interface inheritance graph. Interfaces satisfy the Liskov substitution principle.

If interface A is derived from interface B, then a reference to an object that supports interface

A can be used where the formal type of a parameter is declared to be B.

Value Types

A value typeis an entity, which shares many of the characteristics of interfaces and structs. It

is a description of both a set of operations that a client may request and of state that is

accessible to a client. Instances of a value type are always local concrete implementations in

some programming language.A value type, in addition to the operations and state defined for

itself, may also inherit from other value types, and through multiple inheritance support other

interfaces. Value types are specified in OMG IDL. An abstract value typesdescribes a valuetype that is a pure bundle of operations with no state.


9/25

9

Abstract Interfaces

An abstract interface is an entity, which may at runtime represent either a regular interface

(see Section 1.2.5, Interfaces, on page 1-6) or a value type (see Section 1.2.6, Value

Types, on page 1-6). Like an abstract value type, it is a pure bundle of operations with no

state. Unlike an abstract value type, it does not imply pass-by-value semantics, and unlike aregular interface type, it does not imply pass-by reference semantics. Instead, the entity's

runtime type determines which of these semantics are used.

Operations

An operation is an identifiable entity that denotes the indivisible primitive of service

provision that can be requested. The act of requesting an operation is referred to as invoking

the operation. An operation is identified by an operation identifier. An operation has a

signature that describes the legitimate values of request parameters and returned results. In

particular, a signatureconsists of:

A specification of the parameters required in requests for that operation. A specification of the result of the operation. An identification of the user exceptions that may be raised by an invocation of the

operation.

A specification of additional contextual information that may affect the invocation. An indication of the execution semantics the client should expect from an invocation

of the operation.

Operations are (potentially) generic, meaning that a single operation can be uniformly

invoked on objects with different implementations, possibly resulting in observably different

behavior. Genericity is achieved in this model via interface inheritance in IDL and the total

decoupling of implementation from interface specification. The general form for an operationsignature is:

[oneway] (param1, ..., paramL)

[raises(except1,...,exceptN)] [context(name1, ..., nameM)]where:

The optional oneway keyword indicates that best-effort semantics are expected ofrequests 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 is the type of the return result. The provides a name for the operation in the interface. The operation parameters needed for the operation; they are flagged with the

modifiers in, out, or inout to indicate the direction in which the information flows(with respect to the object performing the request).

The optional raises expression indicates which user-defined exceptions can besignaled to terminate an invocation of this operation; if such an expression is not

provided, no user-defined exceptions will be signaled.

The optional context expression indicates which request context information will beavailable to the object implementation; no other contextual information is required to

be transported with the request.

ParametersA 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


10/25

10

parameters type constrains the possible value, which may be passed in the directions dictated

by the mode.

Return ResultThe return result is a distinguished out parameter.

Exceptions

An exception is an indication that an operation request was not performed successfully. Anexception may be accompanied by additional, exception-specific information. The additional,

exception-specific 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 system exceptions; the standard system exceptions are

described in Section 4.12.2, System Exceptions, on page 4-64. 1.2.8.4 Contexts A request

context provides additional, operation-specific information that may affect the performance

of a request.

Execution SemanticsTwo styles of execution semantics are defined by the object model:

At-most-once: if an operation request returns successfully, it was performed exactlyonce; 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 returnany 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.

Attributes

An interface may have attributes. An attribute is logically equivalent to declaring a pair of

accessor functions: one to retrieve the value of the attribute and one to set the value of the

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

defined.


11/25

11

Chapter 3

CORBA ARCHITECTURE

The OMGs Object Management Architecture (OMA) tries to define the various high-level

facilities that are necessary for distributed object-oriented computing. The core of the OMA

is the Object Request Broker (ORB), a mechanism that provides object location transparency,

communication, and activation. Based on the OMA, the CORBA specification which

provides a description of the interfaces and facilities that must be provided by compliant

ORBs was released. CORBA is composed of five major components: ORB, IDL, dynamic

invocation interface (DII), interface repositories (IR), and object adapters (OA). These are

discussed in the following sections.

3.1 The object request broker

The CORBA specification must have software to implement it. The software that implements

the CORBA specification is called the ORB. The ORB, which is the heart of CORBA, is

responsible for all the mechanisms equired to perform these tasks:

Find the object implementation for the request.

Figure 3.1 The structure of the CORBA 2.0 ORB

Prepare the object implementation to receive the request. Communicate the data making up the request.A number of implementations exist in the market today, including ORBIX from

ONA Technologies (http://www.iona.ie), VisiBroker from Inprise

(http://www.inprise.com), and JavaIDL from JavaSoft(http://java.sun.com/products/jdk.idl). Throughout this part of the book, we will use


12/25

12

the VisiBroker ORB for Java, version 3.1. Figure 3.1 shows how the five major

components of CORBA fit together.

Figure 11.2 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 implementation is

the actual code and data that implements the object. Note that in this figure, the client, ORB,

and object implementation are all on a single machine (meaning theyre not separated by anetwork). There are two important things to note about the CORBA architecture and its

computing model:

Both the client and the object implementation are isolated from the ORB by an IDLinterface.

Figure 3.2 A request from a client to an object implementation

All requests are managed by the ORB. This means that every invocation (whether it islocal or remote) of a CORBA object is passed to an ORB. In the case of a remote

invocation, however, the invocation passed from the ORB of the client to the ORB of

the object implementation as shown in figure 3.3.

3.2 Different vendors and different ORBs

Since there is more than one CORBA implementation, and these implementations are from

different vendors, a good question at this point would be whether objects implemented in

different ORBs from different vendors would be able to communicate with each other. The

answer is this: all CORBA 2.0 (and above) compliant ORBs are able to interoperate via theInternet Inter-ORB Protocol, or IIOP for short. This was not true for CORBA 1.0 products,

however. The whole purpose of IIOP is to ensure that your client will be able to communicate

with a server written for a different ORB from a different vendor.


13/25

13

Figure 3.3 A request from a client to an object implementation within a network

3.3 Interface definition language

As with RMI, CORBA objects are to be specified with interfaces, which are the contract

between the client and server. In CORBAs case, however, interfaces are specified in the

special definition language IDL. The IDL defines the types of objects by defining their

interfaces. An interface consists of a set of named operations and the parameters to those

operations. Note that IDL is used to describe interfaces only, not implementations. Despite

the fact that IDL syntax is similar to C++ and Java, IDL is not a programming language.

Through IDL, a particular object implementation tells its potential clients what operations are

available and how they should be invoked. From IDL definitions, the CORBA objects aremapped into different programming languages. Some of the programming languages with

IDL mapping include C, C++, Java, Smalltalk, Lisp, and Python. Thus, once you define an

interface to objects in IDL, you are free to implement the object using any suitable

programming language that has IDL mapping. And, consequently, if you want to use that

object, you can use any programming language to make remote requests to the object. Inchapter 13, Ill give you detailed coverage of IDL, and in chapter 14, Ill give you an

overview of the IDL-to-Java mapping.

3.4 Dynamic invocation interface

Invoking operations can be done through either static or dynamic interfaces. Static invocationinterfaces are determined at compile time, and they are presented to the client using stubs.

The DII, on the other hand, allows client applications to use server objects without knowing

the type of those objects at compile time. It allows a client to obtain an instance of a CORBA

object and make invocations on that object by dynamically constructing requests. DII uses the

interface repository to validate and retrieve the signature of the operation on which a request

is made. CORBA supports both the dynamic and the static invocation interfaces.

3.5 Dynamic skeleton interface

Analogous to the DII is the server-side dynamic skeleton interface (DSI), which allows

servers to be written without having skeletons, or compile-time knowledge, for the objects

being implemented. Unlike DII, which was part of the initial CORBA specification, DSI was


14/25

14

introduced in CORBA 2.0. Its main purpose is to support the implementation of gateways

between ORBs which utilize different communication protocols. However, DSI has many

other applications beside interoperability. These applications include interactive software

tools based on interpreters and distributed debuggers.

3.6 Interface Repository

The IR provides another way to specify the interfaces to objects. Interfaces can be added to

the interface repository service. Using the IR, a client should be able to locate an object that

is unknown at compile time, find information about its interface, then build a request to be

forwarded through the ORB.

3.7 Object adapters

An object adapter is the primary way that an object implementation accesses services

provided by the ORB. Such services include object reference generation and interpretation,

method invocation, security of interactions, and object and implementation activation anddeactivation.


15/25

15

Chapter 4

Interoperability

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.

4.1 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.

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

immediateand mediatedbridgingof 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 mediatedbridge domains. By use of bridging techniques, ORBs can interoperate without knowing any

details of that ORBs implementation, such as what particular IPC or protocols (such as

ESIOPs) are used to implement the CORBAspecification.

Inter-ORB Bridge Support

The interoperability architecture clearly identifies the role of different kinds of domains for

ORB-specific information. Such domains can include object reference domains, type

domains, security domains (e.g., the scope of a Principal identifier), a transaction domain,

and more. Where two ORBs are in the same domain, they can communicate directly. In manycases, this is the preferable approach. This is not always true, however, since organizations

often need to establish local control domains. When information in an invocation must leave

its domain, the invocation must traverse a bridge. The role of a bridge is to ensure that

content and semantics are mapped from the form appropriate to one ORB to that of another,

so that users of any given ORB only see their appropriate content and semantics. The inter-

ORB bridge support element specifies ORB APIs and conventions to enable the easy

construction of interoperability bridges between ORB domains. Such bridge products could

be developed by ORB vendors, Sieves, system integrators, or other third-parties.Because the

extensions required to support Inter-ORB Bridges are largely general in nature, do not impact

other ORB operation, and can be used for many other purposes besides building bridges, they

are appropriate for all ORBs to support. Other applications include debugging, interposing of


16/25

16

objects, implementing objects with interpreters and scripting languages, and dynamically

generating implementations.

General Inter-ORB Protocol (GIOP)

The General Inter-ORB Protocol (GIOP) element specifies a standard transfer syntax (low-level data representation) and a set of message formats for communications between ORBs.

The GIOP is specifically built for ORB to ORB interactions and is designed to work directly

over any connection-oriented transport protocol that meets a minimal set of assumptions. It

does not require or rely on the use of higher level RPC mechanisms. The protocol is simple,

scalable and relatively easy to implement. It is designed to allow portable implementations

with small memory footprints and reasonable performance, with minimal dependencies on

supporting software other than the underlying transport layer. While versions of the GIOP

running on different transports would not be directly interoperable, their commonality would

allow easy and efficient bridging between such networking domains.

The IIOPs relationship to the GIOP is similar to that of a specific language mapping to OMG

IDL; the GIOP may be mapped onto a number of different transports, and specifies theprotocol elements that are common to all such mappings. The GIOP by itself, however, does

not provide complete interoperability, just as IDL cannot be used to build complete programs.

The IIOP and other similar mappings to different transports, are concrete realizations of the

abstract GIOP definitions, as shown in Figure 4-1

Figure 4-1 Inter-ORB Protocol Relationships

Environment-Specific Inter-ORB Protocols (ESIOPs)

This specification also makes provision for an open-ended set of Environment-Specific Inter-

ORB Protocols (ESIOPs). Such protocols would be used for out of the box interoperation

at user sites where a particular networking or distributing computing infrastructure is already

in general use. Because of the opportunity to leverage and build on facilities provided by the

specific environment, ESIOPs might support specialized capabilities such as those relating to

security and administration. While ESIOPs may be optimized for particular environments, all

ESIOP specifications will be expected to conform to the general ORB interoperability

architecture conventions to enable easy bridging. The inter-ORB bridge support enables

bridges to be built between ORB domains that use the IIOP and ORB domains that use a

particular ESIOP.


17/25

17

4.2 Relationship to Previous Versions of CORBA

The ORB Interoperability Architecture builds on Common Object Request Broker

Architecture by adding the notion of ORB Services and their domains. (ORB Services are

described in Section 13.2, ORBs and ORB Services, on page 13 -3). The architecture

defines the problem of ORB interoperability in terms of bridging between those domains, anddefines several ways in which those bridges can be constructed. The bridges can be internal

(in-line) and external (request-level) to ORBs. APIs included in the interoperability

specifications include compatible extensions to previous versions of CORBA to support

request-level bridging:

A Dynamic Skeleton Interface (DSI) is the basic support needed for building request-level bridges. It is the server-side analogue of the Dynamic Invocation Interface and

in the same way it has general applicability beyond bridging. For information about

the Dynamic Skeleton Interface, refer to the DynamicSkeletonInterfacechapter.

APIs for managing object references have been defined, building on the supportidentified for the Relationship Service. The APIs are defined in Object Reference

Operations in the ORB Interface chapter of this book. The Relationship Service isdescribed in the Relationship Service specification; refer to the CosObjectIdentity

Modulesection of that specification.

4.3 Examples of Interoperability Solutions

The elements of interoperability (Inter-ORB Bridges, General and Internet Inter-ORB

Protocols, Environment-Specific Inter-ORB Protocols) can be combined in a variety of

ways to satisfy particular product and customer needs. This section provides some

examples.

Example 1

ORB product A is designed to support objects distributed across a network and provide out

of the box interoperability with compatible ORBs from other vendors. In addition it allows

bridges to be built between it and other ORBs that use environment specific or proprietary

protocols. To accomplish this, ORB A uses the IIOP and provides inter-ORB bridge support.

Example 2

ORB product B is designed to provide highly optimized, very high-speed support for objects

located on a single machine. For example, to support thousands of Fresco GUI objectsoperated on at near function-call speeds. In addition, some of the objects will need to be

accessible from other machines and objects on other machines will need to be infrequently

accessed. To accomplish this, ORB A provides a half-bridge to support the Internet IOP for

communication with other distributed ORBs.

Example 3

ORB product C is optimized to work in a particular operating environment. It uses a

particular environment-specific protocol based on distributed computing services that are

commonly available at the target customer sites. In addition, ORB C is expected to

interoperate with other arbitrary ORBs from other vendors. To accomplish this, ORB C

provides inter-ORB bridge support and a companion half-bridge product (supplied by the


18/25

18

ORB vendor or some third-party) provides the connection to other ORBs. The halfbridge uses

the IIOP to enable interoperability with other compatible ORBs.

4.4 Motivating Factors

This section explains the factors that motivated the creation of interoperabilityspecifications.

ORB Implementation Diversity

Today, there are many different ORB products that address a variety of user needs. A large

diversity of implementation techniques is evident. For example, the time for a request ranges

over at least 5 orders of magnitude, from a few microseconds to several seconds. The scope

ranges from a single application to enterprise networks. Some ORBs have high levels of

security, others are more open. Some ORBs are layered on a particular widely used protocol,

others use highly optimized, proprietary protocols. The market for object systems and

applications that use them will grow as object systems are able to be applied to more kinds of

computing. From application integration to process control, from loosely coupled operating

systems to the information superhighway, CORBA-based object systems can be the common

infrastructure.

ORB Boundaries

Even when it is not required by implementation differences, there are other reasons to

partition an environment into different ORBs. For security reasons, it may be important to

know that it is not generally possible to access objects in one domain from another. For

example, an internet ORB may makepublic information widely available, but a companyORB will want to restrict what information can get out. Even if they used the same ORB

implementation, these two ORBs would be separate, so that the company could allow access

to public objects from inside the company without allowing access to private objects from

outside. Even though individual objects should protect themselves, prudent system

administrators will want to avoid exposing sensitive objects to attacks from outside the

company.

ORBs Vary in Scope, Distance, and Lifetime

Even in a single computing environment produced by a single vendor, there are reasons why

some of the objects an application might use would be in one ORB, and others in anotherORB. Some objects and services are accessed over long distances, with more global

visibility, longer delays, and less reliable communication. Other objects are nearby, are not

accessed from elsewhere, and provide higher quality service. By deciding which ORB to use,

an implementer sets expectations for the clients of the objects.

One ORB might be used to retain links to information that is expected to accumulate over

decades, such as library archives. Another ORB might be used to manage a distributed chess

program in which the objects should all be destroyed when the game is over. Although while

it is running, it makes sense for chess ORB objects to access the archives ORB, we

would not expect the archives to try to keep a reference to the current board position.


19/25

19

4.5 Interoperability Design Goals

Because of the diversity in ORB implementations, multiple approaches to interoperability are

required. Options identified in previous versions of CORBAinclude:

Protocol Translation, where a gateway residing somewhere in the system mapsrequests from the format used by one ORB to that used by another.

ReferenceEmbedding, where invocation using a native object reference delegates to aspecial object whose job is to forward that invocation to another ORB.

AlternativeORBs, where ORB implementations agree to coexist in the same addressspace so easily that a client or implementation can transparently use any of them, and

pass object references created by one ORB to another ORB without losing

functionality.

In general, there is no single protocol that can meet everyone's needs, and there is no single

means to interoperate between two different protocols. There are many environments in

which multiple protocols exist, and there are ways to bridge between environments that share

no protocols.This specification adopts a flexible architecture that allows a wide variety of ORB

implementations to interoperate and that includes both bridging and common protocol

elements. The following goals guided the creation of interoperability specifications:

The architecture and specifications should allow high-performance, small footprint,lightweight interoperability solutions.

The design should scale, should not be unduly difficult to implement, and should notunnecessarily restrict implementation choices.

Interoperability solutions should be able to work with any vendors existing ORBimplementations with respect to their CORBA-compliant core feature set; those

implementations are diverse.

All operations implied by the CORBA object model (i.e., the stringify and destringifyoperations defined on the CORBA:ORB pseudo-object and all the operations on

CORBA:Object) as well as type management (e.g., narrowing, as needed by the C++

mapping) should be supported.

Non-Goals

The following were taken into account, but were not goals:

Support for security Support for future ORB Services


20/25

20

Chapter 5

Portable Interceptors

5.1 Introduction

Portable Interceptors are hooks into the ORB through which ORB services can intercept the

normal flow of execution of the ORB. The following figures describe the programming

model for which portable Interceptors were designed.

Object Creation

Figure 5-1 Object Creation

Figure 5-1 shows the parts involved in the creation of an object. An object is represented by

an IOR created by the POA. A set of policies is used to create a POA which influences the set

of tagged components contained within the profiles of any IOR created by that POA. ORB

services may have tagged components specific to their service, therefore they require a means

to add tagged components to an IOR. ORB services may also introduce new policies;

therefore, they require a means to create these new policies.

Requirement: Add tagged components

Satisfiedby: IORInterceptor

Requirement: Create policies

Satisfiedby: PolicyFactory

Client Sends Request


21/25

21

Figure 5-2 Transfer Clients Context to Requests Service Context

Figure 21-2 shows what is needed to transfer a clients context to the service context. Service

contexts are populated from information in a services Current object, from the effectivepolicies, and from information in the tagged components on an IORs profile.

The processing of a request is an integral part of the ORB. Since each ORB service

potentially creates its own service context, there must be a means by which each service can

get the necessary information during request processing. Since service contexts are defined as

a unique identifier and an octet sequence containing a CDR encapsulation there must be a

portable method to create such an octet sequence.

Requirement: Intercept request processing and access necessary data.

Satisfied by: Request Interceptors and the PortableInterceptor::Current

Requirement: Convert types to octet sequences

Satisfied by: Codec .

Server Receives Request

Figure 5-3 Transfer Requests Service Context to Servers Context

On the client, the clients context is transferred to the requests service context. On the server,

the opposite must occur: the information in the service context is transferred to the servers

context which is then available to the server application. Figure 21-3 shows what is necessary


22/25

22

to accomplish this. The requirements which exist in Section 21.1.2, Client Sends Request,

on page 21-3 also exist here.

Server Sends Reply

Figure 5-4 Transfer Servers Context to Replys Service ContextFigure 5-4 shows what is needed to transfer a servers context to a replys service context.

Service contexts are populated from information in a services Current object. The

requirements which exist in Section 5.1.2, Client Sends Request, on page 5-3 also exist

here.Client Receives Reply

Figure 5-5 View the Service Context on the Client Reply

When processing the client reply, although the clients context cannot be updated by thereplys service context, the service may still wish to query the service context information.

The clients context cannot be updated because such updates would be invalid on

asynchronous calls. The client thread may be continually changing its context and if a reply

also changed the context at any time, the state of the context at any given time would be

indeterminate.

5.2 Interceptor Interface

Portable Interceptor interfaces and related type definitions reside in the module

PortableInterceptor. All portable Interceptors inherit from the local interface Interceptor:


23/25

23

module PortableInterceptor { local interface Interceptor { readonly attribute string

name; void destroy();

};

};Each Interceptor may have a name that may be used administratively to order the lists of

Interceptors. Only one Interceptor of a given name can be registered with the ORB for eachInterceptor type. An Interceptor may be anonymous; that is, have an empty string as the name

attribute. Any number of anonymous Interceptors may be registered with the ORB.

Interceptor::destroy is called during ORB::destroy. When an application calls

ORB::destroy, the ORB:

1. Waits for all requests in progress to complete.

2. Calls the Interceptor::destroy operation for each interceptor.

3. Completes destruction of the ORB.

Method invocations from within Interceptor::destroy on object references for objects

implemented on the ORB being destroyed result in undefined behavior. However, method

invocations on objects implemented on an ORB other than the one being destroyed are

permitted. (This means that the ORB being destroyed is still capable of acting as a client, butnot as a server.)

5.3 Request Interceptors

A request Interceptor is designed to intercept the flow of a request/reply sequence through the

ORB at specific points so that services can query the request information and manipulate the

service contexts that are propagated between clients and servers. The primary use of request

Interceptors is to enable ORB services to transfer context information between clients and

servers. There are two types of request Interceptors: client-side and server-side

Design Principles

The following points are the principles followed in the design of the portable Interceptor

architecture.

1. Interceptors are called on all ORB mediated invocations. The following implicit objectoperations may or may not be ORB mediated: get_interface, is_a, non_existent,

get_domain_managers, and get_component. When these are ORB mediated,

Interceptors are called; when they are not ORB mediated, Interceptors are not called.

2. A request Interceptor can affect the outcome of a request by raising a system exception atany of the interception points. It can stop the request from even reaching the target by

raising a system exception in the outbound path. It can alter an outcome specified by thetarget (exception or non-exception) by raising a system exception in the inbound path.

3. A request Interceptor can affect the outcome of a request by directing a request to adifferent location at any interception point other than a successful reply. That different

location might include a location not otherwise reachable through the original request;

that is, a location that might not be discovered by the ORB in the course of a locate

request.

4. A request Interceptor cannot affect a request by changing a parameter specified by the

client. That is, the Interceptor cannot modify in arguments.

5. A request Interceptor cannot affect a non-exception outcome by supplying the response

itself. That is, the Interceptor cannot modify out arguments or the return value.

6. Request Interceptors are independent of other request Interceptors. That is, a requestInterceptor wont need to know, and wont even be told, if there are request Interceptors


24/25

24

executed before or after it. If a request Interceptor down the line (executed closer to the target

than this one) affects the outcome of request, this request Interceptor will not be aware of that

fact. Corollary: request Interceptors can communicate between themselves to bypass this

principle, but thats outside of the concerns of the model.

7. A request Interceptor may make object invocations itself before allowing the current

request to execute.8. There is no provision for making client implementations aware that any request Interceptor

has been or will be called. Corollary: A client and a request Interceptor can communicate

between themselves to bypass this principle, but that is outside of the concerns of the model.

9. There is no provision for making object implementations aware that any request

Interceptor has been or will be called. Corollary: An object implementation and a request

Interceptor can communicate between themselves to bypass this principle, but that is outside

of the concerns of the model.

10. To ensure the integrity of the effect of each request Interceptor, a set of general flow rules

are specified that govern the flow of processing through a list of interceptors. See below.

General Flow Rules

Both client and server request Interceptors are registered with an ORB. The ORB logically

maintains an ordered list of these Interceptors. To accommodate both the client and server

request Interceptors, and any future additions to the interception points list, the following

general rules apply to the flow of execution of request interception points:

There is a set of starting interception points. One and only one of these is called onany given request/reply sequence;

There is a set of ending interception points. One and only one of these is called on anygiven request/reply sequence;

There may be any number of intermediate interception points between the start andend interception points which run in sequence;

On an exception, intermediate interception points may not be called;

If and only if a starting interception point runs to completion is an ending interception point

called.

The Flow Stack Visual Model

To visualize the general flow rules, think of each Interceptor as being put on a Flow Stack

when a starting interception point completes successfully. (An ORB need not implement the

Flow Stack. It is presented simply as a visual cue.) An ending interception point is called for

each Interceptor in the stack. If a starting interception point is called for all Interceptors, thenall Interceptors will have an ending interception point called. If one of the Interceptors raises

an exception during the invocation of its starting interception point, only those Interceptors

on the stack at that point will be popped and have an ending interception point called.

The Request Interceptor Points

Each request Interceptor is called at a number of interception points. Figure 5-6 shows the

flow of control for a request/reply cycle that is subject to at least one request Interceptor.


25/25

Figure 5-6Request Interception Points

Client-Side Interceptor

To write a client-side Interceptor, the ClientRequestInterceptor local interface shall

be implemented.

local interface ClientRequestInterceptor : Interceptor {void send_request (in ClientRequestInfo ri)

raises (ForwardRequest);

void send_poll (in ClientRequestInfo ri);

void receive_reply (in ClientRequestInfo ri);

void receive_exception (in ClientRequestInfo ri)


void receive_other (in ClientRequestInfo ri)


};

Documents

Final Report (NKS)