The following are a simplified description of minimal key elements required to learn
CORBA programming quickly.
copyrightę2001 Prof Devi - email@example.com, firstname.lastname@example.org. All rights reserved
- An Object Request Broker (ORB) is a layer of code that lets objects
transparently make invocations on remote or local objects. The ORB layer of code is
encapsulated in the form of an object. The ORB object is often referred to as an
pseudo-object as it is only accessible to the current running process. It cannot be
made accessible remotely as can a CORBA object. This ORB is also sometimes referred
to as a locality constrained object.
- ORBs communicate with each other using a communication protocol that abides by General
Inter-Orb Protocol(GIOP). GIOP must use a connection oriented network
protocol A specific example of GIOP which runs on TCP/IP networks is the Internet
Inter-ORB Protocol. IIOP uses Transmission Control Protocol(TCP) for
connection oriented communication.
- A CORBA Object has an interface with operations
and attributes. An interface is much like a C++
class with public member methods. In CORBA terms, the C++ class member methods are
called as operations. Attributes are much like
data members of C++ classes. But attributes correspond to nothing
more than C++ mutators and accessors of the some piece of data. Calling a method on
a CORBA Object is referred to as an invocation of an operation on an object.
- Unlike C++ objects, CORBA objects are virtual. A CORBA object can exist with out
having any real code to handle the incoming invocations. The real code, written in
some language that is running to service invocation, is called a servant.
In earlier OMG documentation, a servant was called an object implementation.
When the servant does exist and is ready to handle the incoming
invocations, the servant is said to incarnate the CORBA
Object. When no servant exists to handle invocations on CORBA
Object, than CORBA Object is said to be etherealized. Going from
an etherealized state to an incarnated state is called servant
activation. Servant deactivation is the process of an a
servant going from an incarnated state to an etherealized state. A single servant may
incarnate several different CORBA Objects.
- A server in CORBA is any process that hosts servants(which
incarnate CORBA Objects). Activation of a server
is the process of converting a running server to start receiving incoming messages. ,
while deactivation means that the server is no longer able to receive
- A client is any piece of code that attempts to access a CORBA Object.
- An Object Adapter(OA) is an object that is is found in the server which
offers services and dispatches messages to servants. A server can have
several OA's, and each OA can be responsible for
forwarding messages to several servants. OA's are responsible for
creation of new CORBA objects, servants, and the binding of a CORBA object to a servant.
- The Basic Object Adapter (BOA) is an instance of an OA. The
Original CORBA specification, which defined this OA, did not give a complete functionality
through an IDL interface, and many ORB vendors extended the functionality of the BOA.
- The Portable Object Adapter(POA) is a newer instance of an OA.
OMG standardized the POA from the lessons learned from vendor implementations of BOA.
- The POA Manager is used to control client invocation messages to one or
more POAs.. For instance, the POA Manager
can be used to drop all invocations to a POA.
- POAs can have several policies(ie threading, persistent/transient,id generation) which
dictate how it functions. The RootPOA is a POA that has a default
set of policies(ie Single Threaded, Transient, POA Generated Object ID's).
- An Interface Repository(IR) is an database that holds CORBA object
location information. A client may use an IR to find a specific
CORBA object. A client can also find complete information through the IR about
an interface, its operations, and the arguments to the operations.
- An Interoperable Reference(IOR) is an opaque reference to an CORBA
Object which can give access to the CORBA Object's operations and attributes. The IOR
gives access to the the CORBA Object irrespective of where the Object really is. An
IOR is composed of several key components used to locate a CORBA Object: Protocol
ID, Communication End Point, a Time Stamp, Object Adapter ID, and a Repository
ID. IOR's can be converted into a string called an stringified IOR.
The process is called stringification. The stringified
IOR can be also turned back into an IOR This process is
- A proxy object logically embodies a CORBA Object. All the
operations found on a CORBA Object are found as methods in the proxy object.
An object reference variable points to a proxy object(logically
it acts like it points to a proxy object). Proxy objects wrap all
network communications internally.
- All interfaces are defined in an implementation neutral language called CORBA
IDL(Interface Definition Language). An IDL compiler for a specific language
takes the IDL definitions in a file and generates server skeletons and client
proxies in the language. A server skeleton is the
base code with which one uses to write servant code.