[Enterprise Extensions only]

An overview of basic CORBA concepts

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

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:
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.