CORBA Concepts

Common Object Request Broker Architecture (CORBA) is a long-established standard that enables interoperation between dissimilar computing systems.

This standard is described by specifics published by the Object Management Group (OMG), a global industry consortium consisting of hundreds of large enterprises, institutions, and product vendors.

CORBA versus Web Services: Similar Yet Different

CORBA is similar to Web services and JAX-RPC in the following ways:

• CORBA allows software components to communicate with one another over a network.

• CORBA allows software components written in different programming languages to communicate with one another.

• CORBA allows software components running on different operating systems and hardware platforms to communicate with one another.

• CORBA is an international standard supported by a very large body of products and service vendors.

• CORBA clients make a local call to a stub object that forwards the actual call over the network to the server.

That’s where the commonality ends; CORBA is significantly different from Web services and JAX-RPC in the following ways:

• CORBA does not use XML-based SOAP messages for communication. A CORBA message is well specified but in binary encoding.

• CORBA does not operate over HTTP as its transport protocol. CORBA has its own General Inter-ORB Protocol (GIOP), with a specialization of it for TCP/IP networks called Internet Inter-ORB Protocol (IIOP).

• CORBA requires a language-specific binding to be available before client or server code can be written in a specific programming language.

• CORBA requires the service of a special component called an Object Request Broker (ORB) to work. Many ORB products are available - both commercial and Open Source.

• CORBA is a matured standard that has withstood the test of time (over two decades) in the computing industry.

Because of the maturity of CORBA, it is often seen as one of the premier open interface technologies to the J2EE enterprise integration system tier. Specifically, CORBA is frequently used to access functionality built into legacy mainframe, microcomputer, or customer purpose processing subsystems. You can contrast this with Web services, a modern access technology focused around business-to-business and business-to-consumer application integration.

The next section covers some key concepts and terminology specific to CORBA interoperation, enabling you to communicate with CORBA developers during Geronimo administration tasks.

Interface Definition Language

A CORBA client application invokes the feature of a CORBA server component by calling methods on a published interface on the server component. This is identical in concept to the Web service SEI. However, instead of being described in WSDL, the interface is described in CORBA Interface Definition Language (IDL)

IDL is programming-language neutral. An IDL file can describe the interfaces and methods that are available from a CORBA service component. All CORBA implementations will provide tools that can convert the IDL to programming-language-specific bindings. A binding is essentially generated code that implements the stub and skeleton framework. Figure 14-9 shows the relationship between IDL and language bindings.

Figure 14-9: IDL compiler and programming-language-specific binding

In Figure 14-9, the IDL file is processed by an IDL compiler to generate code (binding) in the supported programming language. The generated code is then compiled linked with the client’s (or server’s) logic code to access the CORBA object remotely. Creating a CORBA client requires a separate code-generation (from IDL) phase and then a compilation phase.

ORB and CORBA Services

During IDL code generation, the IDL compiler actually creates a stub object on the client side (similar to JAX-RPC for Web services) and then a skeleton object on the server side (similar to the tie of JAX-RPC).

Unlike JAX-RPC, however, the stub does not create SOAP messages, and it does not communicate with the skeleton directly. Instead, they talk to a CORBA system component called an Object Request Broker (ORB). The role of an ORB is to transparently mediate between the client and the services that are available to it. The CORBA client invokes the services as if they are local to the client. The stub object forwards the invocation information to the ORB. It is the ORB that actually locates the appropriate service physically and brokers the call. On the service end, the service logic is implemented against the generated binding’s skeleton object. The service object thinks that the call is local, but it is actually a forwarded call through the skeleton, from an ORB. One ORB may handle the call forwarding all by itself, or it may work with other ORBs in locating the service; this detail is opaque to the client and the service. Figure 14-10 shows the action of an ORB.

Figure 14-10: CORBA ORB brokering a remote call

In Figure 14-10, the client’s local call to a method on the service interface is being intercepted by the stub- a part of the binding. The stub object passes the call to the ORB. The ORB, in turn, forwards the call to the service, potentially using the service of another ORB. The call is received at the service end by the skeleton binding code. This skeleton binding code invokes the service method locally within the service implementation.

The CORBA specification also includes a set of standard CORBA Services. Some of these services are mandatory, and are implemented by every compliant ORB vendor. For example, the Naming service, a service providing for a client to locate a remote CORBA component by name, is standard with every ORB implementation.

GIOP and IIOP

In early versions of CORBA, ORBs from different vendors were not able to communicate with one another. This posed a major problem for a supposedly universal, interoperable mechanism. As a major design goal of CORBA 2.x, all modern ORBs are now required to be interoperable with one another. This interoperation is achieved through a common over-the-wire protocol called General Inter-ORB Protocol (GIOP). GIOP specifies how ORBs must communicate over a network. When the network is a TCP/IP network (such as the Internet), a specialization of GIOP called Internet InterORB Protocol (IIOP) is used.

Simplifying Java-Based CORBA Interoperation

To support CORBA interoperation, Java has incorporated an ORB as part of its platform since the early days of JDK 1.1. The OMG group also views the Java platform as a very important server implementation vehicle and has worked with the Java community to improve the interoperability between CORBA and Java components.

Java’s native means to communicate between distributed Java components is Remote Method Invocation (RMI). RMI utilizes a proprietary Java Remote Method Protocol (JRMP) to communicate between components. To facilitate interoperation with CORBA-based components, RMI-IIOP as introduced with JDK 1.2. RMI-IIOP utilizes IIOP as the protocol between distributed Java components, instead of the proprietary JRMP. As a result, a Java-based client can access CORBA service objects on any platform using RMI styled semantics. Using RMI-IIOP, the Java programming language can also be used to create service components that can be exposed as CORBA components - without having the hassle with binding generation from IDL and source-based compilation. Figure 14-11 shows how RMI-IIOP facilitates CORBA interoperation.

Figure 14-11: RMI-IIOP supporting both CORBA client access and RMI client access

In Figure 14-11, the business-tier EJB component is exposed via RMI-IIOP as a CORBA component supporting the EJB interface. In fact, this is what Geronimo as a J2EE 1.4 compatible server is able to do - exposing a J2EE EJB as a CORBA component - to be accessed by CORBA clients.

Non-Java CORBA clients can generate an IDL file from the exposed RMI interface using the rmic tool supplied with JDK 1.4. This IDL file can then be used to generate language-specific binding in the creation of a client. Java-based clients, on the other hand, can use pure RMI syntax to access the CORBA component via IIOP.