Etude analytique des architectures applicatives

Etude analytique des architectures applicatives 1 - INTRODUCTION... 2 1.1 - Objectif... 2 1.2 - Périmètre de l étude... 2 1.3 - Plan de l étude... 2 1.4 - Guide de lecture... 3 2 - TYPOLOGIE APPLICATIVE ET CRITERES... 4 2.1 - Typologie... 4 2.2 - Critères d évaluation... 5 3 - ARCHITECTURES APPLICATIVES... 12 3.1 - La technologie J2EE... 12 3.2 - La technologie.net... 16 3.3 - Catégorie Web Interactif... 17 3.4 - Catégorie Publication... 32 3.5 - Catégorie Décisionnel... 41 3.6 - Catégorie Collaboratif... 46 3.7 - Catégorie PGIs... 48 3.8 - Catégorie Intégration applicative... 52 4 - APPROCHE ARCHITECTURALE... 55 4.1 - Modèles décrivant une architecture applicative... 55 4.2 - Protocoles et APIs... 61 4.3 - Historique des architectures applicatives... 65 4.4 - Avantages et inconvénients de l approche n-tier... 67 4.5 - Applications et infrastructure... 69 4.6 - Composants et réutilisation... 71 4.7 - Frameworks... 73 5 - APPROCHES COMPLEMENTAIRES... 76 5.1 - Les bases de données... 76 5.2 - Décisionnel OLAP... 77 5.3 - Les Services Web... 82 5.4 - L interopérabilité applicative... 85 6 - ANNEXES...88 6.1 - Glossaire... 88 Document de travail et d information décembre 2002 ATICA - 1 -

1 - INTRODUCTION 1.1 - OBJECTIF Cette étude des architectures applicatives vise à favoriser la connaissance dans ce domaine ; il est perfectible et les lecteurs sont invités à l enrichir et l améliorer en écrivant à l adresse suivante : interoperabilite@atica.pm.gouv.fr. 1.2 - PERIMETRE DE L ETUDE Le périmètre de cette étude est l ensemble des architectures applicatives informatiques ; elle ne se limite pas à celles actuellement utilisées dans l administration mais à l ensemble du marché. Par contre, les architectures des solutions orientées grand public, par exemple les applications personnelles sur PC (bureautique, monétique ), ne seront pas prises en compte. En plus des architectures éprouvées, une exploration des modèles émergents sera effectuée (par exemple les architectures s appuyant sur des Services Web*). Dans le même esprit, les architectures patrimoniales qui fonctionneront encore de nombreuses années (transactionnels non Web, Mainframes...) n ont pas été exclues du champ de l étude. Par contre les architectures pour le temps réel, la conduite de processus ou le calcul scientifique n en font pas partie. 1.3 - PLAN DE L ETUDE Le chapitre 2 - décrit la typologie de classement fonctionnelle des architectures applicatives étudiées, et les critères qui les caractérisent, aussi bien du point de vue général qu en terme d interopérabilité. Le chapitre 3 - décrit chaque architecture et l évalue par rapport aux critères définis. Le chapitre 4 - traite la problématique architecturale d un point de vue plus analytique. Il comprend un rappel historique et une typologie de différents types d architecture (n-tier), puis aborde la thématique des composants et des frameworks. Le chapitre 5 - traite des approches complémentaires, autour des bases de données et du décisionnel, et fournit une présentation des Services Web et de l intégration applicative. Le document est complété par un glossaire. Les mots du glossaire sont signalés par une * à leur première apparition. - 2 -

1.4 - GUIDE DE LECTURE Ce document vise des audiences diverses et peut sembler volumineux. Voici un guide de lecture selon votre profil : Si vous êtes expert en architecture, vous pouvez lire seulement les chapitres 2 et 3, et les paragraphes 5.3 et 5.4. Si vous êtes membre d une maîtrise d ouvrage ou d une équipe projet : Si une remise à niveau architecturale vous semble nécessaire, lisez d abord le chapitre 4, et des éléments du chapitre 5 selon vos sujets d intérêt, avant de lire les chapitres 2 et 3. Si vous chercher une aide pour un projet précis, identifiez son type d après le chapitre 2 et allez directement au paragraphe approprié dans le chapitre 3. Si vous souhaitez lire l ensemble du document, commencez par les chapitres 4 et 5, puis continuez par les chapitres 2 et 3. Cet ordre des chapitres, qui peut paraître paradoxal, a été choisi pour éviter de présenter d emblée aux lecteurs experts des considérations générales qui risquent de leur sembler trop évidentes. - 3 -

2 - TYPOLOGIE APPLICATIVE ET CRITERES Ce chapitre propose une description de la façon d organiser les architectures applicatives et une série de critères pour les analyser. 2.1 - TYPOLOGIE La typologie utilisée est pragmatique, destinée à être pertinente non seulement pour les architectes des systèmes informatiques mais également pour les maîtrises d ouvrage et les chefs de projet. Bien sûr, certains projets imposent de mettre en œuvre plusieurs de ces types de façon cohérente (par exemple, un web interactif et une gestion documentaire, éventuellement intégrés dans une architecture de type collaboratif). C est le travail d un architecte de projet d établir cette cohérence. Catégorie Web Interactif : il s agit d applications où l utilisateur interagit avec un serveur Web, que ce soit en intranet ou en internet, pour accéder à des données ou des services. L interaction est personnalisée et ne se limite pas à la recherche d information classique traitée dans la catégorie publication. o Web interactif non critique : non critique en matière d argent, de vies humaines ou de réputation mise en jeu ; o Web interactif critique : critique d après les mêmes critères ; se caractérise souvent par la présence de transactions ; o Mainframes webisé : une application mainframe traditionnelle exportée sur intranet ou internet ; o Transactionnel 3-tier webisé : une application transactionnelle exportée sur intranet ou internet ; o Client lourd/serveur webisé : une application client lourd traditionnelle exportée sur intranet ou internet. Les trois dernières architectures, qualifiées de «wébisées», couvrent les applications patrimoniales (legacy) existantes, hétérogènes et le plus souvent anciennes mais au cœur du dispositif. De plus, il n est souvent pas souhaitable de les retoucher sauf sous forme de maintenance applicative. Catégorie Publication : il s agit pour l essentiel de «pousser» de l information vers l utilisateur, en le guidant au mieux : o Web : Intranet & Internet «classique» - les vitrines des organisations ; o Gestion de documents «en grand» : sites de journaux, évènements ; o Streaming son/vidéo : applications avancées comme par exemple celle de «La Villette». Catégorie Décisionnel : les applications permettant de prendre des décisions en analysant un historique de données et de services. Catégorie Collaboratif : les applications permettant une meilleure efficacité du travail en groupe : - 4 -

o Groupware ; o Pair à pair ; o Workflow documentaire. Catégorie PGIs* : une analyse de l architecture actuelle et de la stratégie technique des principaux acteurs du marché mondial est effectuée. Catégorie intégration applicative : intégrer les applications peut être considéré comme une sorte de méta application. En particulier le programme du BPM* (Business Process manager) est une application : o Ad-hoc (spaghetti) : style d intégration inclus dans les applications, o EAI «classique» : produits d EAI du marché, o Web Services / XML : EAI émergente à base de technologies Services Web. 2.2 - CRITERES D EVALUATION Chaque architecture est évaluée selon des critères généraux mais aussi par rapport à sa capacité à implémenter facilement les recommandations actuelles ou à venir du Cadre Commun d Interopérabilité des systèmes d information publics. 2.2.1 - Critères généraux Certains critères nécessitant une explication plus longue sont développés dans les paragraphes qui suivent. Coûts : une architecture applicative donnée induit des coûts d achat et des coûts de possession. Elle induit aussi des retours sur investissement et a donc un impact économique. Ce point trop contextuel ne sera pas abordé ici. Les coûts d achat comprennent les licences de logiciel et les coûts induits en matériel et formation. Les coûts de possession comprennent le support logiciel, l administration et la maintenance de l application. Flexibilité : ces critères caractérisent la facilité avec laquelle l architecture applicative peut s adapter à des changements au niveau des besoins, que ce soit sur le plan fonctionnel ou sur le plan non fonctionnel : o Extensibilité (Scalabilité) en performance (voir 2.2.2 - ), o Evolutivité fonctionnelle, o Capacité à intégrer de nouveaux standards, o Richesse des environnements de développement ; Robustesse : ces critères caractérisent la résistance de l architecture applicative aux erreurs de toute nature : o Robustesse intrinsèque du logiciel et des outils associés, o Robustesse extrinsèque vis à vis des pannes de l environnement, des fautes des utilisateurs ou des administrateurs, o Sécurité : capacité à s intégrer et à étendre le cadre de sécurité global du système, - 5 -

o Haute disponibilité : capacité à gérer des réplications pour la tolérance aux pannes ; Pérennité : ces critères sont liés au fournisseur et au logiciel : o Présence du fournisseur, éventuellement internationale, o Parts de marché du logiciel (en effet, la pérennité du fournisseur ne suffit pas, il peut décider d abandonner un produit); Ces points induisent naturellement la création d un écosystème avec des tierces parties (formation, TMA, hébergement) et des compétences disponibles sur le marché du travail. Implémentation J2EE /.NET / LAMP : capacité à implémenter l architecture avec une de ces trois technologies L ensemble des critères généraux est repris dans le tableau en 2.2.4 -. 2.2.2 - Critère d extensibilité (scalabilité) en performance L infrastructure matérielle se caractérise sommairement par ses capacités en terme de puissance processeur, mémoire et entrées/sorties. La capacité processeur a une interaction importante avec l architecture. La capacité mémoire a également un impact, car certaines applications ne savent pas exploiter des capacités mémoire supplémentaires, mais cet impact est moindre. Il y a 3 dimensions possibles de scalabilité en terme de puissance CPU : Puissance intrinsèque du CPU, c est à dire sa fréquence, son architecture et ses caches : cet aspect n a pas d interaction avec l architecture applicative ; Multiprocesseur symétrique SMP* : ajout de processeurs qui se partagent la mémoire (NUMA* n est qu une variante de SMP) ; Grappe (ou cluster, ou MPP*) : ajout des nœuds reliés entre eux par un réseau de communication. Pour pouvoir exploiter correctement une augmentation de performance dans les dimensions SMP ou cluster, il faut bien sûr que les éléments logiciels sous-jacents soient euxmême scalables dans cette dimension ; ceci est particulièrement vrai pour l OS, la base de données et le serveur applicatif. C est également vrai pour l application elle-même, mais ceci sort du cadre de l étude puisque maîtrisé par le concepteur de l application : par exemple, le modèle proposé par le serveur applicatif peut être potentiellement parallèle (multithread*), mais Google : un exemple de scalabilité cluster exemplaire : le moteur de recherche Google est implémenté par une gigantesque grappe de plus de 10 000 machines Linux. Ceci est efficace car l algorithme de recherche de Google est écrit pour ce mode de fonctionnement. Un autre moteur de recherche avec un autre algorithme pourrait être tout a fait inefficace sur la même architecture. Pourtant le service rendu au client est le même! l application force un déroulement séquentiel. On n améliore pas les temps de réponse avec du SMP dans un tel cadre. Pour chaque architecture sera décrite sa capacité à exploiter les dimensions SMP et cluster. Une règle générale est que la dimension SMP est plus facile à exploiter et - 6 -

son rendement relativement indépendant de la programmation de l application ; par contre, le rendement de la dimension cluster est extrêmement dépendant de la nature de l application. Malheureusement, la croissance dans la dimension SMP est plus chère car les gros multiprocesseurs (8, 16, 32 processeurs) sont plus chers «au ktpmc*» que les petites machines (typiquement mono, bi ou même quadri processeurs). 2.2.3 - Critères relatifs au CCI Le CCI Version 1 recommande un certain nombre de standards ; certains sont pertinents vis à vis des architectures applicatives. Certains standards sont à l état de candidat dans le CCI Version 1. Ils sont listés en italique. Le CCI Version 2 proposera d autres standards, listés ici de manière spéculative, également en italique. Sont listés ci-dessous les standards et leur possible impact applicatif ; «néant» ou «Minime» signifie que l architecture applicative est pas ou peu concernée par le standard. Soit il s agit d un standard d infrastructure, soit l impact est lié à la programmation de l application et pas à son architecture. Standard Définition Impact applicatif CCI Version 1 IP V4 V6 Protocole de transport et de réseau Capacité à communiquer sur une socket HTML Langage de présentation des données sur un navigateur Capacité à produire du HTML DNS Serveur de noms de domaines Néant SMTP MIME S/MIME Protocole et formats d échange de mél Capacité à échanger du mél MIME et S/MIME FTP Protocole d échange de fichiers Minime LDAP Format et protocole d annuaire Capacité à consulter l annuaire SSL Protocole de transfert sécurisé au niveau du transport Capacité à communiquer sur une socket «secure» PKI, X.509 Certificats à clef publique Capacité à utiliser X.509 pour l autorisation et l authentification Accessibilité Faciliter l accès aux handicapés Minime, c est la programmation, pas l architecture qui est impactée XML, XSL XMLSchema Langage de description de données et de meta-données Capacité à manipuler et produire du XML, conformément à des XMLSchemas SOAP WSDL Transport applicatif de XML Langage de description d interface Capacité à produire et consommer des services Web UDDI Annuaire pour les services Web Capacité à découvrir et publier des services Web Formats et SGML, MPEG, GIF Minime, c est la programmation, pas - 7 -

supports l architecture applicative qui est impactée CCI Version 2 (Propositions) Composant Standard Tiers concernés Vers ion Etat du std. Commentaires Typologie et critères Standards trans-architectures RPC universel SOAP surtout métier 1.1 A faire La version 1.2 proposée par le W3C n est pas stabilisée Langage de description d interface WSDL surtout métier 1.1 " " " " Annuaire de services UDDI surtout métier 2.03 " Un annuaire UDDI n est pas indispensable Meta données XML XML Schema tous 1.0 " Nécessaire à l encodage WSDL Sécurité : confidentialité et authentification mutuelle SSL TLS X.509 tous 3.0 1.0 " Schémas d encryption de SOAP sur https Authentification service et client Profil d utilisation des Services Web Basic profile tous 1.0 " Emane de ws-i.org, récent (Octobre 2002) Standards J2EE Framework J2EE J2EE tous 1.3 " Composant de présentation JSP présentation 1.2 " Composant de présentation Servlet présentation 2.3 " Composant métier EJB métier 2.0 " Messagerie JMS métier 1.0.2 " Accès SGBDR JDBC métier données 2.0 " Accès mainframes & PGIs J2EE Connector métier données 1.0 " Abusivement, JCA Communication entre composants RMI/IIOP métier 1.0 " A éviter en hétérogène ; préférer les Services Web RPC entre composants JAX-RPC surtout métier 1.0 " Pour accéder à SOAP en Java La liste des standards d interopérabilité étant longue, une synthèse a été réalisée sous la forme des 7 critères suivants : 1. HTML : capacité de génération du HTML 2. XML : capacité à produire et consommer du XML - 8 -

3. Services Web : capacité à produire et consommer des Services Web 4. Composants : capacité à tirer partie de l approche composants 5. Standards : capacité à intégrer de nouveaux standards 6. J2EE : capacité à interopérer avec le monde J2EE 7..NET : capacité à interopérer avec le monde.net Dans le tableau global ci-après, ils permettront de caractériser les architectures applicatives. - 9 -

2.2.4 - Liste synthétique des critères Critère Coûts d achat Coûts de possession Scalabilité performance Evolutivité fonctionnelle Robustesse intrinsèque Robustesse extrinsèque Sécurité Développement Présence du fournisseur Parts de marché Implémentation J2EE Implémentation.NET Implémentation LAMP HTML XML Services Web Composants Standards Interop..NET Interop. J2EE Définition Critères généraux du logiciel vis à vis de l environnement Capacité à s intégrer et enrichir le cadre de sécurité Richesse des environnements de développement du logiciel Capacité à implémenter l architecture avec cette technologie Capacité à implémenter l architecture avec cette technologie Capacité à implémenter l architecture avec cette technologie Critères d interopérabilité Manipulation du HTML Manipulation du XML Capacité à produire et consommer des Services Web Capacité à tirer partie de l approche composants Capacité à intégrer de nouveaux standards Capacité d interaction avec les architectures.net Capacité d interaction avec les architectures J2EE Pour chaque critère et chaque architecture, une cotation sur l échelle suivante a été attribuée : ++ : très capable + : bon 0 : neutre, ou le critère n est pas pertinent pour cette architecture - : faible -- : incapable - 10 -

Il ne faut pas attribuer à cette approche plus de valeur qu elle n en a, et surtout pas additionner les + et les -. Il est plus instructif de lire la colonne commentaires. De plus, pour les coûts, il n a pas été attribué de cotation (qui pourrait être trompeuse), mais seulement un commentaire qualitatif. En effet, seule une analyse projet peut être menée quantitativement. Certains critères n ont aucun sens pour certaines architectures, vu que le modèle n est pas orthogonal, c'est-à-dire par exemple, le critère «interopérabilité.net» pour l architecture «Web interactif non critique.net». Dans ce cas là, le critère est supprimé du tableau. - 11 -

3 - ARCHITECTURES APPLICATIVES Chaque architecture est décrite, analysée par rapport aux critères définis en 2.2 - puis illustrée par un cas d utilisation typique, si possible dans le contexte de l administration. Pour chaque architecture, les standards à suivre sont définis, quand cela est pertinent. En préalable, les deux principaux protagonistes en terme de plates-formes d implémentation J2EE et.net sont décrits. 3.1 - LA TECHNOLOGIE J2EE Java 2 Enterprise Edition est le modèle de composants promu par Sun et ses partenaires pour les applications d entreprise. Il existe d autres modèles de composants Java plus simples, pour les applications embarquées par exemple (J2ME) ou J2SE pour le poste client, mais elles n entrent pas dans le champ de cette étude. J2EE est du point de vue marketing le nom phare autour duquel se structure l affrontement économique avec Microsoft.NET. J2EE au sens strict est une spécification, pas une implémentation. Cette spécification est contrôlée par Sun Microsystems. Il ne s agit donc nullement d un standard au sens formel. L évolution de J2EE est régie par une charte, le Java Community Process (JCP*), qui a été négociée entre Sun et ses partenaires. 3.1.1 - Description technique La spécification J2EE définit la notion de conteneur, qui est un objet logiciel implémentant une fonction macroscopique. J2EE et ouverture J2EE est généralement considéré comme un cadre plus ouvert que.net ; néanmoins, il n est techniquement pas impossible à Sun de reprendre plus de contrôle, puisque le JCP est la loi définie par Sun. L ouverture de J2EE n est paradoxalement garantie que par la relative faiblesse de Sun dans le secteur du logiciel. Les vrais poids lourds de J2EE, ceux qui ont des parts de marché et du revenu de produits et de services associé à cette technologie sont pour l essentiel IBM, Oracle et BEA. Un Sun qui deviendrait dominant sur le marché du logiciel pourrait adopter des pratiques monopolistiques semblables à celles de Microsoft. Cette hypothèse est néanmoins très peu vraisemblable. La certification est un bon exemple de la politique de contrôle de Sun. La certification J2EE est contrôlée par Sun et demande le passage d une suite de vérification et le paiement de royalties liées aux interfaces. Par le biais de subtilités juridiques dans la licence Java, qui ont alimenté la querelle entre Java et le monde du libre, Sun a jusqu à ce jour empêché la certification de produits libres J2EE. (Néanmoins, il semble que l évolution de JCP 2.5 rende possible en 2003 la certification J2EE 1.4 de Jonas et Jboss). Cette certification ne doit donc pas être vue seulement comme un label de qualité technique, ce qu elle est indubitablement, mais aussi comme un outil politicoindustriel. - 12 -

Client léger Navigateur Client lourd Application / Applet Présentation Conteneur Web o Servlet o JSP RMI RMI Métier Conteneur EJB o JCA o JMS JDBC Données Architecture logique J2EE Deux conteneurs existent de-facto : Le conteneur Web s occupe de la présentation : o les servlet hébergent le code Java, o les JSP (Java Server Pages) hébergent du HTML dynamisé par du Java. o JDBC permet d accéder aux données rangées dans un SGBDR Le conteneur EJB héberge la partie métier. Sa vertu principale est de permettre une gestion déclarative de notions complexes à programmer : o Les sessions : le conteneur gère des beans session, avec ou sans état, qui représentent l interaction courante du client avec le système (par exemple son caddy sur un site de e-commerce). o Les transactions o La persistance des objets : le conteneur gère des beans entité qui représentent les objets persistants, soit en laissant l initiative au bean (Bean Managed Persistence, BMP) soit via un système automatique appelé CMP (Container Managed Persistence) o Un modèle de sécurité basé sur les rôles o Le cycle de vie des composants (activation, passivation) o Un modèle de communication asynchrone avec les Message Driven Beans et l API JMS Le protocole de communication entre beans est RMI, et plus précisément RMI/IIOP pour les interactions hétérogènes (Note : en réalité, il n y a jamais de communication hétérogène, par exemple entre WebLogic et WebSphere, au niveau RMI). Un point important est que le conteneur EJB n est pas indispensable. On peut implémenter la partie métier avec le conteneur Web, JDBC pour accéder aux données et des beans Java classiques. Ce point est un sujet de polémiques interminables dans la communauté Java : - 13 -

Une école de pensée trouve que le modèle EJB est «trop compliqué» pour les choses simples, ou même trop compliqué tout court et préfère se limiter au conteneur Web agrémenté d un pattern d accès aux données. L autre école de pensée considère que le conteneur EJB fait un meilleur travail que le programmeur moyen, s améliore dans le temps et est donc un cadre sécurisant et rentable à moyen terme, même si la courbe d apprentissage est reconnue comme importante. En résumé, ce n est pas le modèle EJB qui est complexe, c est le problème des applications transactionnelles d entreprise. Logiquement, le conteneur EJB ne peut être utilisé que si le programmeur profite des valeurs qu il apporte autour des transactions, de la persistance et de l asynchronisme. Ce point doit être jugé application par application, et non pas dans l absolu. Il est par contre regrettable de ne pas utiliser le conteneur EJB par manque de formation. J2EE est une architecture mono langage (Java) et multi plate-formes (Windows, Linux, UNIX, OS/390). 3.1.2 - Le «standard» J2EE 1.3 J2EE n est pas un standard en soi, mais un ensemble de standards ayant leur cycle de vie propre. A un instant donné, un ensemble cohérent est baptisé «J2EE version x.y» : La dernière version publiée est J2EE 1.3 (Automne 2001) qui contient l ensemble d APIs suivants (par ordre alphabétique) : EJB (Enterprise JavaBeans) 2.0 JAAS (Java Authentication and Authorization Service) 1.0 JavaMail 1.1 Java RMI (Remote Method Invocation) 1.0 JAXP (the Java API for XML Processing) 1.1 JDBC (Java Database Connectivity) 2.0 JMS (Java Message Service) 1.0.2 JNDI (Java Naming and Directory Interface) 1.2 JSP (JavaServer Pages) 1.2 JTA (Java Transaction API) 1.0.1 J2EE Connector Architecture 1.0 RMI/IIOP (Internet Inter-ORB Protocol) 1.0 Servlets 2.3 La prochaine version, J2EE 1.4, est depuis Août 2002 à l état de «final draft». Les évolutions sont centrées autour des points suivants : Support des Services Web : JAX-RPC, JAXR, SAAJ Support de XML : JAXP Management : JMX EJB 2.1 JCA 1.5-14 -

La spécification J2EE est implémentée par de nombreux acteurs dans le monde commercial et dans le monde du libre. 3.1.3 - Produits commerciaux certifiés J2EE Il y a 11 vendeurs certifiés J2EE 1.3 en Novembre 2002 : 1. BEA, WebLogic : le leader du marché 2. Borland, Enterprise Server 3. Fujitsu, Interstage 4. IBM, WebSphere : le challenger, pas loin derrière BEA 5. Macromedia, Jrun server 6. Oracle, 9iAS 7. Pramati, Pramati Server 8. Silverstream extend 9. SunOne Application Server 7 10. Sybase, Enterprise Application Server 11. Trifork, Enterprise Application Server Certains produits sont «en avance» sur J2EE, par exemple implémentent déjà la spécification EJB 2.1. Une synthèse souvent bien à jour est disponible sur Internet : http://www.flashline.com/components/appservermatrix.jsp 3.1.4 - Produits commerciaux non certifiés J2EE 1.3 Cette liste n est pas exhaustive: Caucho, Resin-EJB HP, HP-AS Hitachi, Cosminexus Iona, J2EE Technology Ironflare, Orion Sun, SunOne Application Server 3.1.5 - Produits libres Apache + Tomcat 4.1 : cet ensemble ne gère que le conteneur Web, donc les standards suivants : servlet 2.3, JSP 1.2, JDBC 2.0 Jboss (+Apache + Tomcat) : Jboss est le conteneur EJB le plus répandu dans le monde du libre. Il implémente les standards suivants : EJB 2.0, servlet 2.3, JSP 1.2, JDBC 2.0 Objectweb Jonas (+Apache + Tomcat) : Jonas est une technologie d origine Bull, donnée au consortium objectweb. JonAS 2.6 supporte J2EE 1.3 y compris EJB 2.0 (sauf CMP), JTA 1.0.1, JDBC 2.0, JCA 1.0, JMX 1.0, JNDI 1.2.1, JMS 1.1, JavaMail 1.3, Servlet 2.3, JSP 1.2. - 15 -

3.2 - LA TECHNOLOGIE.NET.NET est une marque de Microsoft, un qualificatif pour les produits Windows et Visual Studio, Visual Basic, ASP, ADO, mais ni une spécification, ni un standard formel. C est néanmoins un facteur majeur sur le marché pour l architecture applicative. Du fait de la polysémie de.net, il est important de préciser ce dont il est question..net n est pas le nouveau nom de DCOM ou de MTS. C est un nouveau modèle de programmation, sensiblement différent du modèle traditionnel de Microsoft, avec des stratégies et des outils de migration. Dans ce document,.net désigne donc les applications écrites nativement avec VisualStudio.NET en C# ou en VisualBasic.NET. C# est un langage objet très similaire à Java. VB.NET est une évolution très significative de Visual Basic vers l objet. Ces applications sont ensuite exécutées sur Windows 2000 avec un certains nombre de compléments (.NET SDK), et prochainement sur Windows.NET, la nouvelle version serveur de Windows. 3.2.1 - Description technique L architecture de.net se caractérise par rapport à J2EE, entre autre, par son aspect multi langages (C#, VB, ) et mono plate-forme (Windows). Client léger Navigateur Client mi-léger WinForms o o Présentation Web ASP.NET WebForms SOAP SOAP o o Métier COM COM+ (MTS) ADO.NET Données Architecture logique.net Les services sont très similaires à ceux de J2EE, sauf que.net n a pas de beans entité..net utilise intensivement les protocoles Services Web (SOAP et WSDL) pour la communication entre les composants.net, que ce soit en distribué ou en local. Des optimisations de performance sont faites en homogène.net et en local, par rapport à une communication vers d autres univers. L essentiel de l innovation.net porte sur la partie frontale et le modèle global de communication et de distribution. Pour la partie métier (l équivalent du conteneur EJB),.NET s appuie fortement sur le moniteur transactionnel MTS et sur la persistance ADO.NET pour l accès aux données relationnelles. - 16 -

3.2.2 - Implémentation Il n existe bien sûr qu un seul.net, celui de Microsoft, actuellement disponible sur Windows 2000 et en natif sur Windows.NET. La date de GA (General Availability) de Windows.NET est prévue en début 2003. Ceci montre la relative jeunesse de la plate-forme.net, bien qu il soit puisse de faire du.net soit avec Windows 2000 soit avec les pre-releases de Windows.NET. Il existe un projet d émulation de.net en libre, MONO. L opinion des auteurs de ce projet est assez partagée. Certains experts disent qu il est quasiment impossible de faire le «reverse engineering» d une architecture aussi évoluée que.net sans la complicité de Microsoft et d autres pensent que ce projet est prometteur et qu il commence à donner des résultats. Il ne faut pas comparer cela à SAMBA par exemple qui a réussi sur le segment très bien défini d un système de fichiers distribué. 3.2.3 - Microsoft et les standards Avec l apparition du Web et les conséquences du procès anti-trust, l attitude de Microsoft face aux standards a beaucoup évolué. La compagnie contribue maintenant très valablement à l émergence d un certain nombres de standards importants, soit en les implémentant dans Windows, soit en les proposant proactivement à la communauté informatique : o HTML, XML, LDAP, o Services Web : SOAP, WSDL 3.3 - CATEGORIE WEB INTERACTIF 3.3.1 - Web interactif non critique 3.3.1.1 - Le besoin Il s agit de fournir un accès Web en Intranet ou en mode Internet à une application interactive. L application n est pas critique au sens que ni des sommes considérables ni la réputation de l organisation ne sont en jeu si l exploitation s arrête quelques heures. De plus les performances exigées ne sont pas aux limites de la technologie en terme de débit ou de temps de réponse. Un besoin similaire existe quand l approche peut être qualifiée d opportuniste ; il s agit de tester rapidement la validité d un concept avant de le déployer de manière systématique et pérenne. 3.3.1.2 - L architecture C est une architecture 3-tier classique avec un client Web léger. 3.3.1.3 - Les implémentations et leurs parts de marché Trois variantes sont possibles : LAMP, J2EE/libre et.net. - 17 -

LAMP : c est un acronyme désignant de manière synthétique un système tout en logiciel libre, avec Linux comme OS, Apache comme serveur Web, MySQL comme SGBDR et PHP, Perl ou Python comme langage de programmation. Les serveurs sont des machines Intel mono ou biprocesseurs. Il existe des variantes où Oracle est utilisé comme SGBD, souvent dans des grands comptes avec des licences site Oracle au niveau du groupe. On trouve aussi parfois, mais très rarement, PostgreSQL comme SGBD en libre. Il est généralement admis que PostgreSQL est plus proche d un «vrai» SGBDR que MySQL en termes de propriétés ACID*. Très rarement, on observe une sous-espèce «AMP sur UNIX», souvent en réutilisation de serveurs UNIX un peu anciens. J2EE/libre : variante Java de la précédente, tout en logiciel libre, avec Linux comme OS, Apache + Tomcat comme serveur Web, MySQL comme SGBDR et Java comme langage de programmation. Les serveurs sont des machines Intel. Il peut parfois être utile d ajouter un conteneur EJB comme Jonas ou Jboss..NET : architecture tout Microsoft avec Windows 2000 ou.net comme OS, IIS comme serveur Web, VisualBasic, C++, VisualBasic.NET ou C# comme langage et SQLserver comme SGBDR. Les serveurs sont des machines Intel. En se basant sur les analyses de Netcraft (www.netcraft.com) LAMP+J2EE/libre possède 2/3 du marché et.net 1/4. Microsoft est plus avantagé à l intérieur des entreprises. Il est difficile de départager LAMP et J2EE/libre, sans doute autour de 45% pour LAMP et 20% pour J2EE/libre. Le J2EE commercial est minoritaire sur ce segment. 3.3.1.4 - Standards associés Dans tous les cas : HTML, DHTML LAMP : à la mode du libre J2EE/libre : servlet, JSP, JDBC, parfois EJB et JMS.NET : à la mode Microsoft 3.3.1.5 - Analyse multi critères Elle est différente dans les trois cas : - 18 -

LAMP Critère Commentaires Critères généraux Coûts d achat Coûts de possession logiciel gratuit, matériel peu coûteux variables selon compétences du client Scalabilité performance 0 Faible en SMP (2-CPU), bonne en cluster Evolutivité fonctionnelle 0 Ad-hoc Robustesse intrinsèque + OK pour.coms Développement 0 Faible (évaluation sujette à polémiques) Robustesse extrinsèque 0 raisonnable Sécurité + raisonnable Présence du fournisseur ++ partout et nulle part Parts de marché ++ les.com, autour de 50% sur Internet Critères d interopérabilité HTML ++ C est fait pour ça XML ++ Xerces, Xalan, expat Services Web ++ Axis Composants 0 Peu structuré Standards + Souple Interop. J2EE + Services Web Interop..NET + Services Web - 19 -

J2EE Libre Critère Commentaires Critères généraux Coûts d achat Coûts de possession Scalabilité performance + logiciel gratuit, matériel peu coûteux variables selon compétences client Faible en SMP (2-CPU), bonne en cluster Evolutivité fonctionnelle Robustesse intrinsèque ++ composants + raisonnable Robustesse extrinsèque 0 raisonnable Sécurité Développement Présence du fournisseur Parts de marché + raisonnable + Ateliers Java ++ partout et nulle part + Autour de 15% sur Internet Critères d interopérabilité HTML XML ++ C est fait pour ça ++ Xerces, Xalan Composants ++ Standards Services Web Interop. J2EE Interop..NET + Processus JCP ++ Axis ++ Conteneur Web + Services Web - 20 -