Corba及与WebService区别

原文：
Building a Distributed Object System with .NET and J2EE Using IIOP.NET
译文：
C#开发CORBA通讯（转载）

总结：
简单来讲，可以把Corba简单理解为WebService，他们实现有两个重要特征。

1. 实现了分布式系统下跨平台，跨语言的数据的传输
2. 实现了远程方法的本地调用（在本地调用远程Server上的方法并取得返回值）

Corba与WebService的不同:
On my opinion if CORBA could brake through firewalls as easy as SOAP does then there where no SOAP developed at all. Cause CORBA ment to be used with more serious and reliable infrastructure than WS does, the first is more faster, has rebust transactional semantics and proved itself as good and open technology while WS tends to have a Microsoft smell.

• 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 systems will communicate with WebServices. WebServices are great when it comes to integrate heterogeneous loosely coupled systems, but they have their limitations too: they have no support for remote object references. In practice, they are stateless and closer to a remote method call than to a distributed object system. Furthermore, SOAP and XML are by no means a compressed format and tend to be quite verbose.

.NET and J2EE are two similar but disjointed worlds: they currently can interact together only using WebServices. Both platforms offer great mechanisms for building tightly coupled distributed object systems: .NET’s Remoting and Java’s RMI, but sadly these rely on incompatible standards. Luckily, .NET’s remoting is highly configurable: a different formatter for the serialization and deserialization of the objects together with a different transport channel can be easily provided.

Fig.1: Overview of a .NET channel

This article shows how the .NET and J2EE platforms can tightly interoperate together, as it is often needed when developing distributed enterprise applications. For this purpose, we use an open-source custom remoting channel called IIOP.NET.

About IIOP.NET

IIOP.NET is a .NET remoting channel based on the IIOP protocol. IIOP is the protocol defined by the CORBA standard, the same used by Java’s RMI/IIOP. IIOP.NET acts as an ORB (a CORBA object request broker); it converts .NET’s type system to CORBA’s type system and back, making the objects defined in your application accessible to other ORBs. RMI/IIOP implements a subset of the ORB functionalities (due to some limitations in Java’s type system) and provides the same features as IIOP.NET for the 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 from Java 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 for this purpose. First, the open-source project Remoting.Corba is quite similar in its goals, but has no generator for creating the IDL from a dll and currently does not support CORBA’s valuetypes; second, Janeva from Borland promises to do the same, but is neither free nor available yet (should be released in summer ‘03). We choose IIOP.NET because it is free, currently available, and has a tool to generate the IDL automatically.

The example: accessing a generic collection service

Your problem: you just implemented a great service using .NET, but your customer insists on using a Java client; You cannot use WebServices, because the client software needs to keep references to the single objects on the server: this is just not possible using WebServices unless you implement your own naming service, lease manager, and distributed garbage collection. A more appropriate approach is to use RMI/IIOP on the Java side and IIOP.NET on the .NET side.

This article is constructed around a non-trivial example (the GenericCollection tutorial in the IIOP.NET release: a .NET server provides access to a set of collections consisting of key / value pairs. A client can grab a collection, modify it by adding more pairs, or querying it about the pairs it contains. This requires the client to hold 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.0 or 1.1) and the C# compiler. The Java part of the demo requires any Java 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:

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. The client merely receives a remote reference to them and works with a proxy object that serializes (i.e. encodes) the method calls and forwards them to the server. On the other hand, Entry structures are entirely 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:

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 all channels. The manager object will handle all requests (in fact, this is a server-activated singleton object).

Step 3: create the IDL description

To be able to access these objects from Java, their definition must be made available. Because Java does not understand .NET’s metadata, we create a description of the objects using the IDL format using the IIOP.NET’s CLSToIDLGenerator tool; this tool takes as input one type and one assembly, and emits the corresponding IDL definition file. It also recursively emits the definitions for all other types used.

Calling

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

generates the description for the Manager type (the full type name is required) defined in the Service.dll assembly and for all other types used by Manager. Manager.idl, Container.idl, and Entry.idl are created.

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.

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 can call the methods defined in the remote object just like normal methods:

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 Entry structure instead is copied to the client (this corresponds to the classes extending marked as serializable in .NET, and to the valuetypes in CORBA): thus, you need to provide a local implementation for all its methods (idlj just provides an abstract class):

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:

D:\Demo\net:> Server
server running

and then the client:

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. First input “1” to create a new collection, and then insert a few keys and values, terminate with an empty key. Keep in mind that every command you 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:

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 hosted under .NET from J2EE using IIOP.NET. The implementation of a distributed application is as simple as using only Java’s RMI/IIOP. It is obviously possible to work in the opposite way hosting the objects on J2EE and remotely accessing them from .NET: IIOP.NET includes also a generator to create the proxies for .NET given the IDL of the objects.

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

Remoting and RMI are the technologies available in .NET and J2EE to create 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/