IIOP.NET for Java EE .NET Integration

IIOP.NET is a technology that allows .NET, Java EE, and CORBA components to interoperate seamlessly using the CORBA-based Internet Inter-Orb Protocol (IIOP). This solution relies on the extensibility of the .NET Remoting architecture to offer transparent, object-level integration without incurring the performance overhead that gateways or SOAP-based products impose.

This technology is available to the software community under the LGPL license as an open-source project at http://iiop-net.sourceforge.net.

Scope

IIOP.NET is an interoperability solution for enterprise applications. It allows interoperation with other peers that understand the IIOP protocol, such as Java EE and CORBA-based objects.

It fully supports bi-directional interoperability, including callbacks, and using distributed objects allows a quasi-natural object-oriented programming style by making references to remote objects almost transparent. These remote objects can be both stateless or stateful.

The framework is also transparent to the applications that use it due to the fact that it is installed into the .NET Remoting infrastructure (which roughly corresponds to Java RMI)objects can communicate with other remote objects without any knowledge of the underlying technology on which they are implemented.

Interoperation via IIOP is not a replacement for SOAP or Web services; the two approaches complement each other in a very natural way. SOAP is best suited for the integration of loosely-coupled services, which are typically stateless and relatively coarse-grained. CORBA objects and Enterprise Java Beans (EJBs) are usually finer-grained and more tightly-coupled than Web services; IIOP, which allows efficient, object-level interactions, is the optimal technology for such cases.

Solution

IIOP.NET takes advantage of the configurability aspects of the .NET Remoting infrastructure (refer to Figure 5-1). At its core is an IIOP Remoting channel that is plugged into the .NET Framework, exactly like the built-in binary and SOAP channels. Consisting of transport sink, formatter, and type-mapper, the remoting channel marshals method invocations and parameters between CORBA and .NET.

Figure 5-1. IIOP.NET opens the IIOP world to .NET.

Besides these runtime components, the solution also includes the build tools that Java and .NET developers need to work with the CORBA interface definitions language (IDL) and the .NET common language specification (CLS):

• A compiler that parses the IDL description of Java or CORBA server classes and produces the corresponding CLS proxy classes needed by .NET clients.

• A generator that transforms the CLS metadata of the server classes into IDL that can be used to build Java or CORBA clients.

IIOP.NET Channel

The IIOP.NET channel is a plug-in for the .NET Remoting infrastructure. It implements a formatter for marshaling the method invocations and a transport sink for handling the low-level networking details (in this case TCP/IP connections). Refer to Figure 5-2.

Figure 5-2. Overview of the .NET Remoting infrastructure

The major difference from the other built-in remoting components is that IIOP.NET allows interoperability with peers other than .NET.

To be part of a distributed object system, the .NET objects face one of two choices:

• Inherit from MarshalByRefObject to be accessible by reference from remote machines (corresponds to Java's Remote interface).

• Inherit from ISerializable or have the Serializable attribute to be cloned between remote machines (corresponds to Java's Serializable interface).

More details about .NET Remoting are beyond the scope of this text and can be found in the .NET Framework documentation.

IIOP.NET Tools

IIOP.NET includes compilers to generate .NET proxies from CORBA IDL definitions and to generate IDL definitions from compiled .NET Assemblies.

The IDLToCLSCompiler takes one or more IDL definitions and generates a DLL containing the proxies for the defined types. Refer to Figure 5-3.

Figure 5-3. IDL to CLS compiler

In Figure 5-4, the CLSToIDLGenerator creates the IDL definitions contained in one or more .NET assemblies. Both tools operate directly on the .NET assemblies to be completely language agnostic.

Figure 5-4. CLS to IDL compiler

Using IIOP.NET

Using IIOP.NET to implement client objects is relatively simple and can be done using four steps. Refer to Figure 5-5.

1. Generate the IDL description for your server objects

2. Generate the proxy classes from the IDL with IDLToCLSCompiler

3. Register the IIOP.NET channel

4. Use the proxy classes

Figure 5-5. A distributed object system with IIOP.NET

Using .NET server objects from Java is as simple as:

1. Generating the IDL description for the server objects with CLSToIDLGenerator.

2. Generating the stubs from the IDL (rmic).

Benefits

IIOP.NET opens the CORBA world to .NET; CORBA defines a protocol that is used to support distributed object systems. This protocol is flexible enough to provide additional services, such as security and transactions, and has many widespread implementations.

Most of the architectural benefits are provided by the IIOP protocol.

• Performance IIOP is lighter and more efficient than SOAP; the IIOP remoting channel shares the same process as the objects it connects, and neither requires a separate gateway nor imposes an additional level of indirection.

• Reliability IIOP defines at-most-once call semantics to ensure that method invocations are processed only once.

• Usability IIOP.NET provides the flexible and powerful model of CORBA, integrated into the simple and intuitive .NET Remoting.

• Scalability The application must handle the scalability; IIOP.NET does not limit it.

Other benefits are

• Tight Coupling Tight coupling between distributed objects in .NET, CORBA, and Java EE; components on each platform can act in either client or server role.

• Transparency Existing servers can be used unmodified, without wrapping code or adapters; this provides a distinct advantage in both development cost and speed.

• Extensive Coverage of CORBA/.NET Type Mappings Most types are already implemented and more are on the way. Note that because of the underlying differences in CORBA and .NET, some types are simply not mappable; these cases are explicitly identified and documented.

• Full Source Code is Available (in C#) This allows users of the framework to configure it to their needs.

• Native Integration in the .NET Framework Because it is directly based on the standard remoting infrastructure, it fits into most architectures and can be combined with other technologies and management systems.

• Well Tested IIOP.NET has been tested with many peers, including Sun's SDK, JBoss, IBM Websphere, BEA Weblogic, Mico, TAO, and omniORB.

• Custom Mappings Custom mappings can be defined for remoting classes with the same semantics but different implementation (that is, .NET and Java EE both define Hashtables, but they have different implementations).

Limitations

Architectural limitations are imposed by the model chosen and cannot be removed:

• Data Typing .NET, Java, and CORBA types differ in some details like the exception types and the character set. IIOP.NET provides a mechanism for mapping custom types that may have a different implementations across the frameworks (for example, Hashtables), but this must be done by hand.

• CORBA Valuetypes (Java Serializable objects) Their methods must be re-implemented in .NET, as the IDL doesn't carry code and Java classes cannot be used in .NET.

Examples

The Supply Chain Management reference application from the WS-I is used throughout this book for examples on interoperability. Here's a short example based on the Retailer part of the application. In Figure 5-6, Web services communicate between applications (like the client and the Retailer system), and a distributed object system implements the communication between the presentation and the Processing tier of the Retailer system.

Figure 5-6. Logical architecture of Supply Chain Management application

The Retailer application consists in a Presentation tier, which provides the rest of the world with Web service access to the Retailer system and is implemented with .NET; the Processing tier consists of some Java-remotable components published through RMI/IIOP. Here stateful components are used and not EJBs because the same interface is already used for the Web access to the application.

The Presentation tier communicates with the Processing tier using IIOP.NET. The Processing tier defines three interfaces. Refer to Listing 5-1.

Listing 5-1. Catalog Interface

Public interface Catalog extends Remote{    Public Document getCatalog() ; } public interface OrderManager extends Remote {    public void registerOrder(Article article, int amount); } public interface Factory extends Remote {    public Catalog getCatalog(); public OrderManager getOrderManager(Customer customer); } 

The Factory is a singleton object that creates instances of the other objects for remote use. Refer to Listing 5-2.

Listing 5-2. Three Interfaces Defined in the Processing Tier

// Create and register factory Factory f = new FactoryImpl(); Context initialContext = new InitialContext(); InitialContext.rebind("factory", f); 

The first step toward interoperability is to create the IDL description of the Catalog, OrderManager, and Factory interfaces:

rmic classpath  . iiop Catalog rmic classpath  . iiop OrderManager rmic classpath  . iiop Factory 

Using these IDL files, the IDLToCLSCompiler generates the proxy classes for .NET:

IDLToCLSCompiler ProxyClasses Catalog.idl OrderManager.idl Factory.idl 

This command generates ProxyClasses.dll, an assembly that contains the definitions for the types defined in the IDL files. Obviously it's important to have all files in the right directory, but all these commands also have options to use different directories for their work.

Now the .NET Web service is implemented, which must register the IIOP.NET channel, connect to the server, and access the remote objects.

The first thing to do is to configure the Web service by registering the channel and fetching a reference to the factory. Refer to Listing 5-3.

Second, the Web service implementation uses the objects in the Production tier. Note how the list of orders is processed by submitting each order singularly to the existing stateful interface. Refer to Listing 5-4.

Listing 5-3. Configuring .NET Web Service

public class Global : System.Web.HttpApplication {     protected void Application_Start(Object sender, EventArgs e) {         // register client channel, no callbacks         IiopChannel ch = new IiopChannel();         RemotingServices.RegisterChannel(ch);         m_factory = GetFactory();         // fetch reference to factory, store it into application         // state access COS naming service         CorbaInit init = CorbaInit.GetInit();         NamingContext nameService = init.GetNameService(host, port);         NameComponent[] name = new NameComponent[]{             new NameComponent("Factory")};         // get the reference to the factory         Factory factory = (Factory)nameService.resolve(name);         Application["Factory"] = factory;     } } 

Listing 5-4. RetailerService

public class RetailerService: WebService {     private Factory GetFactory() {         return (Factory)Application["factory"];     }     [WebMethod]     public void submitOrder(Customer customer, OrderList order) {         OrderManager om = GetFactory().getOrderManager(customer);         try {             foreach (Part part in oders) {                om.Order(part);             }         } finally {             om.completeOrder() ;         }     } } 

Resources

The IIOP.NET project is hosted on sourceforge (http://iiop-net.sourceforge.net/) and maintained by Dominic Ullmann and Patrik Reali and sponsored by ELCA Informatique SA.

The project includes many tutorials and code examples on how to interoperate with peers other than .NET, including the details for the various application servers and ORBs.

The documentation page (http://iiop-net.sourceforge.net/documentation.html) contains the overview of all documentation available. This page also links external tutorials and articles about IIOP.NET.