Créer une architecture .NET distribuée

Interopérabilité entre .NET et Java

A quoi sert le projet IIOP.NET ?

De tous les projets alternatifs à .NET, le mariage de .NET Remoting et Corba est assurément l'un des plus excitants. La seule idée qu'un composant Corba ou Enterprise JavaBean puisse dialoguer avec un client .NET Remoting éveille en nous une rare exaltation (et oui il nous en faut peu ;-)).

C'est d'ores et déjà possible me direz-vous ? Oui, mais la plupart de ces solutions souffrent de lacunes plus ou moins importantes.

Prenons le cas des WebServices. Les WebServices permettent d'intégrer des systèmes hétérogènes mais ils ont leurs limitations :

• Ils ne permettent pas de gérer des opérations aussi triviales que les callbacks ou les transactions distribuées.
• Connexions en mode asynchrone et non en mode "connecté"."Mode connecté" est le noeud du problème. En effet, excepté leur caractère fermé et souvent incompatible avec les pare-feux Internet,  les protocoles en mode connecté sont la solution aux échanges à l'intérieur d'une même application.  
• Ils n'ont aucun support pour les références d'objets distants.
• Ils sont sans état et plus proche des RPC (Remote procedure call) que d'un système d'objets distribués
• De plus SOAP et XML sont des formats d'échange verbeux et non compressés (lourd en terme de réseau et de traitement processeur).

.NET et JEE sont deux mondes similaires mais distincts, ils peuvent interagir ensemble seulement en utilisant les services webs. .NET Remoting et Java RMI sont les deux mécanismes de mise en place d'objets distribués.

Malheureusement, ils reposent sur des standards incompatibles. Malgré cela, .NET Remoting est fortement configurable, et comme nous avons pu le voir précédemment il est possible de créer des formateurs pour la sérialisation et la désérialisation des objets sur différents canaux de communication (tcp, http …). C'est sur cette possibilité d'interopérabilité que s'inscrit le projet open source IIOP.NET.

IIOP.NET est un canal remoting de .NET basé sur le protocole d'IIOP (Internet Inter-Orb Protocol).

Pour rappel, les connexions et les transferts de données dans RMI sont effectués par Java sur TCP/IP grâce à un protocole propriétaire (JRMP, Java Remote Method Protocol) sur le port 1099. A partir de Java 2 version 1.3, les communications entre client et serveur s'effectuent grâce au protocole RMI-IIOP (Internet Inter-Orb Protocol), un protocole normalisé par l'OMG (Object Management Group) et utilisé dans l'architecture CORBA.

IIOP.NET agit comme un ORB (CORBA object request broker) ; il convertit les types de .NET en type CORBA, permettant aux objets définis dans votre application d'être accessible par d'autres ORBs.
RMI/IIOP met en application un sous-ensemble des fonctionnalités d'un ORB CORBA (dues à quelques limitations de Java) et fournit les mêmes dispositifs qu'IIOP.NET pour la plateforme de J2EE.

Employer IIOP.NET est presque aussi simple qu'en utilisant remoting intégré au framework. IIOP.NET est un projet open-source hébergé sur sourceforge (http://iiop-net.sourceforge.net/).
Il a été développé par Dominic Ullmann en tant qu'élément de sa thèse de diplôme à ETH-Z ; son travail est maintenant soutenu par son employeur courant (http://www.elca.ch).


Autres projets existants

Evidemment, IIOP.NET n'est pas le seul logiciel que vous pouvez employer à cette fin.

D'abord, le projet Remoting.Corba open-source est tout à fait semblable dans ses buts, mais n'a aucun générateur pour créer l'IDL à partir d'une DLL et actuellement ne soutient pas les valuetypes de CORBA.

En second lieu, Janeva de Borland prétend faire la même chose, mais n'est pas libre. J'ai choisi de présenter IIOP.NET parce qu'il est libre, actuellement disponible, et a un outil pour produire de l'IDL automatiquement.

Il existe aujourd'hui énormément de produits sur le marché dont le but est d'assurer une interopérabilité .NET/J2EE.
Malheureusement aucun d'entre eux ne propose une réelle intégration de Corba en mode connecté et la plupart préfèrent communiquer avec les composants distribués par biais du protocole HTTP.

Pour exemple, JaNet d'Intrinsyc ® fait appel à .NET Remoting sur HTTP en utilisant coté serveur des squelettes spécifiques.    Quant aux autres produits tels que Halcyon, il s'attachent plus à réaliser une interopérabilité binaire en traduisant le byte-code MSIL en byte-code Java qu'à fournir un pont au niveau protocole.

Architecture de cette solution

Réaliser l'intégration de Corba dans le monde .NET est une opération complexe. Au delà du simple middleware de communication, Corba est un environnement comprenant un compilateur de Stub basé sur un langage de définition d'interface, IDL. Mais également plusieurs outils annexes liés aux divers services proposés par l'ORB.

En fonction du degré d'intégration souhaité,plusieurs approches peuvent être envisagées :

• Porter un ORB Java existant en C#/J# : Cette solution consiste à porter entièrement un ORB Java existant en .NET. Nous aborderons les avantages et les inconvénients de cette solution dans les sections suivantes, mais sachez que cette option fait partie des plus intéressantes. 
• Créer un Formateur de messages Remoting : .NET Remoting intègre dans son architecture la possibilité de créer de nouveaux canaux associés à des formats de messages personnalisés (Custom Formatter). L'implémentation d'un canal TCP/IIOP est une solution élégante et à la fois performante en raison de son intégration naturelle avec l'architecture .NET.
• Utiliser des ponts ou wrappers : Lorsque le coût induit par le portage d'une application existante est dissuasif, l'interopérabilité constitue une alternative solide. Le meilleur exemple d'interopérabilité est le Framework .NET dont une partie non négligeable est constituée de classes réalisant des appels vers du code non managé à l'aide de ponts ou Wrappers.  

C'est sur la deuxième solution qu'est basé le projet IIOP.NET.


Vous trouverez un exemple d'implémentation du projet IIOP.NET au sein des sources liées à ce site. Cette implémentation créé un serveur .NET enregistrant sur un canal IIOP un objet Hello et un client Java interrogeant via RMI/IIOP le service Hello.