JDNet Solutions. Un comparatif entre .Net et J2EE est-il vraiment pertinent ?
Jean-Christophe Cimetière. Il est vrai qu'une telle étude revient à comparer un produit packagé à une spécification - qui elle-même renvoie, il est vrai, à diverses implémentations et stratégies produit. Cependant, cette question peut être pertinente, notamment si elle est traitée en analysant les modèles d'architecture sous-jacents. Elle paraît également importante d'un point stratégique, notamment en vue de définir une politique claire quant à l'évolution d'un système d'information.

A la différence de l'option .Net qui se limite à un socle unique (commercialisé par Microsoft), J2EE implique de se positionner en termes de solutions. Ce qui peut se révéler une démarche assez longue, tout en présentant l'avantage d'offrir une ouverture vers l'open source.

Ces deux architectures sont très proches ?
Ce n'est pas faux, excepté sur un point. On constate en effet que Microsoft ne dispose pas encore d'un modèle de persistence objet équivalent aux composants EJB (Enterprise Java Beans), de type entities, que fournit J2EE. Il affiche certes une initiative dans ce domaine (autour des Objectspaces). Mais, celle-ci est encore à l'état embryonnaire. A l'heure qu'il est, un tel projet de développement demande par conséquent beaucoup plus de temps sous .Net.

Rappelons que les EJB assurent le lien entre les objets métier et les données qui leur sont associées dans les bases de données. Le point fort de ces composants est de soulager le travail des développeurs lors de la mise au point des fonctions de persistence. Il n'en reste pas moins très critiquées par beaucoup de développeurs, notamment pour leur faiblesse de performance d'exécution. Un point qui fait parfois dire que le temps gagné lors de la programmation est finalement perdu au moment du passage en production. Les résultats du benchmark J2EE/.Net réalisé par The Middleware Company s'explique d'ailleurs sans doute par cette difficulté [NDLR: voir l'article].

Face à ce constat, certains n'hésitent pas à reconcevoir entièrement le dispositif - sans faire appel aux EJB - en vue d'aboutir au meilleur niveau d'optimisation.

Derrière cette question se cache la productivité des développeurs et la qualité des outils proposés pour les deux environnements ?
Sur ce terrain, l'approche de Microsoft est intéressante. Il est en effet l'un des seuls à proposer à la fois un atelier de développement et une plate-forme d'exécution, le tout intimement intégré. Dans le monde J2EE, seul IBM est allé aussi loin. En général, les éditeurs dans le domaine Java préfèrent se battre autour des capacités fonctionnelles plutôt que mettre en avant les performances de développement.

J2EE reste plus mature que .Net sur le plan des chantiers d'architecture...
J2EE dispose en effet de design pattern, issus de plusieurs années d'expérience, dessinés pour faciliter la conception d'une architecture multi-tiers (associant interfaces utilisateur et logique applicative principalement). Il existe déjà une implémentation de référence (open source) de ces design pattern. Baptisée Struts, elle fournit à un serveur d'applications l'ensemble des services initiaux lui permettant d'accueillir les couches de l'application Java. Ce cadre réutilisable va au delà des bonnes pratiques définies par Microsoft pour .Net.

Qu'en est-il du caractère multi-langage de Net ?
Cette ouverture est positive dans la mesure où elle a amené Microsoft à découper finement son architecture, et à adopter une démarche et un code plus transparents. A mon sens, ce n'est pourtant pas un argument discriminant. En effet, l'investissement nécessaire à la prise en main de .Net couvre l'intégralité de la plate-forme du même nom, ce qui est très loin de se résumer aux langages de développement en tant que tels.

Microsoft présente les Web Services comme l'un des atouts majeurs de .Net. Quant à l'univers J2EE, il semble distancé sur ce créneau...
Ce retard devrait être comblé rapidement suite à la sortie de J2EE 1.4, qui inclut les spécifications de cette interface interapplicative. Courant 2003, les premières implémentations de cette version devraient apparaître. Pour l'heure, il existe déjà une infrastructure open source (AXIS) qui permet de supporter des Web Services au sein d'un socle J2EE. Elle est notamment intégrée à la suite WebSphere (IBM).

Aujourd'hui, les connexions offertes par les Web Services fonctionnent - aussi bien entre serveurs J2EE qu'entre serveurs J2EE et .Net ! C'est l'argument fort de Microsoft. Pour répondre aux enjeux d'intégration, l'éditeur avance également le serveur d'intégration Biztalk - qui apporte de son côté une bibliothèque de connecteurs spécifiques. Cependant entre un dispositif aussi limité que les Web Services et un framework d'intégration complet tel que Biztalk, il ne propose aucune solution intermédiaire. Ce qui n'est pas le cas de J2EE... qui est doté de JCA (Java Connector Architecture) : un mécanisme d'interfaçage plus intimme qui présente l'avantage d'être standardisé (dans l'univers J2EE).

Beaucoup de fournisseurs de logiciels, parmi lesquels figure notamment Documentum, ont d'ailleurs retenu Java justement pour les qualités apportées par J2EE en matière d'intégration.