Interview d'experts sur "J2EE vs .NET" propos recueillis par Sami Jaber (jaber@ifrance.com)

2EE ou .NET, .NET ou J2EE ; cette question brûle ou brûlera les lèvres d'une grande partie des directions informatiques dans les années à venir. Alors que les comparaisons fleurissent de toute part, personne aujourd'hui n'est réellement en mesure d'affirmer laquelle de ces deux infrastructures aura le plus de chance de séduire les entreprises. De plus, pour agrémenter les querelles de cloché, les éditeurs s'affrontent à coup d'opérations marketing plus ou moins douteuses visant à démontrer les qualités de leur plateforme respective via sites web interposés. Dans ces conditions, toute discussion dans les forums un tant soit peu orientée se transforme aussitôt en pugilat sans fin (appelé aussi discussion de Trolls). 

Est-ce réellement le destin réservé aux développeurs du monde que celui de choisir un camp tel un soldat choisit son armée ? DotNetGuru veut croire que non. Si Microsoft avec .NET nous apporte un bol d'air frais dans un marché en proie à de profonds bouleversement technologiques, Java, lui, continue et continuera de nous faire rêver avec ses innombrables qualités. 

L'heure n'est pas à la division mais à la réconciliation. Rappelez-vous cette phrase désormais célèbre : "le progrès ne vaut que s'il est partagé par tous". Alors développeurs des deux communautés, unissons nous pour partager les progrès de .NET.... et de J2EE afin de construire nos applications du futur au-delà de toute considération politico-stratégico-marketing !

C'est dans cet esprit que nous avons réalisé cet interview, sans arrière pensée et teintée d'une pointe d'originalité. Aujourd'hui nous n'allons pas demander à des experts de nous parler de leur spécialité respective qu'ils maîtrisent à n'en pas douter sur le bout des doigts. Mais plutôt d'un sujet qui leur est étranger, du moins en théorie. Un exercice périlleux auquel s'est livré avec brio nos deux comparses Yann Schwartz et Jérôme Beau. Nous vous écoutons messieurs, la parole est à vous ! 

Sami Jaber
Responsable de la ligne éditoriale

Qui est Yann Schwartz ?

Yann Schwartz (en haut sur la photo) est consultant et formateur pour la société Winwise, spécialiste des technologies Microsoft. A ce titre, il anime régulièrement des séminaires sur .NET et élabore depuis plusieurs années des applications réparties orientées Internet. Son expertise technique couvre aussi bien les plateformes DNA/COM que .NET avec une nette préférence pour cette dernière sur laquelle il travaille depuis bientôt deux ans. Les sujets qui lui sont chers sont donc .NET, HTTP, Python, mais aussi Wiki (http://c2.com/cgi/wiki) et les Design Patterns.

Qui est Jérôme Beau ?

Jérôme Beau est consultant chez Valtech Technology Consulting, société pour laquelle il a développé le cours Enterprise Java Beans (EJB). Auparavant il a été responsable du pôle d'activité Java chez SQL Tech, technologie sur laquelle il travaille depuis la première heure. C'est au cours de ces années qu'il a développé une expérience du développement, de la conception, et un intérêt pour les méthodes (agiles notamment). Il est aujourd'hui chargé de réaliser des audits et des recommandations de développement pour les grands comptes à travers des projets J2EE. Il est par ailleurs cité en remerciement du livre EJB Design Patterns et met en place depuis peu le site Javarome.net.
 

Questions à Jérôme Beau (expert Java) sur .NET

Le marché semble s'orienter aujourd'hui vers deux technologies : .NET et J2EE. Laquelle selon vous a le plus de chance d'aboutir et pourquoi  ?

Jérôme Beau : .NET vise avant tout à crédibiliser Microsoft côté serveur. Là comme ailleurs, c'est souvent le premier arrivé qui a l'avantage. Aujourd'hui la majeure partie des entreprises ont misé sur les serveurs applicatifs issus du monde Java, parce que l'offre Microsoft leur semblait trop fermée, pas assez mûre (malgré des annonces de produits très tôt comme MTS en 1996), ou simplement inexistante sur les machines serveurs d'il y a 2 ou 3 ans, en majorité de type Unix. Ne serait-ce que pour rentabiliser cet investissement lourd et structurant leur SI depuis 2 ou 3 années, ces entreprises devraient continuer à développer leurs applications sur le modèle J2EE. Pour renverser la vapeur côté serveur, Microsoft doit, soit porter sa plate-forme sur d'autres machines que les PC, soit rendre sa plate-forme portable (c'est ce qu'a fait Java), soit compter sur la montée en puissance et l'adoption élargie de machines serveurs de type PC (Intel ou compatible). C'est cette dernière hypothèse qui est la plus crédible, mais cela laissera suffisamment de temps à Java pour gagner plus encore de parts de marchés, tout en bénéficiant aussi de la montée en puissance de machines qui ne seraient pas que des PC.

Quelles sont selon vous les principaux défauts techniques de .NET  ?

Jérôme Beau : .NET est très ambitieux mais souffre de son passé. L'un de ses plus gros défauts est de n'offrir de réelle valeur ajoutée que si les composants sont développés en .NET (VB.NET, etc.). Les composants COM, COM+ et autres existants peuvent être intégré dans .NET, mais le résultat est si dégradé que le choix de .NET n'apporte plus grand chose, hormis la publicité "portée sur .NET". Ce problème n'est pas spécifique à Microsoft et peut tout aussi bien intervenir pour n'importe quel type de solution, puisqu'il s'agit d'un changement de paradigme (services, composants), d'une évolution trop forte pour être migrée en douceur. C'est comme passer du vélo à la voiture. Pour bénéficier de ses avantages, il faut en accepter le coût. Enfin le problème de .NET est bien sûr sa dépendance à Windows et donc aux machines de type PC (SJ : Nous y reviendrons).

... et ses atouts  ?

Jérôme Beau : L'architecture .NET dispose de plusieurs atouts. Tout d'abord elle a su tirer parti des enseignements du succès de J2EE, au point de reproduire un modèle d'architecture quasiment aussi bien pensé : machine virtuelle (CLR) et bytecode (MSIL), language populaire à la Java (C#), modules (assemblies), descripteurs (metadonnées), services de conteneur, déploiement dynamique et simplifié, etc. Il serait donc peu approprié de reprocher à .NET ce que fait J2EE. Ensuite les outils, qui ont toujours su convaincre les utilisateurs, de par leur simplicité apparente de mise en oeuvre (VB en particulier), un atout de longue date chez Microsoft. 

Enfin la puissance commerciale est un atout non négligable, avec un Microsoft qui pousse .NET peut-être plus qu'aucun de ses produits jusqu'alors, au prix d'offres commerciales difficiles à refuser.

En terme d'outil, .NET propose Visual Studio, qu'en pensez-vous ?

Jérôme Beau : Je ne le connais pas.

Vous qui êtes un adepte du monde Java, ne pensez-vous pas que les deux communautés auraient plus intérêt à collaborer qu'à s'affronter ?

Jérôme Beau : Bien sûr, et c'est d'ailleurs sur l'interopérabilité des deux mondes que se situe le challenge aujourd'hui. Tout d'abord, on constate un besoin  grandissant d'interconnexion entre J2EE et le monde Microsoft. Mais ce besoin concerne souvent l'intégration de petites applications "clientes" développées en VB ou Excel au système d'information basé sur des serveurs J2EE. Il ne s'agit donc pas d'un besoin d'interconnexion vers .NET, qui n'a pas encore vraiment de base installée. Ensuite, d'un point de vue plus général les deux mondes ont intérêt à collaborer, sans quoi le client aura à choisir. Ce problème vise à être résolu aujourd'hui par l'utilisation des Web Services, de manière plus ou moins satisfaisante.

A propos justement des WebServices, ils traversent une période quelque peu agitée avec des acteurs peinant à trouver un standard interopérable. Que pensez-vous de l'offre de Microsoft dans ce domaine ?

Jérôme Beau : Microsoft contribue beaucoup au développement des Web Services (partie essentielle de .NET), et ce depuis le début, notamment avec SOAP. 
Cependant les Web Services sont plus exploités aujourd'hui au sein de l'entreprise que sur Internet. Aujourd'hui où Windows est encore cloué sur ses PC, sa place côté serveur n'est pas majoritaire et celle de .NET quasi-inexistante. Les Web Services sont donc l'opportunité de s'affranchir des choix d'infrastructures J2EE tout en restant acteur du SI. A défaut d'être portable, il faut être interopérable ou mourir. On ne peut mettre de côté Windows et un standard d'interopérabilité devient donc un besoin critique. D'ailleurs Microsoft entend bien exercer tout son poids sur ce point. Il est d'ailleurs cocasse de constater que c'est aujourd'hui l'ouverture et l'interopérabilité qui donne un souffle supplémentaire à Microsoft, elle qui rejetait dix ans plus tôt un autre standard d'interopérabilité (CORBA/IIOP) parce qu'elle n'avait pu le maîtriser.

L'absence d'une couche de mapping Objet/Relationnel intégrée dans .NET est-elle un manque ?

Jérôme Beau : Dans un contexte Java, on considérerait plutôt qu'une interface standard manque, plutôt qu'une implémentation, laissée au soin de tel ou tel fournisseur. En l'occurrence elle ne manque pas, puisqu'il s'agit de JDO. Dans un contexte Windows, une implémentation manque effectivement, puisqu'il faut voir Windows comme un produit, en l'occurrence incomplet. Mais on peut voir plusieurs raisons à cette absence. Tout d'abord le besoin d'une telle couche semble moins ressenti dans le monde Microsoft que dans le monde Java. Non pas que Microsoft n'exploite pas d'objets, mais beaucoup de ses solutions visent à simplifier le travail du développeur/concepteur au travers d'outils efficaces ou d'AGL proposant une conception par écrans plutôt que par modèle métier, aboutissant ainsi à des applications de type CRUD*, adaptée aux modèles relationnels des bases. Ensuite, d'un point de vue technique, l'aspect natif des technologies Windows n'aide pas à implémenter des mécanismes nécessaires à l'automatisation d'un tel mapping, comme l'introspection et la sérialisation d'objets. Malgré cela il y a fort à parier qu'une telle couche apparaisse dans .NET, notamment par le biais de la dynamicité/pluggabilité qu'il apporte (VM CLR et langage non machine MSIL). Gageons aussi qu'elle sera logiquement adaptée à un engin de persistance Microsoft comme MS SQL Server.

Le Framework .NET est techniquement très lié aux caractéristiques du système d'exploitation Windows, pensez-vous que ce soit un avantage ou un inconvénient ?

Jérôme Beau : Au-delà d'un avantage ou d'un inconvénient, c'est un fait. On a pas le choix : aujourd'hui .NET ne peut pas exister sans Windows. Maintenant, d'un point de vue idéaliste, c'est un inconvénient : une application devrait pouvoir être indépendante du milieu dans lequel elle s'exécute, de la même manière qu'une personne doit pouvoir habiter dans différents endroits. Mais si l'on revient à la réalité de cette liaison intime entre une application, un framework (.NET) et un OS, il apparaît évident qu'elle offre des avantages considérables en terme d'intégration (sécurité, interface utilisateur) comme de performance. Cependant, avec le temps, la plate-forme Windows évolue vers une architecture plus souple et plus dynamique (code intermédiaire, VM de .NET), de sorte que l'application s'éloigne de l'OS, et que ces avantages tendent donc à s'amenuiser. J2EE a choisit dès le départ d'introduire une couche supplémentaire (indépendance de la plate-forme) tout en appliquant les mêmes principes. Cela a été d'autant plus facile que Java est plus jeune et donc moins dépendant d'un historique technologique à maintenir tel que celui de Windows. Il a su tirer parti des leçons des autres.

Si vous deviez qualifier le type de projet susceptible d'utiliser .NET, ce serait lequel ?

Jérôme Beau : Côté serveur, on ne trouve pas vraiment de facteur différentiateur entre .NET et J2EE (on y trouve les mêmes concepts et solutions mais implémentés différemment, y compris les Web Services) à l'exception de la spécificité et de l'intégration étroite avec Windows. Le choix d'une architecture .NET comme infrastructure se justifie donc principalement pour des applications nécessitant une telle intégration poussée, ce qui est rare côté serveur. Le cas le plus commun sera donc celui de la migration d'applications Windows existantes. On peut penser que l'ensemble de ces dernières vont migrer vers .NET ou mourir, tant cette architecture est structurante et intégrée à l'OS. Concernant l'argument de la performance, qui serait supérieure sur un PC Windows que sur un serveur J2EE sous Unix, c'est un leurre dans lequel les clients ont su ne pas tomber.

Pour finir, êtes-vous favorable aux initiatives indépendantes visant à porter .NET sur d'autres plateformes telles que Linux ?

Jérôme Beau : Je n'en vois pas l'intérêt. Un tel portage reviendrait à réécrire les trois-quarts de Windows au-dessus de un quart d'OS natif (Linux ou autre), avec les problèmes de coût de développement (colossal, et le soutien de la force de développement OpenSource ne leur est pas acquis), délai et synchronisation des livraisons, compatibilité et isofonctionnalités de ces plates-formes .NET "portées" que cela engendrerait. Si l'objectif est d'avoir un "bon framework" dans un OS, Java est là pour l'apporter, sur la base de J2EE.

Questions à Yann Schwartz (expert .NET) sur J2EE 

Le marché semble s'orienter aujourd'hui vers deux technologies : .NET et J2EE. Laquelle selon vous a le plus de chance d'aboutir et pourquoi  ?

Yann Schwartz : C'est une question piège. Disons que la technologie qui a le plus de chances de réussir sera celle qui :

Quelles sont selon vous les principaux défauts techniques de Java ?

Yann Schwartz : De quel Java parle-t-on ?
- Du JRE (VM, bytecode, JIT, etc.) ? après avoir essuyé les plâtres, différentes machines virtuelles et moteurs offrent des performances acceptables.

- Du langage lui-même ? S'il présentait un net progrès par rapport à C++, il comporte aujourd'hui quelques défauts assez mineurs (absence de propriétés, méthodes virtuelles par défaut, types primitifs pénibles à manipuler comme des objets, etc.). Visiblement l'émulation est une bonne chose puisque subitement le support des templates et des attributs a été annoncé pour la prochaine version.

- De la Java Runtime Library ? Encore une fois, historiquement un progrès, mais elle a du mal à évoluer (de nombreuses bibliothèques XML incompatibles jusqu'il y a peu, l'implémentation assez pénible des Web Services).

- Des Frameworks ? AWT puis Swing n'ont jamais vraiment réussi à s'imposer sur le client (performances assez médiocre). Côté serveur, les servlets et les JSP offrent un modèle de programmation puissant (auquel il manque un Framework "à la" WebForms cependant), et au-delà, J2EE offre un Framework assez complet pour développer des applications complexes. On peut regretter le caractère assez directif de J2EE, une certaine lourdeur, et des choix techniques très liés à des architectures de réseau local, qui ont montré leurs limites (de ce point de vue, J2EE se rapproche de COM+ et DNA).

... et ses atouts ?

Yann Schwartz : Historiques d'abord. Un Framework solide et qui a suffisamment pu être mis en oeuvre pour savoir ce qu'il faut faire ou ne pas faire avec.
Mais le plus intéressant dans Java se trouve selon moi dans la culture et les outils qui sont nés ou qui ont évolués avec le besoin d'arriver à gérer la complexité des projets Java. La culture Java est faite de réflexion sur la conception et la réalisation (design patterns, XP contre conception top-down, tests unitaires, approche de la documentation, etc.). Même si la plupart de ces concepts précédaient Java (grosse influence de Smalltalk et C++ en particulier), ils se sont épanouis avec Java. Je dirais que la communauté Java a produit des choses beaucoup plus intéressantes que ne l'est Java lui-même.

En terme d'outil, Java propose une offre diversifiée avec IBM (Eclipse), Jbuilder (Borland) ou NetBeans, qu'en pensez-vous ?

Yann Schwartz : Les outils proposent souvent des fonctionnalités très intéressantes (browsers de refactorisation, intégration de la conception et de la  réalisation, etc.) ou une grande modularité (Eclipse, qui permet comme VS .NET de réaliser des développements dans plusieurs langages), mais les outils de développement Java sont souvent un moyen pour les éditeurs d'avoir un public captif en proposant des extensions spécifiques. Les dernières annonces de Bea montrent que si les outils évoluent, ils amènent aussi des divergences dans ce qu'est Java.

Vous qui connaissez mieux le monde Microsoft que Java, ne pensez-vous pas que les deux communautés auraient plus intérêt à échanger qu'à s'affronter ?

Yann Schwartz : Evidemment. Les problèmes qui se posent sont les mêmes et les solutions techniques sont proches. Et je pense que le plaisir à concevoir et à faire tourner des petites et des grandes choses est le même que l'on fasse du .NET ou du Java.

Les WebServices traversent une période quelque peu agitée avec des acteurs peinant à trouver un standard interopérable. Que pensez-vous des spécifications de Sun dans ce domaine (JaxRpc, ...) ?

Yann Schwartz : J'ai tendance à préférer les standards du W3C... Disons de façon moins provocante que les standards s'imposent lentement (voir l'évolution de XML qui a fini par se cristalliser, ou les atermoiements de Sun sur SOAP...) mais que seuls les besoins, l'implémentation de ces standards par au moins deux des trois frères ennemis, et l'existence d'outils détermineront les standards amenés à survivre.

La présence d'une couche de mapping Objet/Relationnel intégrée dans les EJB est-il un avantage ?

Yann Schwartz : Bien sûr. Mais la solution des couches de persistance à la Entity Beans pose des problèmes de montée en charge. Un des défauts des architectures J2EE est le "one size fits all" qui veut que tout problème appelle la même solution. En .Net, l'approche est moins dogmatique. ADO .Net, les DataSets fortement typés, l'approche DataSet/XmlDataDocument permettent de s'abstraire de la représentation physique des données. Reste que de ce point de vue J2EE a poussé la logique plus loin. Mais on attend ObjectSpaces...

Le Framework Java est techniquement indépendant des caractéristiques internes de chaque système d'exploitation, pensez-vous que ce soit un avantage ou un inconvénient ?

Yann Schwartz : Ni l'un ni l'autre. Si le langage est théoriquement indépendant du système d'exploitation, les applications J2EE sont, elles, très liées au serveur d'application qui les hébergent. Disons que je ne vois pas de différence fondamentale entre être lié à un éditeur de serveur d'application ou à un éditeur de système d'exploitation. Ce qui devient réellement important ce n'est pas de pouvoir faire tourner la même application sur cinquante systèmes différents, mais de parvenir à faire communiquer cinquante applications qui ne sont pas nécessairement bâties sur le même modèle.

Si vous deviez qualifier un type particulier de projet susceptible d'utiliser Java, ce serait lequel ?

Yann Schwartz : Les mêmes que ceux susceptibles d'utiliser .Net.

Pour finir, êtes-vous favorable aux initiatives indépendantes visant à porter .NET sur d'autres plateformes telles que Linux ?

Yann Schwartz : Evidemment. Elles permettent de tester les affirmations de MS selon lesquelles le CLI et le langage peuvent être implémentés de manière  indépendante de MS - et pour l'instant Portable .Net et surtout Mono sont prometteurs. On verra si MS est aussi beau joueur avec ces implémentations que Sun a pu l'être avec JBoss, Enhydra ou Linux (oui, c'est ironique). De plus, un portage indépendant permettra de choisir l'OS et les serveurs (Web, en particulier) sur lesquels reposeront le Framework. Par ailleurs la multiplication de langages capables d'être compilés en IL serait une très bonne chose (c'est déjà le cas pour Delphi, semble-t-il, et j'espère toujours pouvoir un jour faire du .Net en Python. Après tout Jython le permet dans le monde Java...)

Sami Jaber : Merci Messieurs !

Propos recueillis par : Sami JABER

Copyright : DotNetGuru © Septembre 2002

 *CRUD : Create Retrieve Update et Delete