Professional Documents
Culture Documents
The CORBA Architecture: Service Description
The CORBA Architecture: Service Description
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
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.
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.
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 don’t 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).