Interopérabilité Java / .NET : rêve ou réalité ?

L'interopérabilité entre les deux plates-formes applicatives a fait depuis quelques années des progrès significatifs, notamment suite à l'avènement des Web Services. Démonstration.

Java, créée par Sun, est une technologie historiquement mono-langage  mais multi-plateforme (Unix/Linux, Mac, Windows). Bien entendu, les choses ont évolué depuis puisque Java supporte de plus en plus de langages dynamiques tels le Python (avec Jython), Ruby et même PHP (avec Quercus).

Microsoft a, de son côté, apporté .NET qui ne fonctionne en pratique que sur Windows (mono-plateforme donc) - même s'il existe un support pour Linux grâce au projet Mono dont la maturité ne cesse de s'améliorer au fil des nouvelles versions - et supporte plusieurs langages dont le Visual Basic, le C++ et le C#, créé pour l'occasion.

Java et .NET étant deux plates-formes très utilisées et toujours en plein développement, elles sont tout naturellement amenées à cohabiter dans les années à venir.


Historique

L'interopérabilité entre logiciels hétérogènes est un challenge à relever et de nombreuses organisations se sont penchées sur la question. C'est le cas de l'OMG (Object Management Group), un consortium américain à but non lucratif créé en 1989 "évangélisant" le modèle objet. Cet organisme a défini de nombreux standards dont l'UML en 1997 mais aussi la spécification CORBA (Common Object Request Broker Architecture) initiée en 1992 dont la finalité est de permettre à des composants logiciels répartis, écrits dans des langages hétérogènes et fonctionnant sur des plateformes différentes, de communiquer et d'interagir les uns avec les autres.

Les données échangées utilisent le protocole IIOP (Internet Inter ORB Protocol) et des interfaces définies par le langage IDL (langage pivot garantissant l'interprétation correcte des types de données entre des langages hétérogènes et autres technologies mises en oeuvre).

Malgré de relatives bonnes performances, CORBA a toujours été trop complexe à mettre en oeuvre pour être la technologie sous-jacente à une démarche d'intégration de systèmes d'information. D'ailleurs, Microsoft a connu les mêmes écueils avec son implémentation propriétaire COM/DCOM. Sun a essuyé les mêmes critiques avec  les anciennes implémentations de son modèle orienté composant jugé trop complexe : les EJB.

Les services Web apparaissent quant à eux plus simples. Un fichier WSDL décrit le contrat (les services devant être rendus, les types de données utilisés, etc) et une simple classe suffit pour l'implémentation.

Aujourd'hui, nous trouvons deux catégories de services Web:
- Les services Web REST, basés sur l'architecture du Web et les standards HTTP et URI ;
- Les services Web WS-*reposant sur les standards SOAP (Simple Object Access Protocol) et WSDL (Web Service Definition Language). D'une certaine manière, les services Web WS-* sont les héritiers du modèle RPC (Remote Procedure Call) dont fait partie CORBA.

L'intérêt des services Web repose sur des protocoles et sur des standards ouverts ainsi que sur le XML (format texte à balises) pour l'échange de données, lisibles et compréhensibles par un humain.

Pourtant, les Services Web ont connu de nombreuses difficultés :
- La frilosité des entreprises quant à l'utilisation d'une nouvelle technologie ;
- La problématique de sécurisation des  données, avec leur échanges en XML - et donc dans un format lisible (ce n'est plus du binaire mais du simple texte) tout en étant plus gourmand en bande passante ;
- La diversité des moyens d'écrire du XML et la multitude des standards quant à la présentation des données.

Les Services Web apparaissaient déjà comme une solution répondant en partie au problème de l'interopérabilité. Ils soulèvent cependant d'autres besoins comme la gestion de la sécurité, la gestion des transactions et la manière de présenter les données. Nous allons voir, par la suite, que la plupart de ces nouveaux besoins sont en grande majorité couverts.

Les acteurs majeurs de l'informatique sont de plus en plus actifs sur le sujet : Microsoft et Sun ont récemment signé un accord visant à rendre les environnements Java et .NET le plus interopérable possible. Cet accord prévoit quatre points essentiels :

- Favoriser la communication entre les personnes par l'envoi de logiciels simples d'emploi, avec des fonctionnalités évoluées ;

- Travailler ensemble sur la manière de concevoir et de mettre à disposition des services Web : grâce à l'échange de techniques en collaborant avec  les principaux acteurs du marché et en respectant les mêmes normes ;

- Intégrer les services Web au sein des applications existantes et futures. Dans le cas de Microsoft, il s'agit d'intégrer la possibilité d'interroger des services Web directement à partir de solutions telles que Biztalk, Sharepoint et Office Systems. Sun vise, quant à lui, l'amélioration du support des Web Services dans ses différentes solutions d'EAI comme Java CAPS/OpenESB à travers son serveur d'application "Sun Application Server" basé notamment sur le projet Open Source "Glassfish" ;

 - Proposer des ressources adaptées aux besoins des développeurs : par le biais d'exemples de codes sources et d'une documentation exhaustive. Cet accord a déjà été en partie respecté.


Les Web Services et la SOA ?

Bien qu'il soit plus question d'interopérabilité dans cet article, les Web Services sont à mettre en relation avec le concept de SOA, sujet "à la mode" ces derniers temps. La SOA doit permettre de répondre aux préoccupations suivantes :
 - L'intégration des données : comment assurer la cohérence et la transmission des données à l'ensemble des applications concernées ?

- L'intégration des processus métiers : comment déclencher des traitements dans une application fournissant un service ?

Disons pour schématiser que les Web Services sont mis à profit dans les architectures orientées services puisque, même s'ils ne règlent pas à eux seuls les problématiques liées aux modes de transport, ils permettent de couvrir les questions d'invocation de composants.

Aujourd'hui, on assiste à une vraie guerre chez les éditeurs de solutions d'EAI, et plus précisément les ESB - les ESB sont des EAI dont les connecteurs s'appuient sur des Services Web. Mais il s'agit d'un autre débat.


Metro et WCF ?

Metro et WCF sont deux implémentations du projet Tango, la première est destinée à Java alors que la deuxième est intégrée à .NET 3.x. Le projet Tango est un travail commun entre Microsoft et Sun destiné à respecter des dizaines de standards définis par les spécifications WS-* (sécurité, garantie de livraison des messages, optimisation des échanges et gestion transactionnelle, ...).

WCF - Windows Communication Foundation - est intégré nativement à Microsoft Vista et Windows Server 2008, disponible pour Windows XP SP2 et Windows Server 2003. C'est une technologie fédératrice : une couche d'abstraction qui unifie et simplifie la mécanique d'intégration de services divers dont les Services Web.

Lorsqu'un processus WCF communique avec un processus non WCF, le langage XML est utilisé. Dans une communication "inter processus WCF", c'est le format binaire qui est mis à profit. Dans le principe,  une application qui respecte un standard (et il y a de fortes chances que ce dernier soit défini dans WS-*) aura de ce fait de plus fortes chances de pouvoir communiquer avec une application WCF.
 
Metro, de son côté, est une technologie pour écrire des services Web WSIT (Web Services Interoperability Technologies)  en Java pouvant ensuite être déployés sur Glassfish ou Apache Tomcat par exemple (la liste n'est pas exhaustive). C'est le pendant de WCF.

Au final, tout service Web écrit avec WCF sous .NET peut être consommé par un programme écrit en Java. Inversement, tout service Web Metro sous Java peut être consommé par .NET. Quoi qu'il en soit, cette collaboration que certains qualifient d'utopique, tient-elle (et tiendra t'elle) ses promesses ?


Et dans la pratique ?

J'ai personnellement testé l'interopérabilité entre Java et .NET.

Mon premier constat : Microsoft et Sun communiquent sur cette collaboration mais le font de manière incomplète. J'ai par exemple découvert une présentation de Microsoft présentant Glassfish en action mais sans le code source associé pour la partie Java. Inversement, sur le site de Metro, il existe de nombreux screencasts expliquant la réalisation d'un service Web interopérable sous Metro mais, là-aussi, on parle de l'interopérabilité sans montrer d'exemples pour la partie .NET. C'est comme si chacun parlait du même sujet en prêchant pour sa seule paroisse.

Je suis enfin parvenu à trouver, sur le site de Sun, un code source intéressant accessible depuis le  SDN (Sun Developer Network). La-aussi, l'explication est très bien faite côté Java et quasi nulle pour la partie .NET. Le code source est toutefois téléchargeable.

Le tutoriel commence avec un exemple mettant en oeuvre un service Web écrit en Java avec Metro et déployé sous Glassfish puis un service Web WCF déployé sur IIS et consommé par un client Java Metro.

Le dernier exemple est le plus intéressant. Il met en oeuvre un mécanisme de sécurité basé sur des certificats X509. Attention, toutefois, il est nécessaire de mettre à jour ses certificats pour Glassfish V2. La difficulté de ce tutoriel est d'importer les certificats Java (formats jks) sur Windows ! Pour cela, il vous faudra télécharger le Kit Windows Server 2003 Resource Kit Tool et convertir les dits certificats. Cet outil n'est cependant pas compatible Vista : la conversion devra donc se faire sur un poste Windows XP... Cliquez  ici pour consulter cet exemple.


Et les services Web avancés : les WS-*

J'ai également testé, sans difficulté, l'optimisation des messages MTOM pour l'échange de données binaires interopérables entre Services Web, ainsi que la garantie de livraison des messages.  La prise en charge des transactions a fini de me convaincre.

Ce qui est vraiment agréable, c'est la facilité avec laquelle on écrit et on déploie un service Web en Java.  Le développeur n'a qu'à écrire son service, utiliser les fameuses annotations Java apparues avec la version 5 et le déploiement se charge de générer la Servlet pour traiter les requêtes clientes. Il est également possible d'utiliser une implémentation à base d'EJB3 (les composants Java orientés serveurs, largement inspirés du meilleur de Spring ).

Côté .NET, il y a les outils fournis avec le SDK du Framework 3.0 permettant de développer un Service Web. Là-aussi, tout se fait très simplement.


Conclusion

Les différents tests effectués se sont révélés concluants mais la documentation est incomplète et on se retrouve à parcourir les sites de Microsoft et de Sun pour rassembler les pièces d'un grand puzzle. Pour le moment, les promesses sont globalement tenues (communication, échanges de techniques, respect des mêmes normes, documentation disponible mais perfectible).

Mais encore faut-il voir ce que donnera l'intégration dans les produits de Microsoft...

Pour finir, je vous conseille de consulter l'adresse suivante : http://download.java.net/javaee5/screencasts/wsit-excel-demo/

Il s'agit d'un exemple où un service Web déployé sous Glassfish est manipulé par Excel, en utilisant une authentification par certificat. Ce type de mise en oeuvre était difficilement réalisable sans ces dernières avancées.

Il était en effet déjà possible de faire communiquer Java et .NET en utilisant par exemple un service Web ASP.NET et un service Web XFire. Toutefois, lorsqu'il s'agissait d'appliquer des mécanismes de sécurité (par l'authentification par certificat pour reprendre l'exemple ci-dessus), ou de gestion transactionnelle voire de traduction de listes d'objets C# vers des listes d'objets Java, tout n'était pas aussi simple. Les choses ont heureusement changé et s'en trouvent simplifiées ! 

A noter qu'une plate-forme montée par Alexis Moussine Pouchkine - architecte Sun et Stéphane Goudeau - architecte Microsoft, est hébergée au MTC (Microsoft Technology Center) à Paris. Elle leur permet de disposer d'un environnement permanent pour l'illustration d'exemples d'interopérabilité entre les deux plateformes.

Autour du même sujet