Corba constitue sans doute l'un des middlewares les plus utilisés au monde. On ne compte plus aujourd'hui le nombre d'ORB (Object Request Broker) gratuits ou payants basés sur ce modèle de développement ou intégrés dans de multiples serveurs d'application. Il est indéniable que Java à travers la norme J2EE a énormément contribué à son succès en adoptant le protocole IIOP au sein même de l'architecture des composants distribués, Enterprise Java Beans.
Avec l'avènement de .NET et de son middleware fétiche, .NET Remoting, la question de l'intégration de Corba dans l'environnement .NET va de plus en plus se poser. Et ce pour une raison bien précise. De nos jours, J2EE occupe une place non négligeable coté serveur dans bien des Systèmes d'information. Par ailleurs, si les migrations restent rares, les entreprises privilégient (surtout en temps de crise) une démarche d'interopérabilité afin de rentabiliser l'existant.
Les entreprises ayant un lourd existant J2EE et désireuses de mettre en place .NET sur le poste client n'ont aujourd'hui d'autres choix que d'utiliser les WebServices par le biais du désormais célèbre protocole SOAP. Malheureusement, ce protocole bâtie sur HTTP s'avère inadapté dans certaines situations.
Ainsi, HTTP ne permet pas d'effectuer de notification client ou callback, ni de bénéficier de la souplesse des protocoles en mode connecté. Ce qui n'est pas le cas de Corba avec IIOP qui d'ores et déjà gagné ses lettres de noblesse dans l'architecture Java/C++ et prouvé sa maturité et sa capacité à traiter les gros volumes de données. Le Duo .NET et Corba, s'il voit le jour, sera non seulement un point positif pour l'interopérabilité tant attendue entre serveur d'application J2EE et .NET mais également un pas en direction de l'ouverture de .NET vers les standards dont Corba fait partie. Par ailleurs, au delà du simple besoin d'interopérabilité, IIOP pourrait constituer une excellente alternative à TCP Remoting dans le cadre d'une architecture .NET vers .NET.
Qu'en est-il aujourd'hui de toutes ces hypothèses ? Peut on espérer dans les jours ou les mois à venir voir apparaître des applications WinForms ou ASP.NET destinées à communiquer avec des composants EJB en mode connecté ? Nous allons tâcher de répondre à toutes ces questions dans cet article à travers la présentation de 3 choix d'implémentation.
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.
L'intérêt de cet article est d'aborder chacune de ces
approches en abordant leur avantages et leur inconvénients respectifs. 
Réaliser le portage d'un ORB Java ou C++ en .NET représente un véritable défi pour le développeur aguerri souhaitant s'exercer aux affres de la programmation distribuée. Par le passé, nous vous avions déjà présenté des applications Java (moteur de servlets) migrées sans grande difficulté en C#. Malheureusement, il n'en va pas de même pour les ORB Corba dont le noyau représente un modèle de complexité en terme d'architecture logicielle.
Ceci étant, étudions les différentes solutions s'offrant à nous concernant une éventuelle migration.
La première solution et non la moindre consiste à réécrire un middleware Corba en partant de zéro. C'est l'approche adoptée par Sergio Perani avec son outil Harmless .NET qui, malgré toute la bonne volonté de son auteur, devra se transcender pour pour atteindre la richesse des ORB actuels écrits en Java ou C++.
La seconde approche, plus sage, consiste à s'appuyer sur un outil existant et à le migrer "tel quel" en J# ou C#. Cette alternative n'est réellement viable que sous une condition bien particulière. Le compilateur J# de Microsoft ne gérant que les classes du JDK 1.14 de Sun, l'ORB choisi devra être compatible avec cette version pour constituer un candidat idéal au portage. Malheureusement, la norme Corba ayant énormément évolué ces dernières années pour intégrer aujourd'hui des notions avancées telles que le POA (Portable Object Adapter), il sera très difficile de trouver un ORB respectant la dernière spécification de l'OMG et implémenté sur la base d'un "vieux" JDK. Il vous faudra vous armer de patience et certainement modifier à la main le code source de l'ORB en question.
Voyons comment procéder dans le cadre de la migration. Premièrement, téléchargez les sources Java d'un middleware quelconque et amusez-vous à les compiler en .NET avec J#.
Enormément de produits "libres" ou OpenSource sont disponibles sur le marché et pourraient convenir à une telle opération. Un des meilleurs est certainement JacOrb qui fournit une implémentation Java robuste avec un degré de services élevé. OpenOrb ou JonAS peuvent également constituer de bons candidats.
Une fois le code migré, il vous restera encore à porter le compilateur IDL, brique importante dans une architecture distribuée. Un compilateur IDL permet de générer les classes Proxies nécessaires à l'invocation d'une méthode distribuée en réalisant un mapping entre les types IDL standards et le langage cible utilisé.
Dans notre cas, il faudra que le compilateur IDL génère du code .NET. Inutile de dire que cela rajoute un degré de complexité à l'ensemble du projet dans le cas d'une migration basée sur C#. Dans le cas de J#, il n'y aura certainement rien à modifier si les API sont conformes aux contraintes énoncées précédemment.
Cela dit, gardez toujours à l'esprit qu'un ORB compilé à l'aide de J# sera fortement lié aux API Java de Sun. Cela aura pour effet de briser l'homogénéité de l'ensemble. A l'opposé, si l'outil est le fruit d'une migration par équivalence d'API (en C# par exemple), le produit final sera mieux intégré à l'environnement .NET et sûrement mieux accepté.
En résumé, si cette démarche n'est pas la plus complexe car elle permet de s'appuyer sur des sources existants, elle peut très vite tourner au casse-tête dans le cas d'implémentations récentes et ardues. Malgré tout, cette solution s'avère l'une des plus intéressantes en terme de flexibilité et pour son degré de services (Nommage, Persistance, ...). Vous n'aurez pas à réinventer la poudre.
Une autre solution consiste à implémenter naturellement dans le middleware de Microsoft, Remoting, un nouveau Custom Formatter associé à un canal (Channel) spécifique sur le principe du canal SMTP développé par Ingo Rammer. Cette option est intéressante à plusieurs titres. Non seulement c'est une manière élégante d'intégrer naturellement Corba dans l'environnement .NET, mais il est possible de faire appel aux différents services de Remoting tels que les Singleton ou les CAO (Client Activated Objects) associé à IIOP.
Voici un
fichier de configuration décrivant un canal fictif Corba/IIOP
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.runtime.remoting>
<application
name="MyFoo">
<service>
<wellknown
type="Foo,
common" objectUri="Foo.iiop"
mode="Singleton"
/>
</service>
<channels>
<channel
ref="Corba
channel" name="IIOPChannel"
port="9999">
<serverProviders>
<provider
ref="ip
filter" mode="accept">
<filter
mask="255.255.255.255"
ip="127.0.0.1"
/>
</provider>
<formatter
ref="iiop"
/>
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Le schéma ci-dessous résume l'architecture globale :
Aujourd'hui, il est très étonnant de constater qu'aucun éditeur n'ait encore développé un tel canal pour .NET Remoting. Cela est d'autant plus curieux que la plus value d'une telle implémentation serait considérable au vue de l'interopérabilité apportée par une telle solution.
L'interopérabilité est aujourd'hui sans conteste la solution la plus simple. Lorsqu'on désire rapidement intégrer un ORB Corba à .NET, il suffit de créer des wrappers ou Proxies chargés de rediriger les appels .NET vers du code non managé (une DLL ou un fichier .class Java). Pour cela, n'importe quel ORB Corba du marché ferait l'affaire. Sans compter que la génération du Proxy pourrait être réalisée à l'aide du compilateur IDL intégré. Pour le reste, laissez faire des outils tels que TLBIMP.EXE ou les ponts Java/COM (JIntegra). Le schéma suivant illustre la démarche générale.
Si vous disposez d'un serveur d'application J2EE et souhaitez l'intégrer à .NET, cette solution a l'avantage de ne nécessiter aucune intervention particulière sur le serveur. Dans le cas d'un serveur .NET, il vous faudra effectuer la démarche inverse et faire appel à l'interopérabilité dans le sens code natif vers code managé.
L'inconvénient majeure de cette approche est sa faible souplesse dans l'utilisation des types. Non seulement un mapping des types .NET vers COM (ou Java) est nécessaire mais le pliage des paramètres (marshalling) est effectué deux fois, ce qui a pour effet de dégrader les performances. Malgré tout, cette solution reste très performante par rapport aux précédentes du fait de l'utilisation de code natif. A cet égard, nous vous conseillons d'utiliser dans ce cas un ORB C++ plutôt que Java.
Le projet Mono est un exemple de projet confronté a ce problème d'intégration de Corba au sein de .NET. Mono a fait l'objet de nombreux débats sur le sujet sans réellement aboutir à une solution satisfaisante pour tout le monde. En témoigne ces messages échangés sur la liste de diffusion mono-list.
Pour l'heure l'implémentation Corba de Mono est suspendue faute de temps. DotNetGuru a cherché à en savoir plus à travers Diego Ruiz, l'un des principaux contributeur de Mono concernant cette partie du projet, voici sa réponse :
"(...)
Unfortunatelly, the project of adding CORBA support to Mono is frozen, as nobody
implied has enough time to dedicate to it. It is really interesting, because it
gives us the opportunity to study .NET remoting internals and .NET technology in
general (as well as CORBA), but I can't continue with it (at least for now) due
to lack of time. (...)
The work Dietmar did with the channels was the first step. The idea is to
write IIOP marshallers/demarshallers for the remoting channels, plus some
kind of mapping between C# and IDL (including the metadata/introspection level),
but as I tell you, the project is almost frozen by now. (...)
Best regards and thanks again for your interest.
-diego."
Cela démontre une chose, les membres du projet ont approché à tour de
rôle toutes les solutions abordées dans cet article. Et même si la dernière piste
semble la plus privilégiée nous sommes encore loin
de voir aboutir une implémentation Corba avec .NET. Nous ne pouvons que le
regretter.
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. Il serait intéressant d'envisager un mélange de ce type de produits avec la solution 3 afin d'éviter la surcharge induite par le pliage des arguments...
Le chemin qui mène à Corba.NET est encore long et sinueux. Si techniquement plusieurs solutions peuvent être envisagées, dans la pratique, aucune ne fait réellement l'unanimité. L'idéal est sans aucun doute l'approche qui consiste à réécrire entièrement un ORB en .NET mais pour l'heure personne n'est décidé à se lancer dans une telle entreprise.
Malgré tout, plusieurs initiatives nous amènent à penser que l'avenir s'annonce pleins de bonnes surprises. Quoi qu'on en dise, Corba sur .NET est une nécessité, non pas pour promouvoir un standard de tout temps décrié par Microsoft, mais surtout pour interopérer avec les applications Java/EJB existantes. Et pour une fois, par un autre biais que ce bon vieux protocole HTTP.
Auteur : Sami JABER
Copyright : DotNetGuru © Novembre 2002
Pour en savoir plus ...
http://www.mono.org : le projet Mono
http://www.intrinsyc.com : JaNET
http://www.halcyonsoft.com : Halcyon