The tried and true wrapper: CORBA

By Daniel Rubio
[Posted by Jack Vaughan]

If interoperability was a necessity to enterprise software in the pre-web services era, CORBA (Common Object Request Broker Architecture) was in all likelihood at the top of the list for many. Similar to messaging, which we discussed in the last entry, CORBA has had wide acceptance due to the different language/platform support it has garnered throughout the years, including : Java/Java EE, C++, C, COBOL, Python, among others.

And even though the Microsoft product line has lagged in CORBA support, partly due to a competing and in-house technology named DCOM which came out around the same time as CORBA, a series of alternatives have come to fruition in the .NET camp, making CORBA a viable alternative for Java/.NET interoperability projects.

CORBA’s core concepts can be summarized in : ORB’s, IDL and IIOP. An ORB(Object Request Broker) serves as a dispatcher for CORBA-type requests, just like a web server does for web pages. IDL (Interface Description Language) on the other hand is a language-neutral syntax used for describing CORBA services, just like WSDL is a platform neutral syntax for describing web services. (For those wanting a little more background on the similarities between IDL/WSDL, an excellent post by Steve Vinoski can be found at: Weighing in on IDL vs. WSDL). Finally, IIOP (Internet Inter-ORB Protocol) is the wire protocol used by CORBA, that while a little bit arcane to mention as core, is an important aspect when attempting to use CORBA from .NET.

Before we continue our discussion, you should be aware that CORBA is a very powerful and hence complex technology, so it can take some time to become acquainted with its inner workings, nevertheless I will do my best to get you up and running with a very basic CORBA Java/.NET app.

Since Java’s JDK already comes bundled with an ORB and IDL compiler, we will use both tools to create a server side CORBA application, in the case of .NET, we will make use of an open source library named IIOP.NET to make requests from a .NET application to a Java-CORBA application.

Lets start by defining a CORBA application contract in IDL, the following listing illustrates such a contract:

Listing 1.1 CORBA-IDL Contract

module interopApp
{
  interface Demo
  {
    string interopMethod();
  };
};
Don’t dwell to much on the details, just realize the contract indicates the application will have a method by the name interopMethod that will return a string value. With this contract in-hand, you then need to feed it through an IDL compiler to generate language specific supporting CORBA classes. In Java’s case, execute the following from the command line : idlj -fall interopApp.idl, where idlj is the compiler located under the JDK’s bin directory and interopApp.idl is the file containing the contract.

Upon execution, an additional folder with 6 supporting Java/CORBA classes will be created, compile them as you would any other Java classes. These last classes are in effect CORBA’s wrapper for your Java application code, which would look something like the following class:

Listing 1.2 Java-CORBA implementation class

import interopApp.*;

public class DemoImpl extends DemoPOA
{   public DemoImpl() {
    System.out.println( “Called DemoImpl constructor”);
  }

  public String interopMethod() {
      // Hardcode String, other logic or DB access could be used here
      String response = “At ” + new java.util.Date() + ” : Interop String obtained from Java-CORBA server”;
      return response;
  }
}
The import statement in this case is used to tap the generated CORBA classes, while the class in itself inherits its behavior from one of the supporting classes named DemoPOA. The important thing to take note of here is the exposed CORBA method interopMethod is overridden to contain any type of Java logic required by the application.

Next, you need to create a server class to associate this particular application code with a CORBA-ORB, the following listing shows such a server:

Listing 1.3 Java-CORBA Server class

import org.omg.CORBA.ORB;
import org.omg.CosNaming.*;
import org.omg.PortableServer.*;

import interopApp.*;

public class Server
{
  public static void main(String args[]) {
    try {
      String obj_name = “javanetapp”;

      //Create and initialize the ORB
      ORB orb = ORB.init(args, null);
      //Reference to rootpoa & activate the POAManager
      POA rootpoa
      = POAHelper.narrow(orb.resolve_initial_references(”RootPOA”));
      rootpoa.the_POAManager().activate();

      //Create servant and register it with the ORB
      DemoImpl demo_serv = new DemoImpl();

      //Object reference from the servant
      org.omg.CORBA.Object ref = rootpoa.servant_to_reference( demo_serv );
      Demo demoServ = DemoHelper.narrow( ref );

      //Root naming context
      org.omg.CORBA.Object naming
      = orb.resolve_initial_references(”NameService”);
      NamingContextExt nctx = NamingContextExtHelper.narrow(naming);

      //Bind Object reference in naming
      NameComponent path[] = nctx.to_name( obj_name );
      nctx.rebind(path, demoServ)

      //Run a separate thread
      orb.run();
    }
    catch (Exception x) { }
   }
}
The most relevant aspects of this last server class are that it uses the DemoImpl class, and its association to the name javanetapp — using the obj_name string — as a network identifier. Finally, you need to activate the Java ORB so the application can be accessed across the network. From the command line type tnameserv -ORBInitialPort 2007 — this will activate CORBA’s naming service on port 2007 — and then type java Server -ORBInitialPort 2007 — where Server is the previous class — to expose the CORBA access point.

At this juncture, you have a full-fledged CORBA enabled application accessible through the name javanetapp, so lets take a final crack at tapping this application from a .NET environment. Accessing CORBA services is a little simpler than exposing them, while you will need to pass the IDL through the compiler provided in IIOP.NET to generate supporting classes, you won’t need to wire-up up an ORB. The following listing illustrates what a CORBA .NET client using IIOP.NET would look like:

Listing 1.4 .NET-CORBA Client class using IIOP.NET

using System;
using System.Runtime.Remoting.Channels;
using Ch.Elca.Iiop;
using Ch.Elca.Iiop.Services;
using omg.org.CosNaming;
// Route to IDL supporting files
using interop.Demo;
namespace Interop.Demo {

   public class Client {

         public static void Main(string[] args) {
            try {
                string nameServiceHost = “localhost”;
                int nameServicePort = 2007;

                //Register channel
                IiopClientChannel channel = new IiopClientChannel();
                ChannelServices.RegisterChannel(channel);

                //Access CORBA/COS naming service
                RmiIiopInit init = new RmiIiopInit(nameServiceHost, nameServicePort);
                NamingContext nameService = init.GetNameService();
                NameComponent[] name = new NameComponent[] { new NameComponent(”javanetapp”, “”) };
                //Get the reference to Demo
                Demo interopClient = (Demo)nameService.resolve(name);
                //Call interopMethod()
                String result = interopClient.interopMethod();
                Console.WriteLine(”Result: ” + result);
            } catch (Exception e) {
                Console.WriteLine(”Exception: ” + e);
            }
        }
    }
}
Relevant sections in this last listing include : the use of Ch.Elca.Iiop classes — which is the actual namespace used by the IIOP.NET library — and the use of localhost,servicePort and javanetapp for locating the CORBA service, as activated on the Java server side ORB.

With this we conclude our short overview of CORBA as a Java/.NET interoperability option. In the final entry of this series on using non-webservices for interoperability, we will take a look at a non-network approach to interoperability: JNI and DLL’s.

Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics at webforefront.com.


Leave a Reply