The CORBA Architecture

CORBA, or Common Object Request Broker Architecture, is a

standard architecture for distributed object systems. It allows a
distributed, heterogeneous collection of objects to interoerate.
CORBA is a standard defined by the O!" #Object !anagement
"rou$. It describes an architecture, interfaces, and rotocols that
distributed objects can use to interact with each other.
%art of the CORBA standard is the Interface &efinition 'anguage
#I&'$, which is an imlementation(indeendent language for
describing the interfaces of remote objects.
)he O!" comrises o*er +,, comanies and organi-ations, including almost all the
major *endors and de*eloers of distributed object technology, including
latform, database, and alication *endors as well as software tool and
cororate de*eloers.
.a*a I&' is an imlementation of the standard I&'(to(.a*a maing
and is ro*ided by /un in *ersion 0.1 of .a*a 2 and is comliant with
CORBA 2.3 secification. .a*a I&' ro*ides an Object Request
Broker, or ORB.
)he ORB is a class library that enables low(le*el communication between .a*a(I&'
alications and other CORBA(comliant alications.
'ike R!I, .a*a I&' gi*es you a way to access remote objects o*er the network. It
also ro*ides tools you need to make your objects accessible to other CORBA clients.
If you e3ort a .a*a class using .a*a I&', you can create an object from that class and
ublish it through a naming4directory ser*ice.
A remote object can5 find this object, call methods on it, and recei*e data from it, just
as if it were running on the client6s local machine.
7nlike R!I, objects that are e3orted using CORBA can be accessed
by clients imlemented in any language with an I&' binding #C, C88,
Ada etc.$.
)he CORBA standard is e3tensi*e and ro*ides a rich set of ser*ices.
A few of the ser*ices are5
Service Description
Object life cycle &efines how CORBA objects are created, remo*ed,
mo*ed, and coied
Naming Service )he CORBA naming ser*ice ro*ides a naming
structure for remote objects.
Event Service Another COS that ro*ides a supplier-consumer
communication model that creates asynchronous
communication between the objects *ia an 9*ent
Channel. )he flow of data into the Event Channel is
handled by supplier objects, while the flow of data
out of the e*ent channel is handled by consumer
objects. )he Event Service suorts both the ush
and ull model. In the ush model, supplier objects
control the flow of data by ushing it to consumers
and in the ull model, consumer objects control the
flow of data by ulling data from the supplier.
Instead of directly communicating with each other,
the supplier and consumer can each obtain a ro3y
object from the Event Channel and communicate
with it. Supplier objects obtain a consumer proxy
and the consumer objects acquire a supplier proxy.
ersistent object service
Transactions Coordinates atomic access to CORBA objects
Concurrency Control %ro*ides a locking ser*ice for CORBA objects in
order to ensure concurrent access
CORBA %roducts
/e*eral *endors ro*ide CORBA roducts for *arious
rogramming languages. )he CORBA roducts that suort the
.a*a rogramming language include5
ORB &escrition
The !ava " ORB )he .a*a 2 ORB comes with /un:s .a*a 2. It is
missing se*eral features. )he main feature it has is
the ability to look u an object by name.
#isiBro$er for !ava A oular .a*a ORB from Inrise Cororation.
;isiBroker is also embedded in other roducts. <or
e3amle, it is the ORB that embedded in the
=etscae Communicator browser.
Orbi% A oular .a*a ORB from Iona )echnologies.
CORBA Architecture
)he major comonents that make u the CORBA architecture include the5
Interface &efinition 'anguage #I&'$, which is how CORBA
interfaces are defined,
Object Request Broker #ORB$, which is resonsible for all
interactions between remote objects and the alications that use
them,
)he %ortable Object Adator #%OA$, which is resonsible for
object acti*ation4deacti*ation, maing object ids to actual object
imlementations.
=aming /er*ice, a standard ser*ice in CORBA that lets remote
clients find remote objects on the networks, and
Inter(ORB %rotocol #IIO%$.
)his figure shows how a one(method distributed object is shared between a
CORBA client and ser*er to imlement the classic >?ello @orld>
alication.

A one&metho' 'istribute' object share' bet(een a CORBA client an' server)
Architectural descrition5
Any relationshi between distributed objects has two sides5 the client and the ser*er. )he
ser*er ro*ides a remote interface, and the client calls a remote interface. )hese
relationshis are common to most distributed object standards, including R!I and
CORBA. =ote that in this conte3t, the terms client an' server 'efine object&level
rather than application&level interaction&&any application coul' be a server for some
objects an' a client of others) In fact, a single object could be the client of an interface
ro*ided by a remote object and at the same time imlement an interface to be called
remotely by other objects.
On the client side, the alication includes a reference for the remote object. )he object
reference has a stub method, which is a stand(in for the method being called remotely.
)he stub is actually wired into the ORB, so that calling it in*okes the ORB:s connection
caabilities, which forwards the in*ocation to the ser*er.
On the ser*er side, the ORB uses skeleton code to translate the remote in*ocation into a
method call on the local object. )he skeleton translates the call and any arameters to
their imlementation(secific format and calls the method being in*oked. @hen the
method returns, the skeleton code transforms results or errors, and sends them back to the
client *ia the ORBs.
Between the ORBs, communication roceeds by means of a shared rotocol, IIO%((the
Internet Inter(ORB %rotocol. **O, which is based on the standard )C%4I% internet
rotocol and works across the Internet, defines ho( CORBA&compliant ORBs pass
information bac$ an' forth. 'ike CORBA and I&', the IIO% standard is defined by
O!", the Object !anagement "rou. **O allo(s clients using a CORBA pro'uct
from one ven'or to communicate (ith objects using a CORBA pro'uct from
another ven'or thus permitting interoperability+ (hich is one of the goals of the
CORBA stan'ar')
In addition to these simle distributed object caabilities, CORBA(comliant ORBs can
ro*ide a number of otional ser*ices defined by the O!". )hese include ser*ices for
looking u objects by name, maintaining ersistent objects, suorting transaction
rocessing, enabling messaging, and many other abilities useful in today:s distributed,
multi(tiered comuting en*ironments. /e*eral ORBs from third(arty *endors suort
some or all of these additional caabilities. )he ORB ro*ided with .a*a I&' suorts
one otional ser*ice, the ability to locate objects by name.
Interface &efinition 'anguage #I&'$
)he ser*ices that an object ro*ides are gi*en by its interface.
Interfaces are defined in O!":s Interface &efinition 'anguage #I&'$.
I&' is indeendent of any rogramming language.
!aings from I&' to secific rogramming languages are defined as
art of the CORBA secification. !aings for C, C88, /malltalk,
Ada, COBO', and .a*a ha*e been aro*ed by O!".
)he synta3 of both .a*a and I&' were modeled to some e3tent on C8
8, so there are a lot of similarities between the two in terms of synta3.
?owe*er, there are differences between I&' and .a*a.
In I&', you declare only the names and tyes for interfaces, data members, methods,
method arguments etc. Aou do not include the method imlementations.
)he method imlementations are created in imlementation language you choose
after you6*e used an I&' comiler #idlj is the I&' comiler for .a*a$ to con*ert your
I&' interface to your target language. @hen you run the idlj comiler o*er your
interface definition file, it generates the .a*a *ersion of the interface, as well as the
class code files for the stubs and skeletons that enable your alications to hook into
the ORB.
I&' includes, like C88, non(class data structure definitions like structs, unions etc.
#these are not art of .a*a$.
!ethod arameters in I&' include modifiers that secify whether they are inut,
outut, or inut4outut *ariables. In .a*a, all rimiti*e data tyes are assed by *alue,
and all objects are assed by reference.
An I&' file can include multiple public interfaces. .a*a allows multile inner
classes within a single ublic class definition and multile nonublic classes er file,
but only a single public class can be 'efine' in a given !ava file)
!odules, which are similar to .a*a ackages, can be nested within other modules in
the same I&' file. In .a*a, you can define a class only within a single ackage in a
single .a*a file.
Object Request Broker #ORB$
)he core of the CORBA architecture is the ORB. 9ach machine
in*ol*ed in a CORBA alication must ha*e an ORB running in
order for rocesses on that machine to interact with CORBA
objects running in remote rocesses.
Object clients and ser*ers make requests through their ORBs and
the remote ORB locates the aroriate object and asses back the
object reference to the requestor.
)he ORB ro*ides the communication infrastructure needed to
identify and locate objects, handles connection management, etc.
)he ORBs communicate with each other *ia the IIO%.
Requests made on the client stub are transferred from the client6s ORB to the
ORB ser*icing the imlementation of the target object. )he request is assed onto
the imlementation through its skeleton interface.
Once you run the idlj comiler, you can use the skeletons it generates to ut
together your ser*er alication. In addition to imlementing the methods of the
remote interface, your ser*er code includes a mechanism to start the ORB and
wait for in*ocation from a remote client.
/imilarly, you use the stubs generated by the idlj comiler as the basis of your
client alication. )he client code builds on the stubs to start its ORB, look u the
ser*er using the name ser*ice ro*ided with .a*a I&', obtain a reference for the
remote object, and call its method.
=aming /er*ice
&efines how CORBA objects can be looked u by a name. It is a Common
Object Service (COS) and allows an object to be ublished using a symbolic name
and allows clients to obtain references to the object using a standard A%I.
)he CORBA naming ser*ice ro*ides a naming structure for remote objects.
IIO%
)he CORBA standard includes secifications for inter(ORB
communication rotocols that transmit object requests between
*arious ORBs running on the network.
)he rotocols are indeendent of the articular ORB imlementations running at
either end. An ORB imlemented in .a*a can talk to an ORB imlemented in C,
as long as they are both comliant with the CORBA standard. )he inter(ORB
rotocol deli*ers messages between two ORBs. )hese messages might be method
requests, return *alues, error messages etc. )he inter(ORB rotocol #IIO%$ also
deals with differences between two ORB imlementations, like machine(le*el
byte ordering etc. As a CORBA de*eloer, you don6t ha*e to be concerned with
the low(le*el communication rotocol between ORBs. If you want two ORBs to
talk, just make sure they both seak the same inter(ORB rotocol #IIO%$.
)he Inter(ORB %rotocol #IIO%$ is an inter(ORB rotocol based
on )C%4I% and so is e3tensi*ely used on the Internet.
%OA
CORBA Server Object
OA
ORB
)he %OA connects the ser*er object imlementation to the
ORB. It e3tends the functionality of the ORB and some its
ser*ices include5 acti*ation and deacti*ation of the object
imlementations, generation and management of object
references, maing of object references to their
imlementations, and disatching of client requests to ser*er
objects through a skeleton.
=ote5 <ollow the link5
CORBA An Example (!atest "ersion) within the course 7R'5
htt544www.unf.edu4Bsahuja4cisC1,24cisC1,2.html for an e3amle on
creating a comlete CORBA alication.