Transcript
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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:
8/2/2019 Final Report (NKS)
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
8/2/2019 Final Report (NKS)
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.
8/2/2019 Final Report (NKS)
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)
raises (ForwardRequest);
void receive_other (in ClientRequestInfo ri)
raises (ForwardRequest);
};
top related