CIS – 501 Term Paper (Spring 2001)
Dr, William Hankley
Topic :
Distributed Object Computing with CORBA
--- Padmaja Havaldar (3926)
1
Abstract :
The CORBA Specification has provided abstractions for distributed programming that
have served as the basis for a variety of distributed systems. Despite its original
flexibility and applicability to various environments, however, CORBA
has had to evolve to remain viable as a standard for distributed object-oriented
applications. This paper explains several features that are related to CORBA. They are
the Object Request Broker (ORB) Core, Interface Definition Language, Dynamic
Invocation Interface, Interface Repository and the Object Adapters. It also describes
how CORBA works and the need for using CORBA.
2
CORBA stands for Common Object Request Broker Architecture. It is a technology
standard that is published by the Object Management Group (OMG). The core
component in CORBA is the Object Request Broker (ORB). This mechanism allows
objects to transparently make requests to and receive responses from other objects located
locally or remotely. The client is not aware of the mechanisms used to communicate with,
activate, or store the server objects. The ORB serves as the foundation for building
distributed object applications. The standard specification includes a generic Interface
Definition Language (IDL).
The CORBA standard was created to answer the need for interoperability among the
rapidly proliferating number of hardware and software products available today. CORBA
allows applications to communicate with one another regardless of where they are located
or who has designed them. The CORBA specification describes a computer architecture
that is object-oriented, distributed, language-independent, and hardware-neutral.
Object-oriented. CORBA is object-oriented, making it is easy to build components that
can be interchanged and reused.
Distributed. CORBA’s distributed architecture overcomes the inherent inflexibility of
traditional client-server systems. To communicate in a traditional client-server
environment, the client and server must be intimately familiar with one another. In a
CORBA scheme, an object request broker (ORB) sits between the client and server and
marshals all communication between them. This decoupling of the client and server
enables rapid integration of new and pre-existing components.
Language-independent. CORBA enables objects to interact through a languageindependent specification known as the interface definition language (IDL). IDL defines
interfaces to data sources and analysis objects. As a result, the code that implements these
interfaces can change without impact on the user of the implementation.
The OMG Object Management Architecture (OMA) attempts to define, at a high level of
abstraction, the various facilities necessary for distributed OO computing. The core of the
OMA is the Object Request Broker (ORB), a mechanism that provides transparency of
object location, activation, and communication.
The CORBA is composed of five major components:
• ORB Core
• Interface Definition Language
• Dynamic Invocation Interface
• Interface Repository
• Object Adapters
ORB Core: The idea behind CORBA is a software intermediary that handles and
disperses access requests on data sets. This intermediary is referred to as an Object
Request Broker (ORB). The ORB interacts and makes requests to differing objects. It sits
on the host between the data and the application layer (that is, one level lower than the
3
application layer). An ORB negotiates between request messages from objects or object
servers and the affiliated data sets.
Interface Definition Language (IDL): The most important part of the OMG
specification is the Interface Definition Language (IDL). At the core of all CORBA
objects is the strict IDL interface, the most important part of the implementation of an
application. The IDL interface for each object allows an object to interact with the rest of
the world by communicating that object's methods and parameters to other objects
through the ORB. CORBA enforces these interface rules by specifying that an object and
its interface must be tightly coupled and cohesive.
The common implementation of the RPC side of CORBA occurs through stubs and
skeletons. There are two types of stubs: a stub for the client process and a stub for the
server process. The stub for the server process is hereafter called a skeleton. These stubs
act as templates for one another so that methods and parameter-type cohesion are
consistent. The stubs are generated from IDL mapping for a given language. Stubs or
skeletons are the compiled IDL for the objects. Within these stubs are the detailed signal
processing and exception handling needed for the brokerage to occur.
Dynamic Invocation Interface (DII): The CORBA document also specifies a Dynamic
Invocation Interface, which allows CORBA objects not to know until run time interface
information about another object they may use. The links to the object are handled by the
ORB while the application is running. The server side of this interface is known as the
Dynamic Skeleton Interface (DSI).
The DSI is used by the ORB to issue requests to objects that are implemented
independently and that have no compile-time knowledge of their implementation. The
DSI is analogous to a type-specific (IDL) skeleton.
Developers could use DII and DSI to set up interfaces from their objects to interfaces
unknown at the time of development. An example would be a C++ class browser.
Although the dynamic approach of DII and DSI is more flexible, it is more difficult to
implement than its static IDL counterpart. Once developed, DII and DSI are always
slower than static IDL.
Interface Repository: Another service supported by the Object interface and hence all
object references is the get_interface()operation. This operation returns an object
reference to an InterfaceDef that describes the object’s interface. TheInterfaceDef is
stored in an Interface Repository (IR) which provides persistent storage for IDL interface
declarations.The services offered by an IR allow navigation of an object’s inheritance
hierarchy and provide descriptions of all operations that an object supports. .
4
Interface Repositories can be used for several purposes. Interface browsers can traverse
IR information to help application developers locate potentially reusable software
components. ORBs could use them to check operation parameter types at run time. The
primary function of the IR, however, is to provide the type information
necessary to issue requests using the Dynamic Invocation Interface.
Object Adapters: The Object Adapter is how a CORBA object knows of and uses the
services of an ORB. It allows an ORB to make calls of an object's methods and to create
and delete that object, as well as provides security for the ORB and the mapping of object
references to implementations. It allows an ORB to generate and use a reference to its
object. The purpose is to provide another level of abstraction so ORBs can interface in a
standard way with many CORBA objects across platforms and networks.
User-developed application clients can contact CORBA objects for data. These clients
use the data sets of different objects but do not have their own data set. These are datadependent programs that operate based on other data sets. The ORB is the mechanism for
handling the interactions from a user-developed client to a CORBA object.
How CORBA works:
Developers use CORBA to distribute applications across client-server networks. Instead
of having hundreds of thousands of lines of code running on mainframe computers with
dumb terminals, smaller, more robust applications that communicate between file servers
and workstations are now necessary. To keep this distribution of applications simple, a
plug-and- play architecture is necessary to distribute the client-server applications. The
programmer then can write applications that work independently across platforms and
networks.
The idea behind CORBA is a software intermediary that handles and disperses access
requests on data sets. This intermediary is referred to as an Object Request Broker
(ORB). The ORB interacts and makes requests to differing objects. The ORB is the data
negotiator of this framework. An ORB knows about the interfaces to certain objects. The
IDLs for the objects it knows are located in a dynamic listing called the interface
repository. An ORB has the ability to know of other objects that reside in different host
systems. When queried, the ORB tries to match the requested data object to its interface
repository. Then through its implementation repository, the ORB will attempt to send a
message to the object. If the data object or its server is not running, the ORB will obtain
the reference of how and where to start the object in the implementation repository or an
associated database. Once the ORB has the correct reference, it will attempt to start that
object and then proceed to send the original message. If this process fails or the ORB
does not know of the requested object, the ORB will return an appropriate error message
to the calling client application or object.
5
The ORB removes the complexity of distributed network programming for developers.
We no longer need to worry about how to set up and test low- level RPC routines to carry
data from one application to another. We simply set up IDL references to the object and
response methods within the object. Then, we compile and register the object (and its
server possibly), and we are ready to go.
The OMG-specified interface repository is kept within a CORBA host and maintained by
the ORB process (a daemon). The interface repository is a listing of all object IDLs the
ORB needs to be aware of. The object IDLs are not constrained to the same host that the
ORB is running on. They could be on different hosts but must be registered in an
interface repository for use. This repository allows for persistent objects. It does not care
about the status of an object; it is in essence the ORB's database of interfaces for use at
run time. Therefore, applications need not be compiled or linked with the information of
other CORBA objects, but they may still issue calls and use the information through DII.
Also maintained by the ORB daemon is a specified implementation repository. This
repository allows ORBs to locate and activate the various implementations of objects.
The CORBA objects are not required to be running processes. Thus, the ORB is required
to know how to activate an object, if necessary. Usually activating an object requires a
symbol table or other database that has the specified path to the object or server and other
necessary information. Such information could be the last time the object or server was
accessed. If another CORBA object issues a request to a nonrunning CORBA object, the
implementation repository allows the activation of the requested object and the passing of
the original request. At run time, this activity is invisible to the developer.
CORBA Interoperability
The CORBA interoperability standard was developed to allow different ORBs to
communicate. CORBA interoperability provides a gateway infrastructure that makes
different ORB implementations compatible The General Inter-ORB Protocol (GIOP)
specifies one main constraint: different ORBs must be TCP/IP compliant. This
specialized form of the GIOP is referred to as the Internet Inter-ORB Protocol (IIOP).
Through the CORBA specification, the CORBA methods and services allow the object
methodology to be carried to a distributed, enterprise network. Through IIOP, CORBA is
standardized to a lower network level (of OSI) so it may be used between multiple
heterogeneous enterprise networks.
Seven specified IIOP message types exist: Request, Reply, CancelRequest,
LocateRequest, LocateReply, CloseConnection, and MessageError. All message types are
straightforward, except the two Locate message types, which are used for network speed
optimization routines.
Different implementations of ORBs either could be straight IIOP run over TCP/IP
networks or could run over a different type of network infrastructure, such as Novell's
NetWare or a Windows NT Transport Driver Interface (TDI). For the latter to occur, the
ORB implementation would need an associated "bridge" implementation. This bridge
allows its ORBs to communicate with IIOP-based ORBs. When writing a bridge, an
6
implementation can be developed with the Dynamic Skeleton Interface mentioned
previously.
Why CORBA?
Distributed object technology allows granular components of software to plug-and-play,
inter-operate across networks, run on different platforms, coexist with legacy applications
through object wrappers, and manage themselves and the resources they control. CORBA
will be the foundation of this technology.
In general terms, CORBA is a kind of middleware, and in that role, it offers similar
functionality to other middleware solutions in providing scalability, reliability, security
and network transparency to distributed processing.
The CORBA technology makes a perfect marriage with the Internet technologies. This
marriage will make Distributed Object technology in general - and CORBA in particular
- very important.
The CORBA standard is widely shared in the industry - except by Microsoft, who has
created DCOM as an alternative. Fortunately, the COM and CORBA technologies are
inter-operable and we expect their integration to become even better in the future.
Summary:
The goal of CORBA is to make programming easier by making CORBA- based
applications highly portable. Developers now have a standardized set of facilities, as we
shall see later, that they can issue on a host machine to retrieve or manipulate requested
data. Using different databases and data files on one or more hosts will now go unnoticed
by the user or the application. Applications become easy to integrate because the
interfaces are identical.
References:
http://www.cs.wustl.edu/~schmidt/PDF/docwc.pdf
7