J2EE et .Net des ennemis bientôt frères

architectures comparées de .net et J2EE DR

 

J2EE et .Net sont deux plates-formes de développement d’application a priori incompatibles. Mais cette incompatibilité pourrait bien déboucher sur une coexistence à travers les web services.

"J2EE et .NetInternet">i reposent sur deux architectures qui se ressemblent beaucoup. Mais, première différence essentielle, .Net ne fonctionne que sous Windows tandis J2EE est multi-système d'exploitation. Et même si les deux architectures sont théoriquement incompatibles, il demeure tout de même possible de les interfacer ", précise Marc">i Boullier, directeur technique de Vistali, société spécialisée dans l'orchestration des systèmes d'informationi. Pour rappel, surtout poussée par Sun à sa naissance, J2EE est montée en puissance parallèlement à la banalisation des applications multi-tiers. Ce type d'application s'est généralisé en même temps que le webi, sous ses formes intraneti, extranet ou internet">i. Entre autre avantages, il évite le déploiement de clients, garantit une plus grande évolutivité, facilite la maintenance et les mises à jours de logiciels, permet de monter des sites de e-commercei ou encore de s'interfacer avec les applications existantes. Une application multi-tiers décompose données, traitement et interface. Ce qui suppose une interopérabilité entre les différentes briques logicielles.

" Les capacités qu'ont des composants de discuter avec d'autres composants du système d'information permettent de réduire les questions à se poser pour intégrer l'ensemble ", ajoute Marc Boullier. L'exécution suppose une plate-forme capable de faire " tourner " ces applications avec des services adaptés à chacun de ces éléments. Cette plate-forme, ou serveuri d'applications, permet de répondre aux besoins de montée en charge, de " scalabilité " et de disponibilité des applications. Faire dialoguer tous ces composants a supposé une standardisation minimum qui s'est concrétisée sur le terrain par la version 1.3.1 de J2EE, la version 1.5 étant aujourd'hui en cours. Les architectures comparées de J2EE et de .Net présentent une grande similitude.
 
le poids de l'éditeur

Suivant la même évolution vers les applications avec un client léger, et pour s'installer sur ce marché des applications d'entreprise, Microsoft a d'abord ajouté plusieurs briques, MSMQ (MicroSoft Message Queuing server) et Com+ à ses outils internet de base : ASPi (Active Server Pages) et IIS (Internet Information Server). Jusqu'à fournir un "framework" avec .Net, "framework" qui correspond à un ensemble d'outils, de l'IDE (Environnement de développement intégré) à la plate-forme d'exécution permettant d'optimiser l'exploitation. Si l'on ne peut parler de standard à proprement parler pour .Net, puisqu'il est totalement propriétaire, le poids de son éditeur le rend incontournable.

architecture J2EE

J2EE s'est d'abord structurée à partir de deux axes : le langage Javai et la machine virtuelle Java capable d'exécuter le code sous tous les OS (système d'exploitation) majeurs du marché (OS390, AS400, HP UX, Solaris, IBM AIX, Linuxi - Suze ou Red Hat -, Windows). Pour la couche de présentation, correspondant à l'interface et au contrôle sur cette dernière, J2EE englobe la définition des pages JSP (Java Server Pages). Des servlets permettent d'enrichir l'interface sur le client par des options de navigation, par exemple. Moins anodine qu'il n'y paraît, cette couche de présentation sera centrale dans de nombreux projets parce que les terminaux (PDAi, Smatphone, téléphones) sont utilisés pour des applications métiers (consultation de stocks…). Et ces mêmes terminaux peuvent faire tourner la partie applicative avec Java… ou avec Windows CE.
Les deuxièmes composants sont des EJB (Enterprise JavaBean). Ces modèles de développement correspondent à des objets métiers ou à des objets d'accès aux données. En d'autres mots, les objets métiers sont ni plus ni moins des mini-programmes indépendants (pour permettre l'évolutivité et faciliter la maintenance) encapsulés avec des méta-données permettant une gestion fine de l'exécution (équilibrage de charge, persistance…). Les EJB dédiés à l'accès aux données fonctionnement comme une surcouche sur les pilotes développés pour JDBC (Java database connectivity). Pour standardiser l'appel à ces EJB, la communauté OpenSource a défini deux méthodes. En environnement distribué, le protocole RMI (Remote Method Invocation) permet d'appeler les EJB et de les exécuter sur plusieurs machines Java virtuelles différentes. Pour invoquer ces mêmes problèmes sur la même machine virtuelle, IIOP (Internet Inter-Orb Protocol) est utilisé.
Trois autres spécifications viennent en complément de celles-ci : la gestion des transactions avec JTA (Java transaction services), les connecteurs pour s'interfacer avec des systèmes anciens encore en production décrit par JCA (J2EE connector architecture) et un "middleware" asynchrone, le JMS (Java message service), chargé de faire circuler les messages entre les applications. JMS gère les files d'attentes et dépile les messages sur le client. Par exemple, il peut être nécessaire d'envoyer un message de validation à une application tierce avant d'écrire dans une base de donnée (message envoyé à une autre application bancaire avant de débiter un compte, etc.).

architecture .Net

Bâti à partir des objets Com développés en VB (Visual basic), d'IIS et des pages ASP, .Net élargit le nombre de langages de développement utilisables, principalement C# et VB .Net. L'outil de développement, Visual Studio .Net compile les programmes dans un langage intermédiaire (pas du langage de bas niveau) et ajoute les méta-données nécessaires à la gestion de l'exécution. Équivalent de la machine virtuelle, mais limitée à l'OS Windows, ce langage est ensuite compilé à la volée par la CLR (Common Language Runtime).

ce qu'il faut retenir

 
Les architectures J2EE et .Net sont de plus en plus matures et constituent de véritables "framework" applicatifs, c'est-à-dire des ensembles d'outils intégrés, allant du développement à l'exécution. Cependant .Net demeure une solution complètement propriétaire (Microsoft Windows) et les performances de J2EE sont supérieures. Les évolutions futures devraient consacrer la place centrale des web services, basées sur SOAP, pour faire interopérer les applications quelle que soit leur origine.
 
Le reste des composants suit la même logique que J2EE. .Net possède des variantes pour la couche de présentation, Winform pour les clients Windows et WebForm pour les navigateurs. Successeurs des objets Com, les Net Objects sont les programmes équivalents aux EJB. L'accès aux données est assuré par la couche ADO (Access Data Object). MSMQ est le "middleware " asynchrone et une série d'objets Com+ gèrent les transactions. L'invocation des objets distants (sur d'autres serveurs) est assurée par .Net Remoting. Microsoft n'a pas ajouté d'outil pour se connecter aux applications tierces. Comme pour J2EE, l'ensemble permet de développer des applications multi-tiers à condition de se limiter à Windows comme OS.

vers les services web

Pour J2EE, les choses sont moins idéales sur le terrain que ne le laisserait présager le standard. L'implémentation de la gestion des transactions par IBM ou BEA, tous deux éditeurs de serveurs d'applications J2EE, n'est pas complètement identique. Ce qui suppose que traiter des messages complexes avec le "middleware" de l'un avec les EJB de l'autre ne donnera pas forcément le résultat attendu. " On est un peu dans la même situation que lorsque HP poussait son Unix, HP UX, IBM son AIX et SUN Solaris. Des incompatibilités subsistent ", illustre Marc Boullier.
Mais la montée en puissance de SOAP devait à terme faciliter la communication entre tous ces outils. Pour mémoire, SOAP est un protocole de transmission de messages qui structure ces derniers. Il est particulièrement utilisé pour exécuter des requêtes-réponses RPC (Remote Procedure Call). SOAP, qui fonctionne en général sur HTTP, est un canal de communication. La prochaine version de SOAP va intégrer dans les méta-donnés toutes les données nécessaires sur la sécurité. Déjà utilisée sur des intranets et basés sur SOAP, les web services permettent d'étendre ces possibilités sur le web. Autrement dit, une requête en web services permet d'appeler une méthode sur un serveur et/ou site distant et de récupérer les résultats de la méthode. On peut imaginer un site envoyant à la volée à un autre site un texte à traduire et récupérant la réponse. Sur le terrain, ces fonctionnalités permettent déjà à SOAP de servir d'interface entre .Net et J2EE.
 

Le Mag

Tout Archimag, à partir de 9,50 €
tous les mois.

Le chiffre du jour

76
des répondants à notre grande enquête sur les professionnels de l'information et l'entrepreneuriat affirment être attirés par le statut d’entrepreneur (créateur d’entre-prise, indépendant, freelance, etc.).

Recevez l'essentiel de l'actu !