Next: Client and Server Perspectives
Up: ON THE USE OF
Previous: MOTIVATION
The most fundamental component of CORBA is the
Object Request Broker (ORB) whose task is
to facilitate communication between objects.
Given an Interoperable Object Reference (IOR),
the ORB is able to locate target objects and transmit
data to and fro
remote method invocations.
The interface to a CORBA object is
specified using the CORBA Interface
Definition Language (IDL).
An IDL compiler translates the IDL definition
into an application programming language,
such as C++ or Java,
generating IDL stubs and skeletons
that respectively provide the framework
for client-side and server-side proxy code.
Compilation of applications incorporating IDL
stubs provides a strongly-typed
Static Invocation Interface (SII).
Conversely,
a more flexible communication mechanism
can be established through the use of
the Dynamic Invocation Interface (DII)
and the Dynamic Skeleton Interface (DSI)
allowing objects to be created without
prior knowledge of the IDL interface.
In such cases, a description of the interface
is retrieved at runtime from an Interface Repository (IFR),
a database containing the pertinent meta-data.
Requests and responses between objects
are delivered in a standard format defined
by the Internet Inter-ORB Protocol (IIOP),
a communications protocol which
adheres to the CORBA General Inter-ORB Protocol
(GIOP) specification and, as such,
acts as the base for CORBA interoperability on
the internet.
Requests are marshaled in a platform
independent format,
by the client stub (or in the DII),
and unmarshaled on the server-side
into a platform specific format by the
IDL skeleton (or in the DSI) and the
object adaptor, which serves as a mediator
between an object's implementation,
the servant, and its ORB,
thereby decoupling user code
from ORB processing.
In its mandatory version, the
Portable Object Adaptor (POA)
provides CORBA objects with a common set
of methods for accessing ORB functions,
ranging from user authentication to object
activation and object persistence.
It's most basic task, however,
is to create object references and to
dispatch ORB requests aimed at target objects
to their respective servants.
The characteristics of the POA
are defined at creation
time by a set of POA policies.
A server can host any number of
POAs, each with its own set of policies
to govern the processing of requests.
Among the more advanced features of the
POA is the servant manager
which assumes the role of reactivating
server objects (servants) as they are required.
It also provides a mechanism to save and restore
an object's state.
This, coupled with the use of the
Implementation Repository (IMR),
that handles
the automated start and restart of servers,
realizes object persistency.
Requests for server reactivation can,
alternatively, be
delegated to a single default servant
which provides implementations for many objects,
thereby increasing the
scalability for CORBA servers.
Figure:
The CORBA client-server architecture
|
Fig. shows the components
of the CORBA architectural model.
The ORB core is implemented as a runtime
library linked into client-server applications.
Subsections
Next: Client and Server Perspectives
Up: ON THE USE OF
Previous: MOTIVATION
Jan Chrin
2001-11-09