Building a Distributed Object System with .NET and J2EE Using IIOP.NET

• Download IIOP.NET source (includes example) - 315 Kb
• Download example source (without IIOP.NET) - 10 Kb

Introduction

In Microsoft's vision, the next generation of distributed systemswill communicate with WebServices. WebServices are great when it comesto integrate heterogeneous loosely coupled systems, but they have theirlimitations too: they have no support for remote object references. Inpractice, they are stateless and closer to a remote method call than toa distributed object system. Furthermore, SOAP and XML are by no meansa compressed format and tend to be quite verbose.

.NET and J2EE are two similar but disjointed worlds: they currentlycan interact together only using WebServices. Both platforms offergreat mechanisms for building tightly coupled distributed objectsystems: .NET's Remoting and Java's RMI, but sadly these rely onincompatible standards. Luckily, .NET's remoting is highlyconfigurable: a different formatter for the serialization anddeserialization of the objects together with a different transportchannel can be easily provided.

Fig.1: Overview of a .NET channel

This article shows how the .NET and J2EE platforms can tightlyinteroperate together, as it is often needed when developingdistributed enterprise applications. For this purpose, we use anopen-source custom remoting channel called IIOP.NET.

About IIOP.NET

IIOP.NET is a .NET remoting channel based on the IIOP protocol. IIOPis the protocol defined by the CORBA standard, the same used by Java'sRMI/IIOP. IIOP.NET acts as an ORB (a CORBA object request broker); itconverts .NET's type system to CORBA's type system and back, making theobjects defined in your application accessible to other ORBs. RMI/IIOPimplements a subset of the ORB functionalities (due to some limitationsin Java's type system) and provides the same features as IIOP.NET forthe J2EE platform.

Fig.2: Overview of a the distributed object system

Using IIOP.NET is almost as simple as using the built-in remoting.The following example will show you how to access a .NET service fromJava using IIOP.NET.

IIOP.NET is an open-source project hosted on sourceforge (http://iiop-net.sourceforge.net/). It was developed by Dominic Ullmann as part of his diploma thesis at ETH-Z; further work is now sponsored by his current employer (http://www.elca.ch).

Not surprisingly, IIOP.NET is not the only software you can use forthis purpose. First, the open-source project Remoting.Corba is quitesimilar in its goals, but has no generator for creating the IDL from adll and currently does not support CORBA's valuetypes; second, Janevafrom Borland promises to do the same, but is neither free nor availableyet (should be released in summer '03). We choose IIOP.NET because itis free, currently available, and has a tool to generate the IDLautomatically.

The example: accessing a generic collection service

Your problem: you just implemented a great service using .NET, butyour customer insists on using a Java client; You cannot useWebServices, because the client software needs to keep references tothe single objects on the server: this is just not possible usingWebServices unless you implement your own naming service, leasemanager, and distributed garbage collection. A more appropriateapproach is to use RMI/IIOP on the Java side and IIOP.NET on the .NETside.

This article is constructed around a non-trivial example (theGenericCollection tutorial in the IIOP.NET release: a .NET serverprovides access to a set of collections consisting of key / valuepairs. A client can grab a collection, modify it by adding more pairs,or querying it about the pairs it contains. This requires the client tohold references to the objects on the server.

For the sake of simplicity, we will concentrate on the object distribution, and skip all the concurrency-related problems.

Step 1: install IIOP.NET

You will find a few directories:

• IIOPChannel contains the channel code
• CLSToIDLGenerator contains a generator to create the IDL definition files from a .NET assembly
• Examples contains the examples and tutorials code. The one presented in this article is GenericCollections.

To be able to use IIOP.NET, you need Microsoft's .NET Frameword (1.0or 1.1) and the C# compiler. The Java part of the demo requires anyJava system supporting RMI/IIOP (e.g. Sun's Java SDK 1.4).

To install IIOP.NET, first unpack it; them copy the ir.idl and orb.idl files from your Java SDK lib directory into IIOP.NET's IDL directory. Compile by executing nmake in the main directory.

Step 2: define the service

When you define a .NET service, you have the choice between objects marshalled by reference, which subclass MarshalByRefObject, and objects marshalled by value, which implement ISerializable or are decorated with SerializableAttribute. In the GenericCollections example, the objects (without implementation) are defined as:

Collapse

namespace Ch.Elca.Iiop.Demo.StorageSystem {
         [Serializable]
         public struct Entry {
                 public string key;
                 public string value;
         }
         public class Container: MarshalByRefObject {
                 public Container() {...}
                 public Entry[] Enumerate() {...}
                 public void    SetValue(string key, string value) {...}
                 public void    SetEntry(Entry e) {...}
                 public String  GetValue(string key) {...}
         }
         public class Manager: MarshalByRefObject {
                 public Manager() {...}
                 public Container   CreateContainer() {...}
                 public Container[] FilterContainers(Entry[] filter) {...}
                 public void        DeleteContainer(Container c) {...}
         }
}

In practice, Manager and Container objects stay on the server. Theclient merely receives a remote reference to them and works with aproxy object that serializes (i.e. encodes) the method calls andforwards them to the server. On the other hand, Entry structures areentirely copied to the client, which works with its own Entry clones.

You can now make the managed object available to the rest of the (IIOP) world:

Collapse

public class Server {
    [STAThread]
    public static void Main(string[] args) {
        // register the channel

        int port = 8087;
        IiopChannel chan = new IiopChannel(port);
        ChannelServices.RegisterChannel(chan);
        // publish the adder

        Manager manager = new Manager();
        string objectURI = "manager";
        RemotingServices.Marshal(manager, objectURI);
         
        Console.WriteLine("server running");
        Console.ReadLine();
    }
}

The above code installs an ORB listening on the URI iiop://localhost:8087/,and registers a manager instance under the name "manager" to allchannels. The manager object will handle all requests (in fact, this isa server-activated singleton object).

Step 3: create the IDL description

To be able to access these objects from Java, their definition mustbe made available. Because Java does not understand .NET's metadata, wecreate a description of the objects using the IDL format using theIIOP.NET's CLSToIDLGenerator tool; this tool takes asinput one type and one assembly, and emits the corresponding IDLdefinition file. It also recursively emits the definitions for allother types used.

Calling

Collapse

CLSToIDLGenerator Ch.Elca.Iiop.Demo.StorageSystem.Manager Service.dll

generates the description for the Manager type (the full type nameis required) defined in the Service.dll assembly and for all othertypes used by Manager. Manager.idl, Container.idl, and Entry.idl arecreated.

Step 4: create the Java stubs from the IDL

The Java SDK provides the idlj compiler to generate the java stubs for the IDL files. Note that you will need two more IDL files present in your Java SDK: orb.idl and ir.idl, which contain all the predefined CORBA objects for your Java platform.

Step 5: implement the client

You can now implement a client, which accesses the remote objects defined previously.

Collapse

import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import Ch.Elca.Iiop.GenericUserException;
import Ch.Elca.Iiop.Demo.StorageSystem.*;

Manager m = null;
try {
         InitialContext ic = new InitialContext();
         Object obj = ic.lookup("manager");
         m = (Manager) PortableRemoteObject.narrow(obj, Manager.class);
         ... use m ...
} catch (Exception e) {
         System.out.println("Exception: " + e.getMessage());
}

This code retrieves a reference to the remote object. Now you cancall the methods defined in the remote object just like normal methods:

Collapse

Container c = m.CreateContainer();
c.SetValue("name","Patrik");

There is still one catch: you must write and implement the class EntryImpl . The Manager and Container types are accessed by reference, i.e. idlj generates a proxy that forwards all method calls to the server. The Entrystructure instead is copied to the client (this corresponds to theclasses extending marked as serializable in .NET, and to the valuetypesin CORBA): thus, you need to provide a local implementation for all itsmethods (idlj just provides an abstract class):

Collapse

package Ch.Elca.Iiop.Demo.StorageSystem;
public class EntryImpl extends Entry { }

Because Entry has no methods to be implemented(only fields), its implementation is simple and consists of an empty class definition.

Step 6: run the client and the server

As a last step, run the distributed application. First, start the server:

Collapse

D:/Demo/net:> Server
server running

and then the client:

Collapse

java -Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory 
         -Djava.naming.provider.url=iiop://localhost:8087 Client

The internet address part of the URL is passed to the JVM in order to tell RMI/IIOP where to find the naming service.

The java client will prompt you for an operation to perform. Firstinput "1" to create a new collection, and then insert a few keys andvalues, terminate with an empty key. Keep in mind that every commandyou issue, is executed on the server; in fact, by starting two clients,you will access exactly the same data.

Here's a small session log:

Collapse

Main Menu:
0. Terminate
1. Create Container
2. Select Container
1

Container Menu:
0. Return to previous menu
1. Set Entry
2. Show Entries
1
Enter an key / value pair:
  key: site
value: CodeProject

Container Menu:
0. Return to previous menu
1. Set Entry
2. Show Entries
1
Enter an key / value pair:
  key: URL
value: http://www.codeproject.com


Container Menu:
0. Return to previous menu
1. Set Entry
2. Show Entries
2
List Entries
  Entry[site] = CodeProject
  Entry[URL] = http://www.codeproject.com


Container Menu:
0. Return to previous menu
1. Set Entry
2. Show Entries
0

Main Menu:
0. Terminate
1. Create Container
2. Select Container
2

Select Containers: enter a list of key / values pairs; terminate with an empty key
  key: site
value: CodeProject
  key:

Matches:

Container 1
List Entries
  Entry[site] = CodeProject
  Entry[URL] = http://www.codeproject.com

Select container number or 0 to return to previous menu
0

Main Menu:
0. Terminate
1. Create Container
2. Select Container
0

            

Conclusions

This article has shown how to access objects created and hostedunder .NET from J2EE using IIOP.NET. The implementation of adistributed application is as simple as using only Java's RMI/IIOP. Itis obviously possible to work in the opposite way hosting the objectson J2EE and remotely accessing them from .NET: IIOP.NET includes also agenerator to create the proxies for .NET given the IDL of the objects.

IIOP.NET allows to transparently access remote objects using theCORBA standard under .NET. It is well integrated in .NET's remotingframework, and as such, that it can be used together with the otherremoting channels already available without any code change.

Remoting and RMI are the technologies available in .NET and J2EE tocreate tightly coupled interaction in a distributed object system.WebServices are a more appropriated for loosely coupled systems.

Links and References

Projects and products:

IIOP.NET

http://iiop-net.sourceforge.net/

Janeva

http://www.borland.com/janeva/

Remoting.Corba

http://remoting-corba.sourceforge.net/

Technologies:

.NET Remoting

http://msdn.microsoft.com/library/en-us/dndotnet/html/hawkremoting.asp

RMI / IIOP

http://java.sun.com/products/rmi-iiop/

CORBA

http://www.corba.org/

License

Thisarticle has no explicit license attached to it but may contain usageterms in the article text or the download files themselves. If in doubtplease contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Patrik Reali


Patrik Reali was a senior software engineer for ELCA Informatique (www.elca.ch)in Zurich, Switzerland; in January 2005, he joined Google. He isspecialized in systems and programming languages, with a stronginterest for the .NET and Java platforms.

He got a PhD in computer science at ETH-Zurich working on the research operating system and language Oberon.

Together with Dominic Ullmann, he administers the open source project IIOP.NET.
Occupation: Web DeveloperLocation: United States

From: http://www.codeproject.com/KB/IP/dist_object_system.aspx