Department of Computer Engineering Exp No.

12
Semester B.E. Semester VIII – Computer Engineering
Subject Parallel and Distributed Systems
Subject Professor In-charge Prof. Pankaj Vanwari
Assisting Teacher Prof. Avinash Shrivas
Laboratory M 313-A

Student Name Pushkar Kurhekar

Roll Number 15102B0036
Grade and Subject
Teacher’s Signature

Experiment Number 12
Experiment Title Study of CORBA
Theory CORBA is the acronym for Common Object Request Broker Architecture,
OMG's open vendor-independent architecture and infrastructure that computer applications
use to work together over networks. The Common Object Request Broker Architecture
(CORBA) [OMG:95a] is an emerging open distributed object computing infrastructure
being standardized by the Object Management Group (OMG). CORBA automates many
common network programming tasks such as object registration, location, and activation;
request demultiplexing; framing and error-handling; parameter marshalling and
demarshalling; and operation dispatching. See the OMG Web site for more overview
material on CORBA. See my CORBA page for additional information on CORBA, including
our tutorials and research on high-performance and real-time ORBs. Results from our
research on high-performance and real-time CORBA are freely available for downloading
in the open-source TAO ORB.
The following figure illustrates the primary components in the OMG Reference Model
architecture. Descriptions of these components are available further below. Portions of
these descriptions are based on material from [Vinoski].
Figure 1. OMG Reference Model Architecture

Object Services -- These are domain-independent interfaces that are used by many
Department of Computer Engineering Exp No. 12
distributed object programs. For example, a service providing for the discovery of other
available services is almost always necessary regardless of the application domain. Two
examples of Object Services that fulfill this role are:
The Naming Service -- which allows clients to find objects based on names;
The Trading Service -- which allows clients to find objects based on their properties.
There are also Object Service specifications for lifecycle management, security,
transactions, and event notification, as well as many others [OMG:95b].
Common Facilities -- Like Object Service interfaces, these interfaces are also
horizontally-oriented, but unlike Object Services they are oriented towards end-user
applications. An example of such a facility is the Distributed Document Component Facility
(DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for
the presentation and interchange of objects based on a document model, for example,
facilitating the linking of a spreadsheet object into a report document.
Domain Interfaces -- These interfaces fill roles similar to Object Services and Common
Facilities but are oriented towards specific application domains. For example, one of the
first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM)
Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the
telecommunications, medical, and financial domains.
Application Interfaces - These are interfaces developed specifically for a given
application. Because they are application-specific, and because the OMG does not
develop applications (only specifications), these interfaces are not standardized. However,
if over time it appears that certain broadly useful services emerge out of a particular
application domain, they might become candidates for future OMG standardization.
CORBA ORB Architecture
The following figure illustrates the primary components in the CORBA ORB architecture.
Descriptions of these components are available below the figure.
Figure 2. CORBA ORB Architecture

Object -- This is a CORBA programming entity that consists of an identity, an interface,

Department of Computer Engineering Exp No. 12
and an implementation, which is known as a Servant.
Servant -- This is an implementation programming language entity that defines the
operations that support a CORBA IDL interface. Servants can be written in a variety of
languages, including C, C++, Java, Smalltalk, and Ada.
Client -- This is the program entity that invokes an operation on an object
implementation. Accessing the services of a remote object should be transparent to the
caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args).
The remaining components in Figure 2 help to support this level of transparency.
Object Request Broker (ORB) -- The ORB provides a mechanism for transparently
communicating client requests to target object implementations. The ORB simplifies
distributed programming by decoupling the client from the details of the method
invocations. This makes client requests appear to be local procedure calls. When a client
invokes an operation, the ORB is responsible for finding the object implementation,
transparently activating it if necessary, delivering the request to the object, and returning
any response to the caller.
ORB Interface -- An ORB is a logical entity that may be implemented in various ways
(such as one or more processes or a set of libraries). To decouple applications from
implementation details, the CORBA specification defines an abstract interface for an ORB.
This interface provides various helper functions such as converting object references to
strings and vice versa, and creating argument lists for requests made through the dynamic
invocation interface described below.
CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue''
between the client and server applications, respectively, and the ORB. The transformation
between CORBA IDL definitions and the target programming language is automated by a
CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies
between client stubs and server skeletons and increases opportunities for automated
compiler optimizations.
Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the
underlying request mechanisms provided by an ORB. Applications use the DII to
dynamically issue requests to objects without requiring IDL interface-specific stubs to be
linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows
clients to make non-blocking deferred synchronous (separate send and receive operations)
and oneway (send-only) calls.
Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's
DII. The DSI allows an ORB to deliver requests to an object implementation that does not
have compile-time knowledge of the type of the object it is implementing. The client making
the request has no idea whether the implementation is using the type-specific IDL
skeletons or is using the dynamic skeletons.
Object Adapter -- This assists the ORB with delivering requests to the object and with
activating the object. More importantly, an object adapter associates object implementation
with the ORB. Object adapters can be specialized to provide support for certain object
implementation styles (such as OODB object adapters for persistence and library object
adapters for non-remote objects).
-A stateless system can be seen as a box [black? ;)] where at any point in time
the value of the output(s) depends only on the value of the input(s) [after a certain
processing time]
A stateful system instead can be seen as a box where at any point in time the value of the
output(s) depends on the value of the input(s) and of an internal state, so basically a
 Department of Computer Engineering Exp No. 12
stateful system is like a state machine with "memory" as the same set of input(s) value can
generate different output(s) depending on the previous input(s) received by the system.
-From the parallel programming point of view, a stateless system, if properly
implemented, can be executed by multiple threads/tasks at the same time without any
concurrency issue [as an example think of a reentrant function] A stateful system will
requires that multiple threads of execution access and update the internal state of the
system in an exclusive way, hence there will be a need for a serialization [synchronization]
point.
-A stateful server keeps state between connections. A stateless server does not.
-HTTP and NFS are stateless protocols. Each request stands on its own.
Sometimes cookies are used to add some state to a stateless protocol. In HTTP (web
pages), the server sends you a cookie and then the browser holds the state, only to send it
back to the server on a subsequent request.
SMB is a stateful protocol. A client can open a file on the server, and the server may deny
another client’s access to that file until the client closes it.
Conclusion Thus, we understand the working of CORBA by referring its architecture. CORBA is the
acronym for Common Object Request Broker Architecture, The Common Object Request
Broker Architecture is an emerging open distributed object computing infrastructure being
standardized by the Object Management Group (OMG). CORBA automates many common
network programming tasks such as object registration, location, and activation; request
demultiplexing; framing and error-handling; parameter marshalling and demarshalling; and
operation dispatching.