In this chapter, we have seen elements of how .NET Remoting can be implemented on both .NET and J2EE, using the native support in the .NET Framework and Intrinsyc's Ja.NET for Java. As mentioned in the chapter's introduction, .NET Remoting was designed to be an extensible framework that can be expanded to include new functionality. By developing new channels, it's possible to use .NET Remoting to connect to other technologies and systems.
One example of such a new development is the enabling of .NET Remoting with CORBA. Using .NET Remoting to connect to existing CORBA implementations offers some interesting interoperability scenarios.
Note | CORBA stands for Common Object Request Broker Architecture, a standard developed by the Object Management Group (OMG), http://www.omg.org . In addition to being used in standalone applications and many network devices, CORBA is the middleware technology that underpins J2EE. All J2EE application servers implement RMI-IIOP, and IIOP is based on the CORBA specification. For verticals, based on my experience, I've found CORBA to have a high penetration in both financial and telecom marketplaces . |
While it's too early to write about a released product, one of the ongoing projects in this area is called Remoting.Corba ( http://remoting-corba. sourceforge .net/ ). This is an open -source project being run by an independent developer named Kristopher Johnson. Although the project is in its early stages, it's easy to see the areas that it could address.
Remoting.Corba uses a custom channel in .NET Remoting to communicate with a CORBA 2.6 “compatible Object Request Broker (ORB). The channel works like a regular .NET Remoting channel, except that the URL is a standard CORBA IOR string as opposed to a regular tcp:// or http:// URL. An IOR (Interoperable Object Reference) is a bundle of data used to connect to the server and object and is automatically generated by the CORBA server. The goal is not to create a complete ORB for .NET, but merely to use .NET Remoting as a channel for accessing components hosted in existing ORBs. Although this is the case, Remoting.Corba can also act as both a CORBA client and server.
The first stage for using Remoting.Corba is to take the CORBA IDL and generate an interface in .NET. Today, this has to be created by hand, because there is no C# IDL compiler. An example IDL could be as follows :
// CORBA IDL interface Echo { typedef sequence<Object> List; List echo_list (in string message); string echo_string (in string message); oneway void shutdown (); };
Using this IDL, the following interface would need to be created for .NET (using C#):
// C# interface Echo { string echo_string(string message); [OneWay] void shutdown(); }
Within the .NET client project, the channel is created by importing a Remoting.Corba DLL and registered using the following command:
ChannelServices.RegisterChannel(new IiopClientChannel());
An activator is used to create a new reference to the remote CORBA component. Once the reference to the object has been created, methods can then be called based on the interface definition.
There are of course some limitations with the version (1.3) as it exists today. This includes a few limitations for type mappings, no security support, and no IDL compiler, but as the development evolves this looks like a very promising project.
More Info | For a more complete tutorial on how Remoting.Corba can work with the sample interfaces and classes shown here, visit http:// kristopherjohnson.net/cgi-bin/rc/wiki.pl?Tutorials/Echo_Client . |