1

111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
1111111The 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
interoperate.
CORBA is a standard defined by the OMG (Object Management Group). It describes an
architecture, interfaces, and protocols that distributed objects can use to interact with each
other.
Part of the CORBA standard is the Interface Definition Language (IDL), which is an
implementation-independent language for describing the interfaces of remote objects.
The OMG comprises over 700 companies and organizations, including almost all the
major vendors and developers of distributed object technology, including platform,
database, and application vendors as well as software tool and corporate developers.
Java IDL is an implementation of the standard IDL-to-Java mapping and is provided by
Sun in version 1.3 of Java 2 and is compliant with CORBA 2.x specification. Java IDL
provides an Object Request Broker, or ORB.
The ORB is a class library that enables low-level communication between Java-IDL
applications and other CORBA-compliant applications.
Like RMI, Java IDL gives you a way to access remote objects over the network. It also
provides tools you need to make your objects accessible to other CORBA clients. If you
export a Java class using Java IDL, you can create an object from that class and publish it
through a naming/directory service.
A remote object can: find this object, call methods on it, and receive data from it, just as
if it were running on the clients local machine.
Unlike RMI, objects that are exported using CORBA can be accessed by clients
implemented in any language with an IDL binding (C, C++, Ada etc.).
The CORBA standard is extensive and provides a rich set of services.
A few of the services are:
Service
Description
Object life cycle
Defines how CORBA objects are created, removed, moved, and
copied
Naming Service
The CORBA naming service provides a naming structure for
remote objects.
Event Service Another COS that provides a supplier-consumer communication model
that creates asynchronous communication between the objects via an Event Channel. The
flow of data into the Event Channel is handled by supplier objects, while the flow of data
out of the event channel is handled by consumer objects. The Event Service supports both

the push and pull model. In the push model, supplier objects control the flow of data by
pushing it to consumers and in the pull model, consumer objects control the flow of data
by pulling data from the supplier. Instead of directly communicating with each other, the
supplier and consumer can each obtain a proxy object from the Event Channel and
communicate with it. Supplier objects obtain a consumer proxy and the consumer objects
acquire a supplier proxy.
Persistent object service
Transactions
Coordinates atomic access to CORBA objects
Concurrency Control Provides a locking service for CORBA objects in order to ensure
concurrent access
CORBA Products
Several vendors provide CORBA products for various programming languages. The
CORBA products that support the Java programming language include:
ORB
Description
The Java 2 ORB
The Java 2 ORB comes with Sun's Java 2. It is missing several
features. The main feature it has is the ability to look up an object by name.
VisiBroker for Java A popular Java ORB from Inprise Corporation. VisiBroker is also
embedded in other products. For example, it is the ORB that embedded in the Netscape
Communicator browser.
Orbix
A popular Java ORB from Iona Technologies.
CORBA Architecture
The major components that make up the CORBA architecture include the:
Interface Definition Language (IDL), which is how CORBA interfaces are defined,
Object Request Broker (ORB), which is responsible for all interactions between remote
objects and the applications that use them,
The Portable Object Adaptor (POA), which is responsible for object
activation/deactivation, mapping object ids to actual object implementations.
Naming Service, a standard service in CORBA that lets remote clients find remote
objects on the networks, and
Inter-ORB Protocol (IIOP).
This figure shows how a one-method distributed object is shared between a CORBA
client and server to implement the classic "Hello World" application.
EMBED Word.Picture.8
A one-method distributed object shared between a CORBA client and server.
Architectural description:
Any relationship between distributed objects has two sides: the client and the server. The
server provides a remote interface, and the client calls a remote interface. These
relationships are common to most distributed object standards, including RMI and
CORBA. Note that in this context, the terms client and server define object-level rather
than application-level interaction--any application could be a server for some objects and
a client of others. In fact, a single object could be the client of an interface provided by a
remote object and at the same time implement an interface to be called remotely by other
objects.

On the client side, the application includes a reference for the remote object. The object
reference has a stub method, which is a stand-in for the method being called remotely.
The stub is actually wired into the ORB, so that calling it invokes the ORB's connection
capabilities, which forwards the invocation to the server.
On the server side, the ORB uses skeleton code to translate the remote invocation into a
method call on the local object. The skeleton translates the call and any parameters to
their implementation-specific format and calls the method being invoked. When the
method returns, the skeleton code transforms results or errors, and sends them back to the
client via the ORBs.
Between the ORBs, communication proceeds by means of a shared protocol, IIOP--the
Internet Inter-ORB Protocol. IIOP, which is based on the standard TCP/IP internet
protocol and works across the Internet, defines how CORBA-compliant ORBs pass
information back and forth. Like CORBA and IDL, the IIOP standard is defined by
OMG, the Object Management Group. IIOP allows clients using a CORBA product from
one vendor to communicate with objects using a CORBA product from another vendor
thus permitting interoperability, which is one of the goals of the CORBA standard.
In addition to these simple distributed object capabilities, CORBA-compliant ORBs can
provide a number of optional services defined by the OMG. These include services for
looking up objects by name, maintaining persistent objects, supporting transaction
processing, enabling messaging, and many other abilities useful in today's distributed,
multi-tiered computing environments. Several ORBs from third-party vendors support
some or all of these additional capabilities. The ORB provided with Java IDL supports
one optional service, the ability to locate objects by name.
Interface Definition Language (IDL)
The services that an object provides are given by its interface. Interfaces are defined in
OMG's Interface Definition Language (IDL). IDL is independent of any programming
language.
Mappings from IDL to specific programming languages are defined as part of the
CORBA specification. Mappings for C, C++, Smalltalk, Ada, COBOL, and Java have
been approved by OMG.
The syntax of both Java and IDL were modeled to some extent on C++, so there are a lot
of similarities between the two in terms of syntax. However, there are differences
between IDL and Java.
In IDL, you declare only the names and types for interfaces, data members, methods,
method arguments etc. You do not include the method implementations.
The method implementations are created in implementation language you choose after
youve used an IDL compiler (idlj is the IDL compiler for Java) to convert your IDL
interface to your target language. When you run the idlj compiler over your interface
definition file, it generates the Java version of the interface, as well as the class code files
for the stubs and skeletons that enable your applications to hook into the ORB.
IDL includes, like C++, non-class data structure definitions like structs, unions etc. (these
are not part of Java).
Method parameters in IDL include modifiers that specify whether they are input, output,
or input/output variables. In Java, all primitive data types are passed by value, and all
objects are passed by reference.
An IDL file can include multiple public interfaces. Java allows multiple inner classes

within a single public class definition and multiple nonpublic classes per file, but only a
single public class can be defined in a given Java file.
Modules, which are similar to Java packages, can be nested within other modules in the
same IDL file. In Java, you can define a class only within a single package in a single
Java file.
Object Request Broker (ORB)
The core of the CORBA architecture is the ORB. Each machine involved in a CORBA
application must have an ORB running in order for processes on that machine to interact
with CORBA objects running in remote processes.
Object clients and servers make requests through their ORBs and the remote ORB locates
the appropriate object and passes back the object reference to the requestor.
The ORB provides the communication infrastructure needed to identify and locate
objects, handles connection management, etc. The ORBs communicate with each other
via the IIOP.
Requests made on the client stub are transferred from the clients ORB to the ORB
servicing the implementation of the target object. The request is passed onto the
implementation through its skeleton interface.
Once you run the idlj compiler, you can use the skeletons it generates to put together your
server application. In addition to implementing the methods of the remote interface, your
server code includes a mechanism to start the ORB and wait for invocation from a remote
client.
Similarly, you use the stubs generated by the idlj compiler as the basis of your client
application. The client code builds on the stubs to start its ORB, look up the server using
the name service provided with Java IDL, obtain a reference for the remote object, and
call its method.
Naming Service
Defines how CORBA objects can be looked up by a name. It is a Common Object
Service (COS) and allows an object to be published using a symbolic name and allows
clients to obtain references to the object using a standard API.
The CORBA naming service provides a naming structure for remote objects.
IIOP
The CORBA standard includes specifications for inter-ORB communication protocols
that transmit object requests between various ORBs running on the network.
The protocols are independent of the particular ORB implementations running at either
end. An ORB implemented in Java can talk to an ORB implemented in C, as long as they
are both compliant with the CORBA standard. The inter-ORB protocol delivers messages
between two ORBs. These messages might be method requests, return values, error
messages etc. The inter-ORB protocol (IIOP) also deals with differences between two
ORB implementations, like machine-level byte ordering etc. As a CORBA developer, you
dont have to be concerned with the low-level communication protocol between ORBs. If
you want two ORBs to talk, just make sure they both speak the same inter-ORB protocol
(IIOP).
The Inter-ORB Protocol (IIOP) is an inter-ORB protocol based on TCP/IP and so is
extensively used on the Internet.
POA

CORBA Server Object

POA
ORB
The POA connects the server object implementation to the ORB. It extends the
functionality of the ORB and some