A CORBA environment is based on client applications finding and using objects that
provide a desired function. The objects typically represent something in the
real world, for example shopping carts, and are hosted by servers (typically
CORBA servers or EJB servers). The type of object is defined by it's interface
and the semantics defined for that interface. There can be many instances
of an object (with the same interface and semantics), but representing different
entities. CORBA provides the Interface Definition Language (IDL) to define
object interfaces, and ORBs to provide access to objects through a distributed
environment. The binding of an object's interface to a specific
implementation is handled in the server environment
Conceptual view of a C++ CORBA environment. This figure shows the conceptual elements in a C++ CORBA environment, such as ORBs, object adapters, and implementations. For more information, see the text following the figure.
A CORBA environment comprises the following elements:
- Client environment
- The client runtime environment enables CORBA client applications to access
server implementation objects. The client environment can be any of the following:
- A WebSphere CORBA C++ client or server (written with the CORBA C++ SDK)
- Java code in a WebSphere J2EE Client or Application Server
- A non-IBM-ORB-based CORBA client or server.
- Client programming languages
- WebSphere CORBA clients can be developed in C++. Also, Enterprise JavaBeans
hosted by a WebSphere EJB server, as a CORBA client, can access server implementation
objects hosted by CORBA servers. 3rd-party CORBA clients can be developed
in C++, ActiveX, Java, or other languages supported by the CORBA client programming
model. IDL language-bindings include COBOL.
- Object
- From the client's point of view, a CORBA object is an entity with an object
reference that provides the operations defined in its interface. These operations
are always available to the client, from the time the object instance is created
until the time it is destroyed.
- Client stub
- To the client, the object on the server appears as if it resides in the
client program. This is accomplished by using a client-side stub object. The
stub object has the same interface as the server-side object it represents,
but does not directly implement the object's methods. Instead, the stub object
translates a method invocation into a format that is communicated over the
ORB to the server. The server then finds the target servant object,
which executes the actual method implementation.
When a client wants to
call a method on a server object, it creates an object reference,
a pointer to the servant object, and stores it in the stub object.
- Server implementation (servant) object
- The server implementation object (also known as a servant object)
is visible only to the server. The servant implementation is the executing
CPU and memory resource that performs an object's operation. The client only
knows that it invoked an operation defined on the object's IDL interface,
and the response came back.
- Object reference
- An object reference contains information that is used to identify a target
object. For example, a client-side stub object (as an object reference) contains
information to locate the target server and the target servant object within
that server.
An interoperable object reference (IOR) is a distributed
object pointer that allows objects to communicate across network boundaries.
IORs provide a platform- and vendor-independent object reference. The representation
of an IOR depends on where it is used. For instance, it is represented in
a wire-level message format when it is being sent between ORBs and in an object
format when it is stored in a stub object. A client can convert an IOR into
a string, save it to a file, and then terminate. When the client is activated
again, the IOR can be read from the file, and then converted back into an
object reference.
- CORBA-compliant Object Request Broker (ORB)
- The CORBA-compliant ORB enables clients to communicate with the application
server. The ORB sends local client requests across a network by using the
Internet Inter-ORB Protocol (IIOP), which is a TCP/IP-based communications
protocol with CORBA-defined message exchanges. Separate ORBs resides at each
end of the communication channel.
- Object adapter
- The object adapter acts as a mediator between the communications framework
of the ORB and the servant objects that reside on a server. When the server-side
ORB receives a request, the ORB passes the request to the object adapter.
The object adapter analyzes each request received by the ORB and dispatches
it to the servant object that is the target for the request. The object adapter
class provides methods that allow the server application to participate in
the exporting and importing of object references and the selection of threads on
which remote requests are dispatched.
- Server
- The server provides the runtime environment in which a servant object
can exist. For example, it initializes the ORB and object adapter, creates
a servant object, gives it a name in an appropriate naming context in the
naming service. This makes it possible for the client to find and use the
servant. The server puts itself into an infinite wait loop, during which the
ORB can transmit requests to and from the servant object that the server hosts.
If the server is shut down, it removes the servant object from the runtime environment
and cleans up the resources used to support the servant object.
- IIOP
- The client and server ORBs communicate using the CORBA Internet
Inter-ORB protocol (IIOP), which is a TCP/IP-based protocol with CORBA-defined
message exchanges. CORBA uses the General Inter-ORB Protocol (GIOP) to define
the format of messages and uses IIOP to map between GIOP messages and TCP/IP
messages. IIOP allows ORBs to communicate with each other and enables them
to use the Internet for distributed object communication.
- Naming service
- The naming service forms the lookup directory for a distributed system.
It provides an interface for binding and resolving names to object references.
When an object is created, its object reference can be bound to a name in
the naming service. Any other object with access to the naming service can
use the name to return the associated object reference. The naming service
implements the CosNaming service, the standard naming service defined by the
CORBA services specification.
A CORBA client can use the Interoperable Name
Service (INS) specification to call resolve_initial_references("NameService")
on the client ORB to establish a root naming context for the naming service.
- Interface Definition Language (IDL)
- The CORBA Interface Definition Language (IDL) enables clients and servers
to have a platform-independent and language-neutral standard on which to base
their communications.
Using IDL, application developers can specify the
public interface to a CORBA class or Enterprise JavaBean (as the servant class).
For a CORBA server implementation, the application developer typically creates
the IDL "by hand". For an Enterprise JavaBean a tool is used to
create the IDL from the interface/class file. The IDL definition of a servant
is used to generate the client stub. An IDL compiler generates the code necessary
to use an interface with a specific programming language.
Serializable
objects used in an Enterprise JavaBean's interface are expressed in IDL as
CORBA valuetypes. Therefore every Java serializable to be passed by a CORBA
client as a parameter or return value for an Enterprise JavaBean must be re-implemented
in the language of the client. To simplify the development of CORBA clients
of Enterprise JavaBeans, you should try to minimize the range of Java serializables
used in the Enterprise JavaBean's interface.
- Implementation repository
- The implementation repository is a persistent data store of ImplementationDef
objects, each representing a logical server that has been registered.
WebSphere Application Server takes care of the communications protocol,
ORB, and object references. WebSphere Application Server supports RMI-IIOP.
In addition, WebSphere Application Server implements JNDI using a Directory
which also supports CORBA CosNaming bindings, making WebSphere Enterprise
JavaBeans visible to CORBA clients.