Passer au contenu

1. Choisir entre les deux architectures

Au-delà de différences techniques mineures, le choix entre J2EE et .NET est déterminé par le besoin d’ouverture, la culture de l’entreprise et la stratégie des éditeurs.

Les entreprises devront trancher entre une architecture multiplate-forme et mono-langage et une autre monoplate-forme, mais multilangage “, résume Bruno de Combiens, chef de produits chez Borland. Les critères de choix seront politiques – nature de l’existant, culture des développeurs et des administrateurs, stratégie des éditeurs de progiciels ou encore volonté de limiter le nombre d’interlocuteurs.

Des incompatibilités résolues avec XML et les services web

On ne peut qu’être frappé par les similitudes entre les architectures. Toutes deux autorisent le déploiement d’applications multitiers séparant don- nées, traitements et interface utilisateur. Les applications prennent la forme de composants objets compilés dans un code intermédiaire et exécutés par une machine virtuelle : la JVM (Java Virtual Machine) pour J2EE, le CLR (Common Language Run-time) pour .NET. Enfin, chaque plate-forme intègre un ensemble de services d’exécution des composants ou d’accès à des applications et données externes.Quant aux différences, elles ne sont pas fondamentales. Les problèmes d’incompatibilité soulevés peuvent être résolus avec XML ou les services web. On retiendra néanmoins le clivage entre les deux plates-formes sur l’accès aux données et la gestion de la persistance des objets. Alors que J2EE fait appel à des EJB persistants (Entity Beans), .NET s’appuie sur des procédures stockées dans le SGBD et invoquées depuis des composants ADO (Abstract Data Object). Chacune des deux approches a ses avantages : meilleures performances pour .NET et large spectre fonctionnel existant (EJB métiers), synonyme de rapidité de développement pour J2EE.J2EE et .NET se distinguent aussi par les langages pris en charge. J2EE est synonyme de Java, tandis que .NET offre un vaste choix, avec par exemple la possibilité de mixer Visual Basic et C#. Toutefois, VB a dû être refondu, tandis que Cobol ou JavaScript n’exploiteront pas toute la richesse de .NET. Seul C#, proche de Java et de C++, est nouveau et conçu pour .NET.Les compétences des développeurs auront donc une influence sur le choix de l’architecture. Et l’on entre alors de plain-pied dans des critères plus politiques, souvent liés à la notion d’ouverture. Ainsi, les implémentations de J2EE tournent aussi bien avec NT et 2000 qu’avec Unix – promesse d’une liberté et d’une meilleure évolutivité, les serveurs Unix montant plus haut en gamme. On peut en outre associer un environnement de développement et un serveur d’applications d’origines différentes. “Si l’on ne s’écarte pas des standards, une application déployée sur Web Logic fonctionnera également sur WebSphere“, affirme Dominique Jocal, consultant chez Octo Technology.

IBM tente d’imposer Eclipse

Cette ouverture impose un effort d’intégration qui sera fonction du fournisseur. De ce point de vue, les approches des deux leaders, BEA et IBM, diffèrent. Pour Christian Doguet, directeur avant-vente chez BEA : “Le serveur d’applications représente un métier à part entière, tant sont élevés les coûts de R&D nécessaires à l’obtention de la certification J2EE. ” De son coté, IBM cherche à proposer toutes les briques autour du serveur d’applications : outils de développement, SGBD, EAI… Avec son projet Eclipse, IBM tente même d’imposer son environnement de développement auprès des autres éditeurs.Microsoft va encore plus loin, son approche propriétaire le contraignant à fournir la panoplie entière. Pour autant, la plupart des briques ne seront cuisinées à la sauce .NET qu’en 2003 ou 2004. “D’ici là, l’interopérabilité entre .NET et COM+ permettra d’utiliser Biztalk ou SQL Server à partir d’applications .NET“, affirme Marc Gardette, chef de produits chez Microsoft. L’ouverture serait en outre assurée par la publication des spécifications de .NET. Même si cette démarche est limitée au CLR, à C# et aux bibliothèques de base, il faudra surveiller les projets open source visant à porter .NET sous Linux.

J2EE et .NET ne sont pas les uniques fondations

À force d’écouter les protagonistes, on comprend que ce débat sur l’ouverture est loin d’être clos. “ Par leur volonté de publier les standards et d’instaurer une dynamique de collaboration au travers de l’open source, seuls les partisans de J2EE recherchent délibérément l’ouverture“, affirme Rémy Baranger, responsable marché Web- Sphere chez IBM. Tandis que Marc Gardette (Microsoft) rétorque : “La véritable standardisation est apportée par les services web. Notre but est de fournir la meilleure plate-forme pour les développer et les déployer.“Mais, finalement, les entreprises vont-elles sélectionner une architecture ? Ou celle-ci sera-t-elle déterminée par les choix opérés par les éditeurs de progiciels, eux-mêmes sélectionnés en amont, selon des critères fonctionnels ? Leur stratégie montre à quel point il est difficile d’imaginer utiliser J2EE ou .NET comme fondation unique sur laquelle il suffirait d’installer des composants de PGI ou de GRC prêts à l’emploi. Ainsi, malgré un choix Java stratégique, SAP ne proposera R/3 que sur son propre serveur J2EE, qui gérera également l’architecture propriétaire ABAP, afin de permettre une migration progressive. PeopleSoft est également passé à J2EE, mais le rôle du serveur Java est limité à la gestion de l’interface utilisateur, les composants métiers restant pris en charge par un moniteur transactionnel. De son côté, Siebel conservera un serveur propriétaire exécutant un code C++ compilé. En revanche, les éditeurs d’outils de gestion de contenu ou de création de sites, comme Vignette, ATG ou BroadVision, déclinent réellement leur offre sous la forme d’EJB. Pour leur part, Navision, Pivotal ou Sage ont pris position pour .NET. Tandis que BroadVision déclinerait son offre dans les deux architectures. Mais ces éditeurs n’en sont qu’au stade des déclarations d’intention. En effet, la disponibilité de l’architecture de Microsoft est récente. Son véritable décollage interviendra avec le lancement de .NET Server, successeur de Windows 2000, qui intégrera le framework .NET. Mais, de son côté, J2EE peut se targuer d’une certaine maturité et de nombreux retours d’expérience.


































































 Microsoft .NET : une disponibilité progressive 
 Produit     Disponibilité 
     
 Visual Studio .NET, framework .NET avec run-time à installer sous Windows 2000.     Février 2002. 
     
 .NET Server (successeur de Windows 2000 Server).      Fin 2002 (premier semestre 2003 en France). 
     
 Portage complet de SQL Server.     Courant 2003. 
     
 Portage complet de Biztalk Server.     Courant 2003. 
     
 Portage complet d’autres produits Microsoft (Commerce Server, Host Integration Server, MSMQ…).      2003 ou 2004. 
 

























































































 Les deux protagonistes en lice 
     J2EE     .NET 
         
 Principales implémentations     IBM WebSphere, BEA WebLogic iPlanet AS, Oracle9iAS.     Microsoft (autres implémentations probablement marginales). 
         
 Systèmes d’exploitation     Principaux Unix, Windows NT et 2000, systèmes propriétaires IBM.     Windows NT et 2000. 
         
 Principaux environnements de développement     VisualAge et Eclipse d’IBM, JBuilder de Borland, JDeveloper d’Oracle.     Visual Studio de Microsoft, Delphi et C++ Builder de Borland. 
         
 Langages     Java.     C#, VB, JavaScript, Java, C++, Delphi, Cobol, J# (Java de Microsoft) et autres. 
         
 Quelques éditeurs ayant fait un choix stratégique     Oracle, SAP, PeopleSoft, ATG, BroadVision, Vignette, Intentia, Ariba, WebMethods, Tibco.     Navision, Pivotal, Sage, BroadVision (2003), Commerce One. 
 



🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


TLA