Etude analytique des architectures applicatives

Transcription

1 Etude analytique des architectures applicatives 1 - INTRODUCTION Objectif Périmètre de l étude Plan de l étude Guide de lecture TYPOLOGIE APPLICATIVE ET CRITERES Typologie Critères d évaluation ARCHITECTURES APPLICATIVES La technologie J2EE La technologie.net Catégorie Web Interactif Catégorie Publication Catégorie Décisionnel Catégorie Collaboratif Catégorie PGIs Catégorie Intégration applicative APPROCHE ARCHITECTURALE Modèles décrivant une architecture applicative Protocoles et APIs Historique des architectures applicatives Avantages et inconvénients de l approche n-tier Applications et infrastructure Composants et réutilisation Frameworks APPROCHES COMPLEMENTAIRES Les bases de données Décisionnel OLAP Les Services Web L interopérabilité applicative ANNEXES Glossaire Document de travail et d information décembre 2002 ATICA - 1 -

2 1 - INTRODUCTION 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 : [email protected] 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 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

3 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

4 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 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 -

5 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 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 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 ), 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 -

6 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 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 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 -

7 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) 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 -

8 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 " 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 " 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 -

9 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

10 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

11 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

12 3 - ARCHITECTURES APPLICATIVES Chaque architecture est décrite, analysée par rapport aux critères définis en 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 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 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

13 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 :

14 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) 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) JNDI (Java Naming and Directory Interface) 1.2 JSP (JavaServer Pages) 1.2 JTA (Java Transaction API) 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

15 La spécification J2EE est implémentée par de nombreux acteurs dans le monde commercial et dans le monde du libre 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 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 : 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 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

16 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 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

17 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 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é 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 CATEGORIE WEB INTERACTIF Web interactif non critique 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 L architecture C est une architecture 3-tier classique avec un client Web léger Les implémentations et leurs parts de marché Trois variantes sont possibles : LAMP, J2EE/libre et.net

18 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 ( 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 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 Analyse multi critères Elle est différente dans les trois cas :

19 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

20 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

21 .NET Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession logiciel peu cher, matériel peu cher facile à développer et opérer Scalabilité performance + Raisonnable, SMP, grappe Evolutivité fonctionnelle + Robustesse intrinsèque - Attendons les preuves avec Windows.NET Robustesse extrinsèque 0 Sécurité -- Attendons les preuves avec Windows.NET Développement ++ Reconnu comme un des meilleurs Présence du fournisseur ++ Incontournable Parts de marché ++ Elevées, 50% globalement Critères d interopérabilité HTML ++ Natif XML ++ Natif Composants ++ Architecture composants Standards - Selon la stratégie business de Microsoft Services Web ++ Natif Interop J2EE 0 Services Web Interop.NET ++ Natif Outils et méthodes associés Il est rare que des méthodes très formelles soient mises en œuvre. XP (extreme Programming) est parfois utilisé pour «aller vite». Pour la gestion de configuration, CVS est presque toujours présent en libre, Visual SourceSafe avec.net. LAMP : Pour la programmation en PHP ou Perl, l éditeur emacs est très populaire ; les programmeurs du libre utilisent peu les outils enveloppants. Beaucoup sont des experts et peuvent s en passer ; ceci induit une approche élitiste qu il faut prendre en compte en adoptant ces outils. ZEND développe un ensemble d'outils autour du langage PHP, comprenant notamment un environnement de développement, un optimiser, un cache logiciel ainsi qu'une solution de protection contre l'utilisation abusive du code de l'application. L utilisation de modélisations UML dépend de la culture des groupes de

22 développeurs (Mozilla, KDE modélisés en UML) plutôt que de la culture générale du monde du libre. Même si la partie Web est codée en PHP ou Perl, la logique métier reste souvent codée en C ou en C++ avec des outils libres comme Kdevelop (C/C++), QtDesigner (C/C++) ou Glade ( C ). J2EE/libre : Sun Forte for Java (version gratuite) ou Borland Jbuilder. En amélioration, encore plus complexe que.net.net : Visual Studio.NET, de l avis général un des meilleurs environnements de programmation, surtout pour les programmeurs moyens Cas d utilisation Gestion des résidences de vacances d un ministère, accessible soit par des agents en Intranet, soit par les fonctionnaires et retraités via Internet. Le choix d architecture est approprié du fait des propriétés ci-dessous liées à l application et à l environnement hypothétique : Enjeux financiers faibles Base de données en lecture principalement Scalabilité en mode grappe facile Compétences sur le libre disponibles sur site (sinon hébergement) Web interactif critique Le besoin Une application Web est critique quand une panne entraîne des pertes considérables en argent ou en image pour l organisation qui la met à la disposition de ses clients ou de ses usagers. Un autre critère est le débit exigé. Plus techniquement, un très grand nombre de transactions par minute, des impératifs forts d intégrité transactionelle ou de disponibilité (Xx24 Yx7) sont des indicateurs de criticité. Ces applications peuvent être qualifiées aussi de «systématiques» (par opposition à «opportunistes»), dans la mesure où l organisation investit pour plusieurs années dans une architecture applicative : la pérennité et l évolutivité à long terme sont cruciaux L architecture Les impératifs de performance et de transaction limitent le choix à des architectures n-tier avec frontal Web Les implémentations et leurs parts de marché L architecture J2EE répond bien à l ensemble de ces besoins. (Voir ). Les architectures de type LAMP sont a priori peu crédibles sur ce segment, par manque de robustesse et de scalabilité SMP. Il y a alors quelques questions critiques à analyser : J2EE est il une technologie assez mûre pour ce segment?

23 J2EE en libre est il crédible sur ce segment?.net est il une alternative crédible? Si J2EE est choisi, sur quelle infrastructure? Ces différents points sont abordé ci-dessous : Maturité de J2EE Les facteurs positifs sont la réputation et la compétence des acteurs engagés derrière ce standard (BEA, IBM, Oracle ), le fait d avoir un historique de 2 ans à peu près, et les références existantes. Les facteurs négatifs sont une relative rareté de très grands sites transactionnels en «pur J2EE». (Souvent, J2EE sert de frontal à un transactionnel plus ancien comme Tuxedo ou CICS) et une réputation de complexité du standard. Devant l absence de challenger crédible à court terme, J2EE est le choix le plus réaliste, et relativement peu risqué si on s entoure des compétences nécessaires. Il semble d une prudence excessive de lancer en 2003 un projet nouveau sur CICS ou Tuxedo. Crédibilité de J2EE en libre Plus précisément, il s agit de savoir si le frontal Tomcat et le dorsal EJB Jonas ou Jboss a les qualités de scalabilité, de robustesse et de sécurité requises. Certaines applications récentes avec plusieurs milliers d utilisateurs donnent à penser que cette offre évolue dans la bonne direction. Crédibilité de.net.net est une architecture très attrayante sur le papier, beaucoup plus que ses prédécesseurs DNA ou DCOM. Mais cette architecture est très nouvelle, Microsoft n a pas un historique très convaincant sur les applications critiques, son modèle économique n est pas centré sur ce segment et enfin ses produits n ont pas démontré de scalabilité sur les grands SMP indispensables aux bases de données à fort débit transactionnel. Tous ces facteurs militent pour la prudence. Les sondages plus ou moins formels faits par les analystes tendent à montrer que la majorité des clients penche pour J2EE pour le serment concerné J2EE sur quelle plate-forme? Le choix s articule autour d UNIX, Windows de Microsoft et zos (ex OS/390 ex MVS) d IBM. UNIX est le choix le plus «naturel» car les OS UNIX sont robustes, les machines scalables et le rapport prix-performance raisonnable. Windows, permet d améliorer en apparence le prix performance grâce au prix des serveurs Intel. La robustesse en souffrant, il n est pas démontré que le coût de possession soit meilleur. IBM promeut le concept de J2EE sur zos avec le produit WebSphere. Cette approche présente un intérêt pour les clients ayant un fort investissement opérationnel sur les zseries. Le rapport prix-performance est moins bon, le coût de possession dans l absolu est supérieur, mais dépend de l environnement. Il ne

24 faut pas oublier que les SMP UNIX sont plus puissants actuellement (puissance transactionelle en tpmc) que les SMPs zseries. Une fois donc J2EE identifié comme architecture, reste à choisir une implémentation. Les 2 leaders du marché, pratiquement à égalité sont IBM et BEA, avec plus de 30% de parts de marché : BEA WebLogic est numéro 1, très prisé par les développeurs. Très souvent associé à Oracle, parfois avec DB2 ou Sybase pour le tier données, IBM WebSphere est numéro 2 juste derrière, très souvent avec DB2, parfois avec Oracle ou Sybase. (Toujours avec DB2 sur zos), Oracle ias, avec moins de 10%, est tiré par la domination d Oracle sur le tier bases de données, SunOne, avec moins de 10%,. Les autres acteurs sont petits et très menacés car le segment des serveurs d application J2EE est en forte consolidation Standards associés Le point clef est de respecter le standard J2EE et de ne pas utiliser les extensions propriétaires des différents vendeurs. Les standards J2EE sont définis en L aspect Java Connector Architecture est particulièrement important car la connexion avec des systèmes patrimoniaux ou des PGIs est presque indispensable Analyse multi critères

25 Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession Scalabilité performance Evolutivité fonctionnelle Moins cher que le TP 3-tier propriétaire, souvent associé à UNIX qui est relativement coûteux Compétences maintenant largement disponibles ; plus cher que.net néanmoins ++ Fonctionne sur les plus gros SMP et possède des modes cluster sophistiqués ++ Approche composant Robustesse intrinsèque + J2EE n est pas encore aussi robuste que les transactionnels classiques qui ont 10 ans de maturité Robustesse extrinsèque ++ Modes haute disponibilité évolués Sécurité + Conforme aux standards du monde «culturel» UNIX Développement ++ Vaste gamme d ateliers Java Présence fournisseur du ++ Les vendeurs sont des poids lourds de l industrie ; les prestataires de service nombreux Parts de marché ++ BEA + IBM + Oracle Implément. J2EE ++ Etudié pour Implément LAMP -- Inapproprié Implément..NET 0 Selon les cas Critères d interopérabilité HTML ++ OK XML ++ OK Services Web ++ Encapsulation automatique des objets Java en SOAP/WSDL Composants ++ Architecture composants Standards ++ Processus JCP très ouvert Interop..NET 0 Via les services Web Interop. J2EE + Natif ; mais l interopérabilité entre implémentations est mauvaise (RMI/IIOP). Préférer les Services Web Outils et méthodes associés La «verbosité» du modèle J2EE augmente l intérêt des ateliers logiciels spécifiques. Les ateliers logiciels J2EE les plus répandus sont : Borland Jbuilder : cible aussi bien WebLogic que WebSphere ; c est le favori des développeurs en France, IBM WSAD (WebSphere Studio Application Developer),

26 Oracle Jdeveloper : pour ias, SunOne Forte for Java (ex Netbeans). Pour la modélisation en amont, UML est populaire avec des méthodes itératives de type UP (Universal Process) comme RUP de Rational. En France, certains utilisent aussi Merise qui est assez peu adapté à l approche objet. Il existe par ailleurs une problématique générale de mapping objet - relationnel pour les données persistantes. Selon les écoles de pensée, on peut s en remettre aux outils automatiques, en particulier avec le CMP* de EJB 2.0, ou il vaut mieux le contrôler «à la main» en mode BMP Mainframes wébisés Le besoin Les applications mainframe rendent des services critiques et hébergent une source très importante de règles métier et de bonnes pratiques. Il est souvent pas rentable de les porter à iso-fonctionalités sur des environnements différents. Il est plus opportun de les frontaliser par des serveurs dédiés aux fonctions de type Web, pour la présentation et parfois pour de nouvelles règles métier L architecture Historiquement on eut lieu une phase de simple émulation de terminaux mainframes dans un navigateur, puis de rhabillage HTML ; ces approches ont rencontré des limites et il est apparu plus avantageux pour les applications mainframes correctement architecturées, c est à dire où présentation synchrone et transactions étaient correctement séparées, de situer l interface avec le mainframe au niveau de la visibilité métier. Les mainframes exposent très rarement leurs données en direct. Le plus souvent, ces données sont encapsulées dans des transactions métiers, comme «créer un nouveau client». Il s agit donc de donner accès à ces transactions à partir de l univers du Web. Les deux principaux fournisseurs de mainframe du marché (IBM et Bull) ont choisi J2EE comme frontal privilégié, tout en fournissant aussi des adaptateurs pour.net mais sans les pousser. La norme de connexion est Java Connector Architecture (souvent raccourcie par erreur en JCA). Serveur J2EE Protocole J2EE Java Connector Protocole propriétaire Mainframe Les implémentations et leurs parts de marché

27 En France, mainframe veut dire IBM ou Bull. Les stratégies des deux constructeurs sont fondamentalement différentes : Bull GCOS8 et GCOS7 Bull recommande de ne plus toucher aux applications sur GCOS sauf pour la maintenance et de ne pas développer de nouveaux modules dans cet environnement. Des environnements capables de traiter Java, HTML ou XML n existent donc pas en natif sous GCOS (sauf marginalement sur GCOS7). La stratégie recommandée est de frontaliser la machine GCOS par un serveur Escala avec WebLogic. Tous les traitements HTML, XML, Java sont faits dans cet environnement avec les outils J2EE. La connexion à GCOS 7 (TDS) ou GCOS 8 (TP8) se fait par un connecteur au standard JCA ; Bull a été en avance sur cette norme et participe à la définition de la norme, encore en progression. JCA étant une norme, il est possible techniquement (mais pas commercialement) de disposer des connecteurs GCOS sur d autres serveurs J2EE. IBM zos IBM recommande également de ne plus toucher aux applications sur CICS ou IMS sauf pour la maintenance et de ne pas développer de nouveaux modules dans cet environnement. Il est recommandé de traiter HTML, XML et java sur WebSphere. La connexion se fait via JCA et des connecteurs JCA pour CICS et IMS sont disponibles chez IBM. Pour faire fonctionner WebSphere, le choix est possible : soit sur un frontal pseries sous AIX, soit sur zos dans l environnement d émulation UNIX de ce système d exploitation. Le client choisit selon sa stratégie HW et ses compétences Standards associés Comme pour «Web interactif critique», voir en insistant particulièrement sur Java Connector Architecture Analyse multi critères

28 Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession modèles de prix Mainframe modèles de prix Mainframe Scalabilité performance + Evolutivité fonctionnelle - Difficile, accès aux compétences Robustesse intrinsèque ++ qualité mainframe Robustesse extrinsèque ++ qualité mainframe Sécurité ++ qualité mainframe Développement 0 via Java, sinon assez anciens Présence du fournisseur 0 selon le constructeur Parts de marché + selon le constructeur Implément. J2EE ++ c est le choix favori Critères d interopérabilité HTML 0 indirectement via Java XML 0 indirectement via Java Services Web 0 indirectement via Java Composants - indirectement via Java Standards -- Réactivité moyenne Interop..NET + des produits existent Interop. J2EE Outils et méthodes associés Les mêmes que pour «Web interactif critique», voir Transactionnel 3-tier webisé Le besoin Un système de production en transactionnel 3-tier nécessite un accès Web avec une présentation remodelée et des fonctions supplémentaires. En dehors des mainframes traités en , ces environnements ont presque exclusivement sur UNIX et en pratique avec BEA Tuxedo, IBM CICS ou compatible CICS comme Unikix (racheté par Sun), ou TopEnd de NCR (racheté par BEA). Il existe aussi un modèle CORBA ou des modèles de serveurs d application 3-tier non J2EE L architecture

29 Le choix des vendeurs ci-dessous repose sur une frontalisation J2EE. On est donc ramené à un problème très similaire à celui du Mainframe, avec un connecteur Java Connector dédié au transactionnel patrimonial Les implémentations et leurs parts de marché BEA propose une connexion WebLogic Tuxedo. Les «services» Tuxedo apparaissent comme des composants J2EE et il est donc possible de les utiliser dans une application WebLogic sans connaître Tuxedo. IBM propose un connecteur Java qui fonctionne de manière similaire avec CICS sur UNIX. CORBA Ce modèle d architecture n a pas connu le succès escompté dans les années 90. Il est de-facto remplacé par J2EE pour le gros du marché. Il existe néanmoins des niches CORBA relativement vastes, en particulier dans l industrie de Télécoms. Les vendeurs de technologie CORBA, comme IONA, prennent en douceur le virage J2EE et proposent donc une communication inter ORB* via IIOP* entre les composants CORBA et les composants J2EE. Serveurs d application non J2EE Avant l apparition du standard J2EE pour le n-tier, un certain nombre de modèles propriétaires ont vu le jour, avec des langages de type 4GL et des services d exécution proches de ceux fournis par J2EE, même si le concept de serveur d application n existait pas encore. Citons par exemple Prolifics ou Forte. Les vendeurs de ces produits ont disparu, ou été rachetés ou se sont reconfigurés. Il existe en général pour les clients des solutions de migration plus ou moins facile vers J2EE. Il est certain en tout cas que continuer des développements sur ces produits ne doit pas être fait sans une analyse approfondie de la stratégie future de sortie de ces modèles applicatifs qui n ont pas d avenir à long terme Standards associés Identiques au cas «mainframe wébisé», voir Analyse multi critères

30 Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession Elevé Elevé Scalabilité performance ++ Evolutivité fonctionnelle + Robustesse intrinsèque ++ Robustesse extrinsèque ++ Sécurité ++ Développement 0 figé Présence du fournisseur + Parts de marché + Implément. J2EE ++ Choix préféré des fournisseurs Implément..NET 0 possible Critères d interopérabilité HTML + XML + via Java Services Web + via Java ou natif Composants 0 indirectement Standards 0 figé Interop..NET 0 des outils COM+ existent Interop. J2EE Outils et méthodes associés Les mêmes que pour «Web interactif critique», voir Client lourd/serveur webisé Le besoin Les nombreuses applications à base de clients lourds rendent des services inestimables et il est parfois irréaliste économiquement parlant d envisager une refonte en n-tier. Comment faire pour rendre ces applications disponibles via un navigateur à moindre coût? L architecture Le client peut être lourd ou mi-léger. Le modèle lourd typique est une application VisualBasic mêlant présentation et métier et accédant en ODBC à un serveur SGBDR

31 Le modèle mi-léger typique est un client Oracle Forms gérant pour l essentiel de la présentation et accédant en SQL une base de données Oracle qui gère le métier en procédures stockées. Dans les deux cas, on ne peut ou ne veut toucher à l application client. La meilleure solution est alors d exporter sur le navigateur uniquement la présentation Windows. Cette approche a été inventée par Citrix avec le protocole ICA et reprise par Microsoft avec le protocole RDP. C est le mode client ultraléger (pratiquement du 3270!). Navigateur + applet ICA/RDP Client natif ICA/RDP ICA / RDP Client lourd inchangé Serveur SGBD inchangé PCs Nouveau Serveur Windows 2000 Serveur existant Le client lourd s exécute maintenant sur un serveur Windows. Ce modèle présente l avantage du faible coût de mise en œuvre mais garde des contraintes importantes : o Il est nécessaire de «valider» le fonctionnement en mode ultra-léger. Beaucoup d éditeurs n autorisent pas ce mode. D autres le promeuvent (par exemple Siebel et SAP). o La charge réseau est fortement dépendante du style d interface de l application Les implémentations et leurs parts de marché Citrix Metaframe a réussi à garder plus de 70% (Giga) de ce marché, en parti grâce à des fonctions supérieures à celles présentes nativement dans Windows Standards associés Les protocoles propriétaires ICA (Citrix) et RDP (Microsoft) Analyse multi critères

32 Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession faible à modéré le principal argument de vente Scalabilité performance 0 Evolutivité fonctionnelle -- Néant Robustesse intrinsèque 0 Robustesse extrinsèque 0 Sécurité 0 Développement + besoins minimes Présence du fournisseur + Parts de marché ++ Implément. J2EE -- Inadéquat Implément..NET ++ Etudié pour Implément LAMP - Tentatives inabouties Critères d interopérabilité HTML + XML 0 Hors sujet Services Web 0 Hors sujet Composants 0 Hors sujet Standards 0 Hors sujet Interop..NET 0 Hors sujet Interop. J2EE 0 Hors sujet Outils et méthodes associés Ces solutions sont sans programmation. Les seuls outils sont des outils de déploiement et d administration. La méthode la plus pertinente est une analyse économique de coûts de possession comparés avec les solutions client lourd CATEGORIE PUBLICATION Web : Intranet & Internet «classique»

33 Le besoin PROJET Les sites Web centrés sur la publication existent et continueront à exister, aussi bien sur Internet que sur Intranet. Toutes les organisations n ont pas besoin ou ne souhaitent pas mettre en oeuvre de l interactivité. Il est parfois nécessaire d avoir un niveau de personnalisation dans la présentation des informations, et quasi indispensable de proposer un moteur de recherche local L architecture Une architecture Web 3-tier convient parfaitement. La logique métier est inexistante et il n est pas indispensable d utiliser un SGBD, un système de fichiers est souvent suffisant. Navigateurs Présentation HTML WML Données XML Architecture Web de publication Si la diffusion d information est multi-canaux, en particulier vers des tablettes Web ou des téléphones mobiles WML, ce besoin est pris en compte par le serveur Web. Il est recommandé mais pas toujours possible de stocker les données au format XML. Un framework de type Cocoon (pour Java) ou une librairie comme expat (pour PHP) est dans ce cas recommandée. Selon les besoins de performance, les documents HTML et/ou WML sont générés dynamiquement à la demande ou statiquement, par exemple au moment de la publication ou chaque nuit. Un portail peut être utile pour apporter la personnalisation si elle est nécessaire Les implémentations et leurs parts de marché Le marché est partagé entre LAMP (voir ) pour 2/3 et Microsoft IIS pour 1/3 à peu près. Le marché des portails commerciaux est complexe et non stabilisé. En logiciel libre, PHP-Nuke, construit sur LAMP, peut être cité. Voir aussi Zope en Standards associés HTML, XML, http. Il n existe malheureusement pas encore de standard pour les portails, en particulier les modèles de portlet* sont propriétaires

34 Analyse multi critères LAMP et.net ne sont pas différentiés significativement vis à vis des critères. Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession faibles faibles Scalabilité performance + Les besoins sont modérés Evolutivité fonctionnelle 0 Robustesse intrinsèque + Robustesse extrinsèque + Sécurité 0 Développement ++ Nombreux et variés Présence du fournisseur ++ Parts de marché ++ Implément. J2EE - trop cher en commercial, possible en libre Implément. LAMP ++ C est fait pour Implément..NET + moins populaire que LAMP en Internet Critères d interopérabilité HTML ++ XML + Services Web 0 inutile Composants + widgets Standards + demande stabilisée Interop..NET 0 inutile Interop. J2EE 0 inutile Outils et méthodes associés Voir Gestion de documents «en grand» Le besoin Une très grande quantité d informations, dans des formats très variés, doit être publiée à destination d un grand nombre de clients. Cette situation est typique des sites des médias (journaux, agences média, télés), des évènements

35 importants (J.O., expositions, ) et de certaines institutions (musées, bibliothèques, ). Les industries de la finance et de l assurance gèrent aussi des masses considérables de documents L architecture Il s agit de marier harmonieusement des architectures Web et des produits de gestion documentaire (GED) qui ont un historique pré-web conséquent. Deux modèles sont classiquement observés : o Produits de gestion de contenu wébisés : l architecture propriétaire du logiciel est conservée et frontalisée par des serveurs HTTP. o Produits de gestion de contenu pour le Web. Ils sont souvent alors basés sur un serveur applicatif J2EE ou.net. La problématique de performance engage à utiliser au maximum les propriétés de cache du contenu en différents points du réseau. Selon que l on cible le côté client, le coté serveur origine ou le réseau lui-même, des solutions diverses sont envisageables Les implémentations et leurs parts de marché Les fournisseurs majeurs classiques de gestion de contenu sont Documentum, Interwoven, Vignette et Divine. Il est illusoire de comparer rapidement les fonctions. L analyse technique suivante est donc sommaire : o Documentum : 4i WCM propose des APIs J2EE (DFC) et supporte XML, XSL, SOAP / WSDL. Les nouveaux entrants sont très nombreux et le marché est dans un état turbulent, avec une centaine de produits, dont les prix s échelonnent de 0 à 500 K ou plus. Pour ce qui est des musées français par exemple, les choix techniques sont souvent orientés autour de solutions en logiciel libre. Zope (voir encadré) peut être considéré comme un framework de gestion de contenu, plus que comme une solution ; il est possible de débattre sur la «taille» de problème de gestion de documents à laquelle Zope est adapté. Zope Zope est un framework en logiciel libre, permettant de construire des solutions de gestion de contenu ou de groupware. Il est basé sur un modèle LAMP avec Python comme langage. Zope a un club assez actif. Les revenus de Zope Corporation, le créateur de Zope, sont générés en mode service. Les solutions de cache réseau sont soit orientées produits, à acheter par les FAIs* (NetworkAppliance, F5 ) soit orientées services, à acheter par le fournisseur de contenu (Akamai). Ce choix n est pas sans impact sur l application elle-même Standards associés Il n existe pas de standards universels stabilisés en terme de gestion de contenus, bien que de nombreuses initiatives autour de XML soient en cours. Mentionnons en particulier : le standard RDF* du W3C, dans le cadre du Web Sémantique, WebDAV* pour la publication,

36 la norme de méta-données du Dublin Core (DCMI*). PROJET Il y a bien sûr des standards de formats pour les documents eux-mêmes : SGML, HTML, XML, RTF, PDF, PostScript, Office Analyse multi critères Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession souvent élevés élevés Scalabilité performance + Evolutivité fonctionnelle ++ Outils souples Robustesse intrinsèque + Robustesse extrinsèque + Sécurité + Développement + Nombreux outils Présence du fournisseur 0 selon le fournisseur Parts de marché 0 selon le fournisseur Implément. J2EE + possible Implément.NET + possible Implément LAMP - un peu juste Critères d interopérabilité HTML + XML + Services Web 0 En gestation Composants 0 selon le fournisseur Standards + En gestation Interop..NET 0 Interop. J2EE Outils et méthodes associés En dehors des éditeurs de documents trop nombreux pour être cités ici, les outils sont propriétaires et dépendants du produit choisi. Voir néanmoins le standard WebDAV* pour la publication Streaming son/vidéo

37 Le besoin PROJET Les besoins traditionnels de streaming dans l entreprise, tels que la vidéosurveillance et la vidéoconférence sont désormais rejoints par les besoins exprimés par les partisans de la convergence multimédia : diffusion des radios et TV sur Internet, achat d événements asynchrones (VOD) et la communication d entreprise (communication interne et formation) L architecture Quatre éléments distincts se succèdent : Le formatage et l encodage du signal audiovisuel. Le média peut être de la forme fichier (WAV ou AVI par exemple) ou d un signal compressé (MPEG1, MPEG2, MPEG4 ou MJPEG) ou non (DV, composite) ; L encodage transforme ces formats vers le format ou les formats supportés par le client. Le résultat est un fichier ou directement en un flux. Le flux est généralement diffusé en mode broadcast ou multicast pour permettre aux clients de se connecter de façon asynchrone sur un port et une adresse donnée. Le serveur de médias. Ils fonctionnent en deux modes : le multicast pour la connexion asynchrone des clients sur des flux diffusés et l unicast pour une connexion à la demande (le flux ou fichier n est diffusé que pour le client) Le réseau Tout se qui est à base IP, plus généralement : HTTP/TCP/IP en mode WEB standard sans serveur dédié qui permettent de passer aisément les firewalls du réseau, malheureusement ce protocole est difficilement temps réel. UDP/IP pour les diffusions broadcast ou multicast, malheureusement quasiment systématiquement bloqué par les firewalls du réseau. RTSP subtil composition des deux précédents, il s agit bien sur de la solution adaptée au streaming média sur IP. Ce protocole permet d implémenter les fonctions classiques du magnétoscope (marche, arrêt, pause, avance et retour rapide, enregistrement et montage). Inspiré de HTTP et incluant ses mécanismes de sécurité (SSL et authentification), il autorise le maintien de connexion nécessité par exemple par la fonction pause, l étiquetage des contenus, le paiement électronique, amis surtout il autorise la commande à distance des serveurs multimédias indispensable au client lecteur. Le client (player). L accès s effectue par l intermédiaire d une page WEB qui contient soit un répertoire d objets, soit un protocole d accès au serveur de médias

38 Ce client utilise soit la norme (MPEG2 ou MPEG4 principalement, bientôt H264), soit un dérivé de la norme qui, grâce à des raccourcis permet d avoir une qualité meilleure à débit identique au détriment de l interopérabilité. Cette interopérabilité est régulièrement testé par l ISMA tant au niveau protocole de transfert que méthode de compression. Un cinquième élément intervient sur les sites payants : la gestion des droits et des clés de cryptage. Le piratage lié à la diffusion de fichiers MP3 a conduit à la constitution du SDMI pour la diffusion de musique, aux concepts de DRM pour la diffusion vidéo. Nous ne traitons pas ici des systèmes connexes (facturation, gestion des clients, interactivité) Les implémentations et leurs parts de marché Les deux acteurs principaux du marché sont : RealNetworks et Windows Media Player, un troisième se maintient à distance : QuickTime. Il est remarquable que ces deux clients utilisent la norme MPEG4 pour l interopérabilité et leur propre syntaxe dérivée pour gérer un parc fermé. Pour des raisons d envies hégémoniques, chacun défend âprement son format contre la norme. Trois secteurs apparaissent : L entreprise (formation, communication interne, conférence) est un domaine dont l essor est accentué par les difficultés de transport liées au terrorisme. Les médias classiques (journaux, radios et TV) qui migrent vers des supports de diffusion informatique (Internet principalement mais aussi les réseaux câblés ou ADSL de demain) et reprennent des concept de PPV (Pay Per View) et PPL (Pay Per Play). Les nouveaux services de diffusion de médias à la demande (VOD, NVOD) En plus de ces trois acteurs, une multitude d entreprises proposent des systèmes de compression et de diffusion : Envivio, Ivast, VideoLocus, Standards associés Pour la diffusion des signaux audiovisuels, le standard apparaissant comme incontournable est MPEG4 pour la compression, la diffusion et la synchronisation des objets multimédia. Le concept d animation de scène offre la souplesse nécessaire au montage et à l interactivité. Une évolution de MPEG4 est le standard H264 (également appelé MPEG4 part 10) qui offrira une meilleure qualité à des débits inférieurs. Pour le protocole réseau, RTSP est bien sur la solution adaptée au streaming média sur IP. Ce protocole permet d implémenter les fonctions classiques du magnétoscope (marche, arrêt, pause, avance et retour rapide, enregistrement et montage). Inspiré de HTTP et incluant ses mécanismes de sécurité (SSL et

39 authentification), il autorise le maintien de connexion nécessité par exemple par la fonction pause, l étiquetage des contenus, le paiement électronique, amis surtout il autorise la commande à distance des serveurs multimédias. Notons que pour la diffusion de flux audio, l alternative peut être d utiliser les protocoles MIDI, la synchronisation avec des évènements textuels pouvant être faite en utilisant SMIL dont le langage de composition de médias est compatible avec XML. Pour la compression audio, il existe bien entendu la norme de compression MPEG1 pour une qualité VHS et MPEG2 pour une qualité DVD. Deux améliorations sensibles de la qualité (à débit constant bien sur) sont MPEG Layer3 (improprement appelé MP3) et le format AAC Analyse multi critères Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession Scalabilité performance ++ en baisse peu de retour d expérience (équilibrage de charge et débit ajustable) Evolutivité fonctionnelle 0 Robustesse intrinsèque - Produits encore jeunes Robustesse extrinsèque - Produits encore jeunes Sécurité -- Problèmes de piratage Présence du fournisseur + Parts de marché 0 Implément. J2EE + Implément..NET + Implément. LAMP + Critères d interopérabilité HTML ++ XML + Services Web ++ Composants 0 dépend du fournisseur Standards + en gestation Interop..NET 0 dépend du fournisseur Interop. J2EE Outils et méthodes associés

40 Un éditeur d application par fournisseur logiciel, notons cependant que la norme MPEG4 à travers la gestion des scènes procure un «langage» commun de description, mais les implémentations restent très libres Cas d utilisation Si le streaming Internet progresse bien en Asie et aux Etats-Unis, ce n est pas encore le cas en Europe : notons néanmoins quelques portails TV : émanation de TDF. Une explication possible de ce frein est le déploiement des sites de diffusion MPEG2 pas encore amortis par les opérateurs TV et la frilosité contextuelle des opérateurs télécommunications. Un axe de développement est la communication d entreprise, à travers la vidéoconférence et la formation qui permet de réduire les déplacements et l indisponibilité des personnes

41 3.5 - CATEGORIE DECISIONNEL Le besoin Le besoin émane des acteurs de l entreprise qui, pour remplir leurs objectifs/missions doivent prendre des décisions et piloter. Ces décisions, pour être pertinentes, nécessitent des clichés et des analyses des données de production de l entreprise adaptés (Datawarehouse) aux exigences des utilisateurs. Ces différents clichés n existent pas toujours, d où des besoins inopinés (à la volée, impromptus) qui peuvent réclamer l ensemble des données de production aménagées, voire leur historique (pour des analyse de tendance par exemple). Il s agit par ailleurs de mettre à disposition des ces utilisateurs des outils qui leur permettent de réaliser des clichés/analyses eux-mêmes à discrétion. Bien évidemment, la rapidité des décisions est un facteur clé de réussite, ainsi la fraîcheur des clichés de données/historiques oblige les architectures résultantes à être équipées de composants bien ciblés quant aux types & nombre d utilisateurs, aux volumes brassés, à la cohérence des données manipulées, aux clichés/analyses potentiellement possibles et à la matérialisation de ceux-ci Les architectures Ce sont des architectures 3-tier classiques ou hybrides selon les besoins de l entreprise : 1. Au niveau du serveur de données, il est possible d avoir des contentions au niveau CPU et/ou au niveau E/S. Pour répondre à ces deux problèmes, le parallélisme (intrinsèque CPU et/ou données) d une part et d autre part la possibilité d accroître les ressources le plus linéairement possible peuvent être introduits. Les architectures résultantes peuvent être de type SMP ou grappe. 2. Les serveurs d applications sont plutôt considérés comme des serveurs intermédiaires (l application n étant à priori définie ; seul le besoin générique est connu). La combinatoire entre ces deux niveaux de serveurs fait appel à un mapping de l exploitation des données essentiellement dépendant des besoins et du volume de celles-ci. Ainsi, selon la combinatoire, on aura à faire à du MOLAP, ROLAP ou du HOLAP. 3. Trois variantes sont possibles pour matérialiser/router/publier les restitutions : LAMP, J2EE/libre et.net (voir ). En revanche, le Data Mining la plupart du temps s inscrit en mode client/serveur traditionnel (publiable ou non en Web) ; ceci est dû principalement à l ancienneté des outils (origine Mainframe) qui utilisent des algorithmes connus depuis plus de 20 ans (Fortran, APL,...) et au faible nombre d utilisateurs potentiels Les implémentations et leurs parts de marché

42 Les 10 acteurs les plus importants du marché sont : 1 Oracle 2 SAS 3 IBM 4 COGNOS 5 CA 6 Teradata 7 Microsoft 8 SAP 9 Micro Strategy 10 People Soft Standards associés Concernant le décisionnel, le seul standard vraiment spécifique est la conformité au CWM* qui implique par ailleurs XML. Les autres normes sont déjà traitées dans le cadre des architectures traditionnelles Analyse multi critères Les offres majeures sont celles d ORACLE, IBM DB2 et Microsoft (une offre ouverte, une offre propriétaire, un challenger). En effet, les autres offres sont de toutes façons juxtaposables/combinables aux trois offres retenues. TERADATA, peu répandu en France (TRANSPAC, La Poste, Chronopost,...) est exclusivement réservé aux grands comptes et connu depuis fort longtemps

43 Oracle Critère Commentaires Critères généraux Coûts d achat Coûts de possession Scalabilité performance Evolutivité fonctionnelle Licences assez chères selon compétences pré-requises. ++ Bon en SMP & NUMA, moins convainquant en MPP. ++ Ad-hoc Robustesse intrinsèque + Selon configurations Robustesse extrinsèque + Selon configurations Sécurité + Dans son univers Développement + Ecosystème varié Présence du fournisseur Parts de marché ++ Bonne ++ N 1 SGBDR Critères d interopérabilité HTML + Fonction de la combinatoire XML ++ Associé au CWM Composants 0 peu pertinent Standards + flexible Services Web + Oracle Portal Interop. J2EE + Possible en greffant SAS, BO, COGNOS,... Interop..NET 0 Fonction de la combinatoire

44 IBM DB2 Critère Commentaires Critères généraux Coûts d achat Coûts de possession Licences propriétaires chères selon compétences pré-requises. Scalabilité performance + Evolutivité fonctionnelle ++ Ad-hoc selon Outils juxtaposés Robustesse intrinsèque ++ Atout propriétaire Robustesse extrinsèque ++ Atout propriétaire Sécurité ++ Atout propriétaire Développement + Assez complet Présence du fournisseur ++ Bonne Parts de marché + N 1 propriétaire Critères d interopérabilité HTML + Fonction de la combinatoire XML + Associé au CWM Composants 0 Peu pertinent Standards + Flexible Services Web + Portail Interop. J2EE ++ WebSphere, fonction de la combinatoire Interop..NET 0 Possible en greffant SAS, BO, COGNOS,

45 Microsoft Critère Commentaires Critères généraux Coûts d achat Coûts de possession Modéré, extension Licences souvent déjà acquises selon compétences pré-requises, souvent le cas grâce à son implantation clients Scalabilité performance 0 Moyen en SMP peu prouvé. Evolutivité fonctionnelle ++ Ad-hoc, ACCESS, Excel, selon Outils juxtaposés Robustesse intrinsèque 0 Origine SYBASE + AdOne Robustesse extrinsèque 0 selon réputation Sécurité 0 réputation connue Présence du fournisseur + Surtout forte en bureautique et réseau Parts de marché 0 Challenger pour l instant (VLDB?) Critères d interopérabilité HTML + Fonction de la combinatoire XML 0 XML oui mais pas membre du CWM Composants 0 Peu pertinent Standards - Selon la stratégie du vendeur Services Web + Portail Interop. J2EE + Fonction de la combinatoire Interop..NET ++ C est l auteur Outils et méthodes associés L élaboration d une architecture globale de Data Warehousing met en évidence plusieurs typologies d outils représentés sur le schéma ci-après :

46 source OSIS Collectif Data Mining Opérationnel Infocentre SIAD EIS Tableaux de bord Applicatifs Métier Fonction Outils de mise en forme Aide à la Décision Tableurs Individuel Cas d utilisation A.N.P.E : Superdome HP (SAN, SMP) ORACLE + SAS (programme de SPNDE & MAIDEF (PAR & PAP) en cours), Enjeux politiques forts, Taille de base de 1 To, Couverture fonctionnelle (y compris Data Mining) totale 1200 utilisateurs (DG, DRG, ALE) CATEGORIE COLLABORATIF Le besoin

47 L objectif est de favoriser le travail en groupe avec des outils informatiques. Cette problématique recouvre donc un ensemble très varié de produits destinés à faciliter la communication et le partage d information. Cela peut aller jusqu au segment en vogue de la gestion des connaissances L architecture Il n existe pas d architecture à tout faire. Mais la typologie architecturale tourne autour de l opposition centralisé / distribué, aussi bien au niveau logique qu au niveau de l implémentation. Au niveau logique, certains services sont structurellement de type pair à pair, distribués sur les postes de travail : o Messagerie électronique, o Workflow documentaire, o Chat, o Vidéoconférence. D autres services sont par nature de type centralisé, au sens que le modèle contient une instance unique des données : o Calendrier de groupe, o Documents partagés, o Groupes de discussion, o Tableau (au sens tableau blanc) partagés. Par contre l implémentation technique peut être différente de l architecture logique ; quelques exemples : o Le mél est assuré par un serveur de mél central (lui même en réseau au niveau supérieur) o Lotus Notes gère des documents partagés par réplication en mode distribué o Microsoft Exchange essaie de gérer un calendrier partagé en mode distribué o La distribution musicale en MP3 a passé par une instance centrale (Napster) et est maintenant en mode pair à pair décentralisé (Kazaa, ). o La plupart des architectures logiques pair à pair sont plus faciles à implémenter avec un serveur central : workflow, Cette variété d implémentation est due en général au souci d optimiser l utilisation de la bande passante réseau. Une autre dualité architecturale est l aspect synchrone / asynchrone : o Synchrone : chat, vidéoconférence, tableaux partagés o Asynchrone : mél, news, documents partagés, calendrier

48 De ce fait, il convient de s orienter soit vers des suites de groupware associant de multiples architectures applicatives en un ensemble plus ou moins intégré, soit vers des produits ponctuels assemblés par les utilisateurs Les implémentations et leurs parts de marché Les suites intégrées les plus populaires depuis fort longtemps sont Lotus Notes de IBM et Exchange de Microsoft. Oracle a lancé en 2002 une offre de groupware concurrente. Le Web, grâce l hypertexte en complément au mél et aux groupes de discussion a constitué quasi instantanément une alternative à coût faible à ces outils. Une floraison de produits de groupware basés Web a suivi, sans émergence claire de leaders. De ce fait, en tant que produits pre-web, Notes et Exchange ont dû fortement évoluer pour intégrer les technologies Web, ce qu ils ont fait avec succès. Dans l espace du logiciel libre, il est à noter la popularité de phpgroupware qui fonctionne sur une infrastructure LAMP. Zope (voir ), parfois cité comme un groupware, doit plutôt être considéré comme un atelier permettant la construction d applications communicantes, et donc en particulier de groupware Standards associés En dehors de standards classiques, la collaboration souffre plutôt d un manque de standards de coordination. Par exemple, la norme de calendrier ical reste finalement difficile à exploiter. L interopérabilité entre calendriers est encore un challenge. Pour l essentiel, dès qu il sort des classiques de l Internet (HTML, news, mél), le client devient prisonnier de sa suite de groupware. L initiative WebDAV* s attache à rendre la publication Web interopérable Analyse multi critères Les produits sont trop divers pour qu une telle analyse ait un sens Outils et méthodes associés Ils dépendent du logiciel sélectionné CATEGORIE PGIs La catégorie des PGIs (Progiciel de Gestion Intégré) est si vaste qu il est difficile de ne pas faire de sous-catégories. Dans un but de concision, la présente étude se limite donc aux PGIs majeurs pour les grands clients. Il ne sera pas traité par conséquent tous les produits pour entités petites ou moyennes, ou les produits spécialisés Historique et émergence des PGIs Les Progiciels de Gestion ont pratiquement toujours existé (au moins depuis 1957, premier plan comptable)

49 Dans un premier temps, il s agissait souvent d une reprise et d une adaptation d un patrimoine informatique déjà existant qui avait fait ses preuves chez un client ayant une activité analogue. Dans un deuxième temps, l idée a germé, principalement chez les grands constructeurs de l époque, d intégrer ces petits progiciels dans une structure/présentation unique (apparition des PGIs vers le début des années 80 ; époque encore propriétaire). Puis l émergence des PGI tels que nous les connaissons aujourd hui a été favorisée par : Le besoin L apparition des systèmes ouverts (UNIX), L apparition des normes et standards internationaux ainsi que des méthodes, La maturité d analyse des différents domaines fonctionnels des entreprises, Les délais de mise en œuvre, La peur de l an 2000 et du passage à l Euro, L aide à la réorganisation des entreprises, La mondialisation pour les grands comptes. Les PGIs répondent aux besoins informatiques bien formalisés des entreprises ; en adoptant un progiciel, on implémente de-facto les bonnes pratiques de l industrie plutôt que de développer une application spécifique. Les PGIs répondent donc bien aux besoins de l entreprise en dehors de son cœur de métier. Par contre, il est peu vraisemblable qu une entreprise puisse trouver sur le marché le PGI qui va informatiser correctement sa valeur propre, ce qui la différentie de ses concurrents. Ceci relève d un développement spécifique L architecture Les PGIs de haut de gamme, plus spécialement Baan, Oracle Business Suite, Peoplesoft, SAP et Siebel, visent tous des grands clients et des populations vastes et utilisent tous une architecture n-tier. o Tier données : tous sont basées sur une grande base unique et centralisée. Parfois propriétaire (SAP DB), c est maintenant en général Oracle et DB2 au choix. Il est rare que le mode cluster des bases soit supporté. o Tier applicatif : La plupart ont démarré avec un serveur d application propriétaire (SAP, Oracle, Siebel). D autres ont utilisé Tuxedo (Peoplesoft). La plupart de nos jours ont adjoint un serveur d applications J2EE pour les nouveaux modules : c est le cas pour Oracle (ias), SAP (serveur 2EE de SAP), PeopleSoft (WebLogic)..NET est très peu populaire chez ces grands vendeurs comme architecture sous-jacente. L interopérabilité.net est par contre très développée. o Tier présentation pour les humains : la plupart disposent à la fois d un client mi-léger propriétaire (gestion de formulaire) et d un client Web léger en HTML

50 o Tier présentation applicative : tous les PGIs ont le besoin de présenter des APIs au monde extérieur. Dans les années 90, ces APIs étaient propriétaires (Exemple : les BAPIs de SAP). De nos jours, presque tous ont annoncés une présentation de type Web Services, mais il convient de noter que les implémentations tardent à suivre Les implémentations et leurs parts de marché Le marché des PGIs est relativement segmenté (ERP, SCM, CRM ). Tous les grands acteurs viennent d un segment (par exemple la GRH pour PeopleSoft) et cherchent à s étendre pour couvrir tous les besoins d une entreprise Ce mouvement se fait essentiellement sur l axe front-office back office, vers le front office pour SAP, Baan et Oracle, vers le back office pour Siebel qui est né dans le CRM. Cette approche totalisante est de nos jours considérée comme peu réaliste, du fait des acquisitions et de la dépendance excessive vis à vis d un vendeur. La tendance est donc plutôt au choix d un sous-ensemble restreint de PGIs interopérant à travers un EAI (voir ). Le logiciel libre et les PGIs Un débat agite la communauté sur le PGI comme source de crédibilité pour le concept de logiciel libre en dehors du monde des informaticiens. Un exemple d effort en ce sens qui a un certain succès est Compiere ( un PGI pour PME (ERP et CRM, écrit en Java, SGBD Oracle pour le moment) Standards associés J2EE et Services Web sont les deux standards les plus structurants pour l infrastructure des PGIs haut de gamme. Pour la partie métier, un certain nombre suivent les recommandations des organismes horizontaux (comme OASIS ebxml) ou verticaux (RosettaNet, ) Analyse multi critères Elle est faite pour les leaders du marché des grands PGIs

51 Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession parfois élevés significatifs Scalabilité performance 0 Evolutivité fonctionnelle 0 Robustesse intrinsèque 0 Robustesse extrinsèque 0 Sécurité 0 Développement + Selon le produit, mais aussi J2EE Présence du fournisseur 0 Parts de marché 0 Implément. J2EE ++ choix préféré Implément.NET 0 seulement pour le milieu de gamme Implément LAMP - rare (pour le moment?) Critères d interopérabilité HTML 0 XML 0 Services Web 0 Composants + A la mode Java Standards 0 Peu réactifs Interop..NET + Correcte Interop. J2EE ++ Bonne Outils et méthodes associés Les outils sont propriétaires ou Java pour ceux qui ont adoptés un complément J2EE pour certains modules (voir alors ) Cas d utilisation Le progiciel financier de PeopleSoft est utilisé par l état français pour le projet ACCORD de gestion des dépenses publiques, déployé sur la période

52 3.8 - CATEGORIE INTEGRATION APPLICATIVE Le besoin Comme expliqué en 5.4 -, il est nécessaire de communiquer entre applications. Ceci est vrai aussi bien pour les applications développées en interne, tout au long des années, que pour les PGIs adoptés au fil du temps, des acquisitions et des fusions. Toute entreprise ayant une histoire conséquente est à la tête d un patrimoine applicatif hétérogène et communiquant L architecture Trois catégories peuvent être distinguées : L approche la plus répandue est une implémentation ad-hoc (spaghetti point à point) qui a l énorme avantage d avoir un coût de démarrage faible, et un coût de maintenance dissimulé dans la maintenance applicative. Dans le cas où le nombre d applications est limité, c est aussi la solution la moins chère. Il ne faut pas considérer le terme spaghetti comme péjoratif. Il est possible de les implémenter avec des technologies modernes comme XML et des Services Web et obtenir un résultat raisonnablement maintenable si le nombre d applications est faible. Business Process Manager Routage & Transformation des données Règles métier Sémantique applicative Message Oriented Middleware Communication EAI «classique» : chaque produit a tendance à avoir son architecture, même si tous partagent plus ou moins un schéma en couches comme cidessous : Presque tous les produits sont bâtis sur une architecture de type serveur d application, mais certains plus récents utilisent une base J2EE ou.net. mais de toute façon, les formats pivots utilisés, les transformateurs de données, l architecture des adaptateurs et le langage de workflow (BPM) sont spécifiques. Web Services / XML : dans ce modèle émergent, le moyeu interagit avec les applications autant que faire se peut via des protocoles Web Services (SOAP sur HTTP ou JMS). Si les applications fournissent elle-même un interface SOAP (voir ), il n y a pas d adaptateur à développer. Si ce n est pas le cas, le produit d EAI fournit un ADK (Adapter Development Kit) qui permet de développer l adaptateur dans le cadre de la technologie du produit (J2EE ou.net). Les produits les plus avancés auront prochainement un BPM conforme à la proposition de standard BPEL4WS*

53 Les implémentations et leurs parts de marché Les 10 premiers vendeurs d EAI en 2001 sur le marché mondial (WinterGreen Research) : Rang (2000) Vendeur Parts de marché % 1 (1) IBM (2) TIBCO (5) WebMethods (8) SeeBeyond (4) Vitria (7) GXS (10) Sun (iplanet) (3) Sybase (6) Mercator (9) BEA 4.2 Autres 22.7 Il est à noter que le marché est encore assez fragmenté. Microsoft, IBM, WebMethods et BEA promeuvent activement l approche intégration par les Services Web. Tous les vendeurs ont un discours résolument orienté Web. La qualité de l implémentation est encore variable vu la jeunesse de la technologie. Les vendeurs de serveurs d application utilisent leur serveur d application comme socle pour leur serveur d intégration (BEA, IBM, MicroSoft, Sun, Sybase). Les autres vendeurs ayant hérité d un socle propriétaire ajoutent en général un environnement J2EE/JCA/JMS et font cohabiter les 2 architectures. Le produit de Microsoft, BizTalk 2002, n a pas encore un vrai support natif des Services Web. Il faut attendre «BizTalk.NET» Standards associés XML, XSLT, SOAP, WSDL, JCA, JMS, BPEL4WS Analyse multi critères En se basant l hypothèse raisonnable que les vendeurs ignorant le phénomène Services Web sont voués à disparaître du marché de l intégration applicative à moyen terme, l analyse multicritères est centrée sur les produits des vendeurs promouvant cette approche

54 Critère Note Commentaires Critères généraux Coûts d achat Coûts de possession Les produits sont encore chers Les services à associer sont conséquents Scalabilité performance + Basés sur des serveurs d application 3-tier Evolutivité fonctionnelle ++ Un BPM est très souple Robustesse intrinsèque 0 Produits peu matures, en forte évolution Robustesse extrinsèque + Architecture saine Sécurité + Développement + En plein essor Présence du fournisseur 0 Selon le cas Parts de marché 0 Voir ci-dessus Implément. J2EE Implément..NET La plus crédible pour le hub BizTalk pour le hub Implément. LAMP Pour certains «rayons» Critères d interopérabilité HTML 0 Sans grande importance XML ++ Services Web ++ Composants 0 Peu pertinent Standards ++ C est l objectif Interop..NET + via les Services Web Interop. J2EE + via les Services Web Outils et méthodes associés Pour programmer les adaptateurs, les outils associés à la technologie utilisés sont utiles. Tous les outils associés aux Services Web sont pertinents si l on utilise ce moyen pour communiquer. L application BPM ouvre la voie à des outils de développement visuels divers et variés (par exemple BEA WebLogic Workshop), parfois couplés en amont à des outils de simulation en UML (par exemple de MegaInternational vers BizTalk et d autres EAI)

55 4 - APPROCHE ARCHITECTURALE Ce chapitre aborde les principales considérations architecturales qui permettent de juger des propriétés des architectures applicatives : modèles applicatifs, protocoles et APIs, rappel historique, avantages et inconvénients du n-tier, frontière application/infrastructure, composants et frameworks Modèles décrivant une architecture applicative Une approche «naïve» des architectures applicatives consiste à distinguer «mainframe», «client serveur» et «3-tier» (voir encadré). Cette approche est trompeuse car elle mélange histoire et architecture, et confond architecture logique et architecture physique. Elle sera néanmoins reprise au du fait de sa popularité. Les deux modèles les plus structurants pour les architectures applicatives sont tous les deux organisés en couches : o Les 7 couches du modèle OSI* de l ISO : généralement représentées comme verticales, de bas en haut du physique au logique sur les schémas Un tier, deux tiers, trois tiers, n-tier Le mot anglais tier est généralement utilisé, même en français, pour caractériser la topologie des applications ; il signifie «niveau». Les architectures multi niveaux ont débuté avec le 3-tier, ce qui a introduit une fâcheuse confusion homophonique avec le français tiers. Enfin, la construction n- tier en anglais s écrit sans s. On a adopté dans ce document le mot tier et l orthographe anglaise pour n-tier. o Les couches du modèle n-tier : généralement représentées comme horizontales, de gauche à droite du client aux données sur les schémas. Pour éviter la confusion, ces couches verticales seront dénommées tiers. Ces deux modèles sont orthogonaux et donc complémentaires. Nous les décrivons ci-dessous. Il paraît toutefois important de préciser que le modèle OSI n est plus vraiment utilisé de nos jours pour décrire les architectures applicatives et que dans le reste du document, la vision par tier sera privilégiée Modèle OSI à 7 couches Ce modèle a été conçu dans les années pour structurer une architecture informatique distribuée. Il est constitué de 7 couches :

56 Nom Mots clef Exemple 7 Application SAP BAPI 6 Présentation transcodage, compression, cryptographie MIME 5 Session dialogue, synchronisation RPC 4 Transport connexion, datagramme, séquence, acquittement 3 Réseau adressage, routage fragmentation TCP, SCSI3 IP APIs 2 Liaison trame, contrôle d erreur IEEE Physique matériel Ethernet 100baseT Chaque nœud du réseau contient un sous ensemble plus ou moins complet du modèle : il est possible de supprimer des couches en partant du haut et d avoir ainsi des nœuds de «commutation» à divers niveaux (2 à 6). Ce modèle un peu ancien a plus ou moins bien résisté à l évolution de l informatique ces derniers vingt ans, mais il reste dans l ensemble assez pertinent : o Les couches 1-4, dites couches de transport représentent bien la pile TCP-IP qui est devenu le standard quasi unique de communication. o Les couches 5-7, dites couches applicatives, ont plus de mal à suivre l évolution. En particulier, les modèles de communication de type appel de procédure à distance (RPC*) ont tendance à mêler des éléments de type session et des éléments de type présentation. La communication entre couches se fait par des interfaces applicatives appelées APIs*. Une API est en général lié à un langage informatique. La communication entre nœuds du réseau se fait par des protocoles. Souvent un même acronyme désigne l API et le protocole, ce qui entretient une certaine confusion

57 Nom 7 Application 6 Présentation 5 Session 4 Transport 3 Réseau 2 Liaison 1 Physique Protocoles Nom 7 Application 6 Présentation 5 Session 4 Transport 3 Réseau 2 Liaison 1 Physique Modèle n-tier Un «tier» caractérise une fonction particulière de l application. D une manière simpliste, une première séparation entre données et traitement est apparue. Ensuite les traitements ont été scindés en deux aspects : métier et présentation. Actuellement le modèle de référence repose sur une architecture en 4-tier puisque les clients sont parfois représentés comme un tier à par entière. Client Présentation Métier Données Architecture logique 4-tier Le tier présentation s occupe de l interaction avec l utilisateur, en entrée et en sortie, Le tier métier prend en charge les traitements en fonction des processus métiers, Le tier données s occupe de la persistance des données. Attention, il ne faut pas confondre le tier présentation du modèle en tiers et la couche présentation du modèle en couches OSI. Rigoureusement, le client n est pas un tier ; ce client peut être considéré comme faisant partie de la présentation, ou n appartenant pas à cette typologie. Il est néanmoins pratique et donc pratiqué de représenter ainsi le modèle. Le modèle à 4-tier peut être condensé en 3-tier ou étendu en 5-tier ou 6-tier selon la complexité du problème à résoudre et selon l organisation

58 Ce modèle est orienté utilisateurs. Il est utile de le compléter par un module d intégration applicative dans le tier présentation : Utilisateurs Applications Présentation humaine Présentation applicative Métier Données Architecture logique 4-tier complète Cette représentation n est pas totalement conventionnelle. Certains représentent le concept de «présentation applicative» ou «intégration» comme une fonction externe au modèle 3-tier. Il est délicat de trancher, et surtout de vouloir modéliser l architecture informatique aussi simplement. Le modèle n-tier est une représentation d une architecture logique ; elle signifie simplement que le code de l application est composé de modules qui implémentent chacun un tier particulier, sans référence particulière aux ordinateurs servant à instancier l architecture. Les deux modèles complémentaires peuvent être globalement représentés ainsi : 7 Application Client Présenta tion Métier Données 6 Présentation 5 Session APIs 4 Transport 3 Réseau 2 Liaison 1 Physique Protocoles Structure du tier client Selon son «poids», le tier client est structuré différemment :

59 o Un client lourd est dans la plupart des cas une application Windows traditionnelle (c est à dire en mode WinForms, et pas en mode WebForms). Les multiples modalités et langages possibles ne seront pas décrits. o Un client léger est un navigateur ; sa fonction est double. D une part, il doit faire une interprétation correcte des langages de présentation reçus du serveur (HTML en général, WML* pour un navigateur sur un téléphone mobile, XML peut-être dans le futur). Dans cette fonction, le navigateur est un interpréteur et le langage un langage de description de données mis à la disposition du programmeur. D autre part, pour animer les pages HTML, il existe diverses options, du simple DHTML ou JavaScript, en passant par des langages propriétaires comme Shockwave et en allant jusqu à une programmation classique (Applets Java ou contrôles ActiveX). o Un client ultra léger est une variante d «écran vert» et se borne à restituer un protocole de présentation d écran (voir ). Aucune «programmation» n est disponible Structure du tier présentation La fonction de présentation des données est distribuée entre les tiers client et présentation. Dans certaines applications, toute animation du HTML sur le client est proscrite pour des raisons de sécurité, de performance ou d administration. La dynamique de présentation repose alors sur la couche présentation du serveur. Avant la vague Internet, la présentation est souvent réalisée par un gestionnaire de formulaires assez sophistiqué, propriétaire, de type Oracle Forms ou WinForms. Internet interdit en pratique ces modalités et a poussé vers des présentations «pur Web» standardisées mais pauvres par rapport aux possibilités des diverses «Forms». L évolution récente des modèles de formulaires Web implémentés sur les serveurs a néanmoins pratiquement comblé le fossé : o Dans le monde.net, Microsoft souligne que WebForms de ASP.NET (voir ) est souvent tout à fait concurrentiel avec WinForms o Dans le monde Java, le modèle JSP et XML ont permis à Oracle par exemple de promouvoir des formulaires assez sophistiqués instanciés sur le serveur d application. o Des modèles de formulaires basés XML apparaissent, encore timidement et non standardisés Structure du tier métier Le tier métier, est avec les données, un des deux piliers du système d information puisqu il implémente les règles métier qui sont le cœur de la pratique de l organisation concernée. Il existe de multiples écoles de pensée sur la meilleure manière de programmer le tier métier. La dialectique procédural / objet est un sujet de débats qui ne sont pas encore clos. Ce point est abordé plus en détail au composants en Le

60 choix du langage de programmation à lui tout seul n épuise pas cette problématique. Un consensus existe sur quelques propriétés optimales du tier métier : o Le tier métier doit pouvoir être distribué de manière transparente pour le programmeur sur plusieurs ordinateurs o La distribution doit être pensée par l architecte de l application et au moment de son déploiement. Sinon, des problèmes de performance peuvent irrémédiablement causer sa perte. o Le tier métier doit savoir gérer des transactions distribuées, même si celles-ci sont rarement mises en oeuvre dans la plupart des applications. o Certaines fonctions très proches des données peuvent valablement être instanciées dans le tier données Structure du tier données Il héberge les données au sens large, soit directement dans des SGBD, soit à travers des procédures sur des systèmes patrimoniaux (mainframes ou OLTP classique) ou des PGIs Données relationnelles Types de données Les SGBDR dominent largement le marché, et de plus, avec l approche «bases de données universelles» de Oracle et IBM avec DB2, ambitionnent de stocker efficacement toutes les sortes de données, par exemple des objets, des structures arborescentes comme les schémas XML ou multi dimensionnelles comme dans le décisionnel, ou du multimédia. Les bases de données spécialisées (XML, objet, multi dimensionnelles, multimédia) sont généralement plus efficaces pour ce type de données non relationnelles, mais la dynamique du marché a empêché l émergence de grands acteurs. Distribution Les bases de données sont distribuables selon 2 modes : o Disque partagé : les instances de la base gèrent un cache mémoire distribué avec un DLM (Distributed Lock Manager) ; o Pas de partage : les instances de la base communiquent au niveau applicatif pour synchroniser les données. Ces 2 modes ont un fort impact sur la scalabilité du tier de données. Voir et Autres «données» La présence de mainframes ou de PGIs dans cette couche est discutable architecturalement car ces systèmes implémentent en fait également une couche métier, mais est une pratique courante dans les présentations n-tier. Dans ce mode, le PGI ou l application patrimoniale est vu comme un super serveur de

61 données. Il serait irréaliste bien sûr de vouloir décrire toutes les possibilités architecturales de ces deux univers. Ils sont abordés en et PROTOCOLES ET APIS Ce chapitre propose une description des protocoles utilisés pour communiquer entre tiers (inter-tiers) ou à l intérieur d un tier (intra-tier), ainsi que les APIs permettant d accéder à ces protocoles. Il convient de distinguer les protocoles et APIs génériques, utilisés dans presque toutes les modalités, et ceux spécifiques à un tier ou à une interface entre tiers Protocoles et APIs génériques Dans le cadre de cette étude, les couches OSI qui ne concernent pas les applications, pour l essentiel, ne sont pas traitées. Un trio API/protocoles générique sur la couche 4 (Transport) et deux APIs génériques sur les couches 5/6 (Session/Présentation) ont été formés. Couche 4 : transport La couche transport est presque normalisée depuis une dizaine d années. Il existe quasiment un seul API universel, dénommé sockets et donnant accès à deux protocoles : l un, orienté connexion, est TCP (Transmission Control Protocol) et l autre, orienté datagramme (message indépendant, sans connexion), est UDP (Universal Datagram Protocol). Sockets est une API en langage C, inventé dans les années 70 dans le cadre de l UNIX BSD développé à Berkeley et ensuite adopté par tous les UNIX, par Windows et par Linux ; il existe des versions dérivées pour tous les langages existant. Il existe cependant d autres protocoles sur la couche 4 : o dans le cadre de la pile TCP-IP : par exemple des protocoles de messagerie électronique comme SMTP, mais ils sont utilisés plus rarement par les applications o dans le cadre d autres piles protocolaires : la pile OSI de l ISO ou des piles propriétaires (Netware IPX/SPX, NETBIOS); mais ils sont beaucoup moins importants depuis 5 à 10 ans. L API sockets avec TCP et UDP est utilisé par tous les tiers en interne et en externe et sert de socle à tous les protocoles des couches supérieures. Couches 5 & 6 : Remote Procedure Call Comme déjà indiqué, le RPC contient des éléments de la couche session. Il implémente la sémantique particulière de l appel procédural, et des éléments de la couche présentation puisque les paramètres d appel et de retour doivent être encodés de manière standardisée. Les APIs de RPC sont bien sûr spécifiques du langage, puisque les types natifs, par exemple, diffèrent selon les langages. Néanmoins ils sont, comme tous les appels procéduraux locaux, très proches

62 Certains RPCs ont des instantiations multi langages (par exemple dans.net, voir , SOAP* ou plus anciennement le RPC de DCE*), d autres sont mono langage (par exemple Java RMI, voir ) On peut aussi distinguer les RPCs internes à un modèle de composants et ceux ayant vocation à faire communiquer des modèles différents (API SOAP par exemple, voir ) : les premiers peuvent avoir une sémantique plus forte au niveau de la vérification des types par exemple, et sont donc sûrs et peu ouverts ; les seconds se doivent d adopter le plus petit commun dénominateur entre les objets communicants, ils sont moins «sûrs» mais plus ouverts. Au niveau des protocoles, tous les RPCs s appuient sur sockets et TCP car ils ont besoin de la qualité de service associée aux connexions. On distingue de même les protocoles propriétaires à un modèle de composants (RMI natif, DCOM) et les protocoles entre modèles de composants, plus intéressants car plus universels : o IIOP* : défini dans le cadre de CORBA*, il permet de faire interopérer des implémentations différentes du modèle J2EE* ou du J2EE et du CORBA. IIOP est en pratique peu utilisé ; o SOAP : dans le cadre des Services Web (voir ), il permet de faire interopérer les modèles J2EE et.net. Le RPC est utilisé plus particulièrement dans les situations suivantes : o Inter tier : Client lourd -> Présentation o Inter tier : Présentation <-> Métier o Intra tier : Métier <-> Métier, rarement Présentation <-> Présentation Couches 5 & 6 : Messagerie asynchrone L alternative au RPC a de tous temps été un modèle de communication asynchrone par messages. Néanmoins, il a été plus difficile d arriver à un modèle concret relativement uniforme, comme pour le RPC, car la sémantique de l envoi de messages est plus complexe. En particulier, à travers les MOMs*, les entités communicantes avaient intérêt à faire transiter les messages via des files d attentes (queues) ou des points de publication (topics). Malheureusement, il n y a pas de modèle universel pour ces objets. Une relative diversité de modèles de files d attentes, de protocoles et d APIs qui se ressemblent tous au niveau supérieur existe. Ils n ont pas de compatibilité, que ce soit pour le programmeur au niveau des APIs ou pour l interopérabilité au niveau des protocoles. Ceci explique la difficulté à faire communiquer par exemple MQseries d IBM et MSMQ de Microsoft. Des «passerelles» sont alors nécessaires. La seule tentative relativement aboutie est JMS*, qui est une API Java (cf ) d accès aux MOMs. Il est possible de décliner l API JMS avec d autres langages. Par contre, JMS n a pas de protocole sous-jacent défini. Donc

63 l ensemble des agents interopérant avec des APIs JMS doit utiliser un seul et unique MOM sous-jacent. Il est probable que cette situation va évoluer à travers l apparition des services Web (voir ). La messagerie asynchrone est plus particulièrement utilisée dans les situations suivantes : o Inter-tiers : Client mobile -> Présentation : c est un bon moyen de pallier aux déconnexions systématiques liées à la mobilité. Cet usage est émergent. o Inter-tiers : Présentation -> Métier : il est parfois utile de découpler le fonctionnement de ces 2 tiers pour donner plus de flexibilité, et dans la mesure où des logiques transactionnelles fortes ne sont pas exigées. o Inter tiers : Métier -> Données : la couche données est souvent plus complexe qu'un «simple» SGBDR et peut comprendre de vastes systèmes patrimoniaux. Il est alors souvent utile de ne pas propager des contraintes de synchronicité intrinsèques au RPC et d introduire l asynchronisme à ce niveau. o Intra-tier : métier <-> métier : la logique métier est parfois compartimentée et il n est pas nécessaire, et même préjudiciable à la fluidité de l ensemble de coupler ces parties de manière synchrone. La messagerie est alors un excellent moyen d isolation des compartiments. o Intra-tier : données <-> données, par exemple pour de la réplication Protocoles et APIs spécifiques au tier client Le client lourd sous Windows dispose d un ensemble d APIs et de protocoles de Windows en intra-tier pour construire l application client. La communication inter-tiers avec le tier présentation se fait en général par le RPC générique. Si un pare-feu est présent, le RPC est alors «tunnélisé» sur le protocole HTTP. Dans certains cas, le client lourd accède directement le tier métier par RPC ou le tier données avec les protocoles spécifiques à ce tier (voir ). Le client léger (navigateur) est très contraint dans le modèle restrictif du protocole HTTP/HTML pour sa communication inter-tiers. Les extensions programmatiques possibles en intra-tier se font par des APIs spécifiques, parfois non autorisés en déploiement pour des raisons de sécurité : o Applets dans le modèle Java o Contrôles ActiveX si le navigateur est exclusivement Microsoft Explorer Protocoles et APIs spécifiques au tier présentation

64 Inter-tiers : le tier présentation communique avec le tier client léger en HTTP/HTML et en RPC avec le tier métier. Un accès direct au tier données avec les protocoles spécifiques à ce tier (voir ) existe également. Intra-tier : les composants du tier présentation communiquent en local selon les modèles servlet (Java) ou composants ASP.NET. Ils reposent en général sur un objet session partagé entre les composants et un mécanisme de communication entre composants spécifique au conteneur Web considéré. La communication en distribué à l intérieur du tier présentation, par exemple dans le cadre d un portail implémenté avec plusieurs portlets, toutes instanciées dans des serveurs Web distribués, se fait via HTTP avec des contraintes topologiques assez fortes sur le réseau d appels possible Protocoles et APIs spécifiques au tier métier Inter tiers : le tier métier communique en RPC ou plus rarement en «message asynchrone» avec le tier présentation ; il communique avec le tier données avec les protocoles spécifiques à ce tier (voir ). Intra-tier : les composants du tier métier communiquent entre eux par RPC ou message asynchrone aussi bien en local qu en distribué, puisqu un composant est par nature distribuable. A l intérieur d un composant existent bien sur les appels procéduraux et autres moyens classiques de communication du langage choisi. Transactions : la couche métier est responsable de la gestion des transactions. Elle inclut donc pour les applications critiques un moniteur transactionnel qui implémente une API et un protocole de transactions distribuées selon le modèle ACID*. En utilisant le vocabulaire du modèle transactionnel XA* (extended Architecture) de l X/Open, le TM (Transaction Monitor) coordonne une transaction distribuée entre plusieurs RM (Resource Monitor) qui peuvent être des SGBDRs, des files de messages ou des applications patrimoniales comprenant le protocole XA. En Java, l API s appelle JTA* et l implémentation du protocole JTS. En.NET, le moniteur transactionnel s appelle MTS et l implémentation de l architecture XA s appelle DTC (Distributed Transaction Coordinator). Les moniteurs transactionnels CICS et Tuxedo sont des exemples d environnement pour des tiers métier transactionnels avec leurs APIs et protocoles propriétaires Protocoles et APIs spécifiques au tier données C est le tier qui a le plus de spécificités au niveau des APIs. Selon que les données sont rangées directement dans un SGBDR ou qu elles sont encapsulées par des «transactions», il existe deux familles d APIs et protocoles spécifiques : Accès aux données relationnelles : une API et un protocole spécifique au modèle de composants (ODBC en C, JDBC en Java, ADO en.net) permettent de transmettre des requêtes SQL au serveur relationnel. La performance de ces interfaces est très critique. Il existe de nombreuses variations et optimisations autour de cette connexion

65 Accès aux données non relationnelles : ce champ est très vaste et mal structuré. Il n existe donc que des «frameworks» de communication permettant d accéder à des applications patrimoniales ou à des PGIs. Il est rare que l on veuille ou que l on puisse accéder directement aux données de la base incluse dans l application patrimoniale ou PGI, car seule l application sait garantir son intégrité. On fait plutôt en sorte que les transactions des applications existantes apparaissent comme des méthodes du modèle objet natif Java2 ou.net ; ainsi, les programmeurs «orientés objet» n ont pas à connaître les particularités du modèle patrimonial ou PGI. Il faut pour cela bien souvent implémenter dans un adaptateur le protocole spécifique de communication de l application interfacée. Dans le mode Java, ces connecteurs utilisent le standard Java Connector Architecture et en Microsoft.NET plusieurs mécanismes ad-hoc (Host Integration Server, messagerie MSMQ ) Architecture physique en tiers De la même manière que pour le modèle logique en tiers, il est possible de définir des tiers physiques, constitués d ordinateurs reliés par des canaux de communication : Serveur 2 Utilisateurs Serveur 1 Serveur 2 Serveur 3 Serveur 4 Architecture physique 5-tier Il existe des dizaines de manières de plaquer une architecture logique n-tier sur une architecture physique n-tier. La décision est prise selon les critères généraux de l entité qui met en oeuvre et ceux spécifiques au projet. L analyse de cet aspect n entre pas dans le champ de la présente étude, néanmoins voici quelques critères pertinents : o Rapport prix performance des serveurs o Capacité des OS choisis pour le multi applicatif o Scalabilité des plate-formes en SMP et en grappe (voir ) o Stratégie de réutilisation du matériel La problématique n-tier, c est à dire combien de tiers logiques et de tiers physiques choisir pour une application, s applique aussi bien au transactionnel qu au décisionnel. Néanmoins, le débat des décennies passées a été essentiellement structuré par la problématique des applications transactionnelles. Les points spécifiques au décisionnel sont traités en HISTORIQUE DES ARCHITECTURES APPLICATIVES

66 En combinant tiers logiques et tiers physiques, toutes les architectures de l histoire de l informatique transactionelle peuvent être obtenues. En simplifiant, trois grandes étapes se sont succédées : Un mainframe classique est caractérisé par une architecture physique 1-tier. Sauf au tout début de l informatique, les tiers logiques ont rapidement été identifiés et tous les systèmes mainframes, même les plus patrimoniaux, sont plus ou moins architecturés comme du 3-tier logique (IBM CICS, Bull TDS ou TP8). Toutefois, la programmation en COBOL permet malheureusement de mélanger le traitement des écrans et le traitement des données. Selon la discipline des programmeurs, les applications patrimoniales ont isolé plus ou moins bien la partie «présentation» (le code de écrans 3270 ou TWS) et la partie «métier» (les transactions). Dans ce modèle, le client est ultra-léger (voir encadré) : écran ou émulateur d écran sur PC (notion de terminal) et le serveur est lourd. Le client serveur classique est une architecture logique 2-tier: un tier données et un tier application qui mélange présentation et code métier. L architecture physique est également 2-tier. Le tier données est instancié sur un serveur de base de données et le tier application sur un PC. Dans ce modèle, le client est lourd et le serveur est variable. En effet, selon les cas, une partie de la logique métier peut être implémentée sur le moteur de base de données comme des «procédures stockées». Le 3-tier le plus classique fait correspondre bijectivement 3 tiers logiques et 3 tiers physiques. Dans ce modèle, le client est plus ou moins léger selon la nature du langage de présentation généré par le tier présentation. Poids du client : le client lourd est relativement bien défini. Il contient tout le code applicatif, présentation et métier. Par contre, il n existe pas de définition universellement acceptée du client léger, ou fin. On s est efforcé d utiliser dans ce rapport une terminologie homogène : Un client mi-léger gère seulement de la présentation. Ce peut être un gestionnaire de formulaires fait par exemple avec un navigateur avec une grosse applet* ; Un client léger est un navigateur sans applets significatives ; Un client ultra-léger ne gère que du graphique. C est un terminal évolué, s appuyant par exemple sur les technologies CITRIX ICA* ou Microsoft RDP*. Historiquement, ces trois modèles se sont succédés comme des architectures de référence. Ils cohabitent, mais la bonne pratique recommandée actuellement est le n- tier. Essayons d analyser le pourquoi. Les critiques du modèle mainframe ont été bien plus liées à des modèles économiques qu à des modèles architecturaux. Le modèle logique du mainframe des années 80 n est pas très différent du 3-tier actuel. De plus, les systèmes d exploitation des mainframes ont des dispositifs variés et fort sophistiqués (partitionnement, gestionnaires de charge) qui permettent de faire cohabiter aisément les tiers logiques sur un seul tier physique. L émergence du modèle client serveur dans les années 80 correspond à une évolution économique liée à la baisse du coût et à l augmentation de puissance du matériel qui a permis l apparition du PC Windows et du serveur UNIX qui sont les composants majeurs de ce modèle, couplé avec la domination des SGBDR. Il s agissait essentiellement de remplacer les MIPS chers du mainframe par les MIPS

67 relativement bon marché de ces nouvelles machines. Presque aucune considération architecturale n a présidé à cette évolution. Il peut même être considéré qu il y a eu une régression architecturale puisque les tiers présentation et métier se sont retrouvés mélangés. Néanmoins, ce modèle a permis l'apparition de nouveaux paradigmes ergonomiques (multi fenêtrage, Wysiwyg, souris, ) qui ont modifié radicalement la perception des applications informatique par les utilisateurs. L apparition du 3-tier est liée aux déconvenues du client lourd intrinsèque et du modèle client serveur classique. Le PC du client est devenu une source de coûts d administration élevés du fait de sa nature distribuée et extrêmement peu sécurisée, que ce soit physiquement ou logiquement. La «révolution 3-tier» consiste donc à extraire la logique applicative du poste client pour la remettre sur un serveur, environnement plus facile à sécuriser et à administrer. Selon qu on rapatrie seulement le tier métier, ou également le tier présentation, on obtient un client miléger ou léger. Le modèle logiciel FORMS d Oracle par exemple est un client miléger qui ne gère que la présentation FORMS avec un tier «Métier + Données» agrégé autour de la base de données Oracle avec ses procédures stockées. Du faux 3- tier diront certains. A l inverse, un modèle Web, avec le client léger qu est le navigateur, rapatrie la totalité de la présentation dans les serveurs. Du vrai 3-tier pour les puristes. Front office et back office Le front office est l informatique en relation avec le client. Le back office est l informatique de production des biens ou des services. Le back office a longtemps constitué le cœur de l informatique de gestion. La GRC* (ou CRM) a fait émerger le front office. Du point de vue de l architecture applicative, cette distinction n est pas très structurante. Les applications de ces deux compartiments (et du middle-office que certains identifient entre les deux) ne se différencient pas significativement par leur architecture applicative (voir ). Il est important de noter que l apparition du Web autour de 1995 a imposé le client léger. Il s est en effet avéré difficile de gérer du code de présentation sur le poste client, même par téléchargement automatique. Il est important de noter le relatif échec des applets Java sur le poste client, au moins sur Internet du fait de la faible bande passante. Il y a donc eu une conjonction d intérêts à un moment donné : le modèle Web exigeait un client léger et le modèle n-tier avait besoin d une «application phare». D où l apparition du serveur d applications Web. Cette description historique montre que les arguments d architecture applicative ne sont pas forcément primordiaux et en tout cas mobilisés au service des stratégies économiques des acteurs AVANTAGES ET INCONVENIENTS DE L APPROCHE N-TIER Il importe de revisiter à froid les vrais avantages architecturaux des architectures n- tier avec client léger, par rapport à des architectures client-serveur avec client lourd. Ils tournent tous autour de la flexibilité, c est à dire la capacité de l architecture de s adapter à des variations de la demande. Il y a aussi bien sûr de vrais inconvénients. Facilité d évolution

68 Une structuration en tiers permet de séparer les problématiques au niveau de l analyse, de la programmation et des compétences. Une évolution de la présentation à la demande des ergonomes par exemple n impacte pas les règles métier. De même, une évolution de la législation qui nécessite un ajustement des règles métier n impacte pas la présentation. Les technologies, les outils et les compétences associées à la présentation (HTML et Dreamweaver de Macromedia par exemple) ne sont pas les mêmes que celles adaptées à la programmation du métier et des transactions (EJB et Jbuilder de Borland par exemple). Il est donc plus facile d avoir des équipes spécialisées travaillant chacune sur un tier, avec une interface entre tiers bien formalisé. Cette séparation des rôles autorise une spécialisation de plus en plus poussée des réalisateurs et ainsi un gain en efficacité. Extensibilité (scalabilité) L extensibilité est la capacité à croître pour suivre la demande. Il y a deux dimensions à cette croissance de la demande, soit une augmentation du nombre des utilisateurs, soit un alourdissement de l application (par complexification ou apparition de nouveaux types de traitements - exemple : requêtes lourdes et/ou complexes) ; les deux induisent une croissance de la taille des données à manipuler. Le Client / Serveur suit assez facilement la croissance du nombre des utilisateurs, puisque l application utilise les ressources du poste du client ; ceci peut avoir un coût élevé s il devient nécessaire de fournir un client puissant à un utilisateur occasionnel. Il faut aussi bien sûr faire croître le serveur de données. Le n-tier nécessite l accroissement de puissance des tiers présentation, métier et données. L avantage est une mise en commun de cette puissance qui nécessite l achat de moins de «MIPS» sur les tiers serveurs que sur le tier client. Mais comme les MIPS serveurs continuent à être plus chers que les MIPS client, un équilibre relatif sur ce critère existe. Par contre, le n-tier suit beaucoup plus facilement un accroissement de complexité de l application puisqu il suffit comme précédemment d ajouter des ressources sur les tiers serveurs alors que le client / serveur doit envisager le remplacement de tous les postes client. Dans un contexte décisionnel OLAP* (gros volumes de données et peu d utilisateurs), la scalabilité repose surtout sur l architecture des serveurs de données (SMP* et sa variante NUMA*, cluster et sa variante MPP*). Disponibilité Une analyse sommaire pourrait laisser croire que le n-tier avec ses multiples serveurs est moins disponible que le client / serveur. Dans la réalité, les serveurs sont administrés par des professionnels capables de garantir selon les besoins une disponibilité entre 99% et 99.99%. La disponibilité du poste client lourd est par contre liée aux aléas du comportement de son propriétaire. Une erreur de l utilisateur peut facilement rendre son poste inopérant. Or il contient tout ou partie de son contexte de travail. Avec le client léger et sans état du modèle n-tier, la substitution du poste client est instantanée

69 Sécurité D un certain point de vue, le n-tier offre plus de garantie en terme de sécurité puisque l environnement applicatif est un serveur sécurisé, ou en tout cas sécurisable, au lieu d être un PC, cible de tous les virus et vers de la planète. Néanmoins, une faille de sécurité sur le serveur d application introduit des risques plus élevés qu une faille sur le client pour l ensemble du système APPLICATIONS ET INFRASTRUCTURE Une application informatique vit à l intérieur d un système informatique, en général associé à une organisation. Dans le mode connecté dans lequel nous vivons, la plupart des systèmes informatiques sont connectés avec d autres systèmes, à travers des réseaux. Néanmoins le système informatique d une organisation est un objet identifiable, avec une frontière. Il ne se confond pas avec le système d information de l organisation, dont il n est qu un des rouages. De manière simplificatrice, le système informatique est souvent assimilé à «notre Intranet», le monde extérieur étant appelé «l Internet». Les deux sont séparés par «un pare-feu». Il faut par conséquent commencer à décrire l architecture globale d un système informatique. Ce dernier est composé d une infrastructure qui supporte des applications. Chacun a une appréciation intuitive de la signification de ces 2 termes. Le propos cidessous est de préciser leurs limites respectives. Deux frontières se présentent : celle qui sépare infrastructure et applications, et celle qui sépare une application d une autre. Application Application Application Infrastructure Frontière entre infrastructure et applications L infrastructure «supporte» les applications, qui sont la partie visible du système pour les utilisateurs. L infrastructure leur permet de communiquer entre elles et avec le monde extérieur, les utilisateurs, et leur fournit les ressources matérielles et logicielles dont elles ont besoin. La frontière applications / infrastructure se déplace dans le temps et selon les organisations. Le fait même qu il existe UNE infrastructure informatique n est pas universellement reconnu. Certains pensent que chaque application contient son infrastructure et que les objets partagés se limitent aux réseaux de divers types qui les relient (réseau IP, énergie électrique). D autres part, certains produits, dont l AS/400 (IBM eseries

70 maintenant) est le représentant emblématique, sont présentés comme des solutions complètes. L approche pilotée exclusivement par les applications est généralement considérée comme coûteuse à moyen terme, si l on en croit les La notion de bonne «bonnes pratiques» (voir encadré). Il est recommandé pratique : à un instant par nombre d analystes d identifier et de gérer donné, un consensus se l infrastructure informatique comme un projet en tant dégage parmi les experts que tel, avec son cycle de vie, relativement indépendant d un secteur selon lequel tel problème est mieux résolu de celui des applications, même si l infrastructure est à avec telle solution. En leur service. informatique, ces bonnes Au fil du temps, et à mesure que les technologies se standardisent et deviennent des «commodités», elles «tombent» dans l infrastructure. L infrastructure contient de manière consensuelle les éléments suivants : Le matériel : o les postes clients (avec leur OS, mais sans leurs applications), o les serveurs, o les sous systèmes de stockage. Le système d exploitation Le réseau TCP-IP et son système de gestion Le système de supervision des systèmes et des applications pratiques se dégagent en général au niveau international, souvent de manière horizontale, mais parfois dans un environnement sectoriel. Plus récemment, de nouveaux éléments sont présentés comme faisant partie de l infrastructure : Le réseau de stockage, SAN* ou NAS*, Les systèmes de base de données (mais pas les données elle-mêmes), Les serveurs applicatifs (mais pas les applications), Les annuaires (LDAP ou X.500), Le système d EAI*. Ces éléments sont inclus dans l infrastructure parce qu ainsi leur unicité est garantie et leur évolution pérennisée, indépendamment des heurs et malheurs des applications individuelles. Une certaine standardisation, classique pour les SGBDs, est gage d économies globales. La tendance lourde est donc d avoir une infrastructure fournissant des services de niveau de plus en plus élevé, ce qui permet aux applications de devenir plus légères et donc moins chères et plus agiles. Il faut noter néanmoins que cette approche est relativement incompatible avec une organisation très décentralisée de l entité Frontière entre application et application

71 Dans un monde où les applications communiquent, comment discerner clairement la frontière entre deux applications? Critère technique (mode de communication) ou critère organisationnel? Les deux sont pertinents : Techniquement, la communication intra applicative est fortement couplée (voir encadré), synchrone, à grain fin et se caractérise par un fort partage de contexte à base de données partagées. Au contraire, la communication entre applications est asynchrone, faiblement couplée, et à gros gain. Du point de vue de l organisation qui la met en œuvre, une application est ce qui rend un service bien défini à un groupe d utilisateurs bien identifié. Selon le point de vue de l observateur, les deux problématiques, technique et organisationnelle, ne vont pas toujours coïncider,. Une adaptation au cas pas cas sera effectuée. Couplage applicatif : on dit que le couplage entre deux éléments est fort si une évolution de l un a de fortes chances d induire une action sur l autre, ne serait ce qu une recompilation : la technologie de mémoire partagée est fortement couplée. Au contraire, avec un couplage faible, les évolutions peuvent se faire de manière désynchronisée : un schéma XML est une structure de couplage faible entre deux entités COMPOSANTS ET REUTILISATION Depuis plus de 20 ans, l industrie informatique vit dans l espoir de voir advenir le composant réutilisable. Un composant est un morceau de logiciel écrit conformément aux pratiques d encapsulation recommandées dans une approche de type objet, de sorte que l interface du composant vers l extérieur soit bien définie, que l utilisateur n ait pas à se préoccuper de l implémentation et que les effets de bord soient minimes ou nuls. Une fois cet objet identifié, il est possible de le réutiliser «tel quel» dans une autre application, comme on réutilise un circuit intégré ou un moteur diesel dans les autres industries. L attrait économique du modèle pour éviter la réinvention récurrente de la roue est évident. Il entraîne un rendement de la programmation qui n a pas été amélioré en informatique autant que dans d autres industries. L aspect séduisant de l approche se heurte a de très nombreuses difficultés pratiques : les expériences récentes des compagnies ayant adopté cette approche montrent qu il est sensiblement plus «cher» (délai et qualité supplémentaires) de programmer un composant réutilisable plutôt que le composant ad-hoc pour «mon application». Ceci est donc contraire à la logique classique d un projet tiré par les coûts et les délais. Il faut plus de temps et d expertise, avec comme espoir un retour sur investissement pour les applications futures. Par ailleurs, un composant doit être maintenu et suivre les évolutions de l'architecture dans laquelle il évolue. On peut imaginer des «entrepôts de composants publics», ou propres à un entreprise. On peut segmenter en composants techniques (gérer un envoi de mél SMTP) et composants métier (calculer le taux de remboursement sur telle prestation médicale). On peut segmenter aussi en grain fin (gérer une file d attente FIFO,

72 calculer un taux de change) et gros grain (prédire la température dans 24 heures, évaluer la solvabilité d un client). Ces pistes ont été explorées au fil du temps avec de nombreux langages (Eiffel, Smalltalk, C++, Java, VisualBasic) et de nombreuses technologies (COM, EJB ). Un composant fonctionne dans le cadre d une architecture. Il n est pas transportable de l une à l autre. Il existe actuellement des composants Java, des composants COM/DCOM et des composants.net. Le bilan en 2002 est nuancé : 1. Ce qui marche bien : Les bibliothèques publiques de composants techniques de présentation (widgets de toutes sortes) 2. Ce qui est dépend du contexte : Les composants métier d une organisation : succès fortement dépendant de la culture et des processus de l organisation, et de l architecture choisie. 3. Ce qui ne marche pas, ou pas encore : Les bibliothèques publiques de composants métier : la prolifération récente de schémas XML montre bien la difficulté de telles approches Un certain niveau de déception l emporte, surtout pour ce qui est d un véritable marché ouvert des composants. L approche composant est un bon cadre structurant pour minimiser les coûts de développement à l intérieur d une organisation, sans négliger les très forts inhibiteurs culturels qui se manifestent dans la population des programmeurs vis à vis de cette approche perçue comme un frein à la créativité. Devant le relatif échec du composant, réapparaissent des approches similaires qui passent du mode produit au mode service. Les composants ne sont plus de morceaux de code réutilisable, mais des services accessibles via le Web («Services Web» : SOAP, UDDI, HTML). Une application devient alors la composition harmonieuse et dynamique de ces services, qui ne sont plus à réinventer «à la maison». Cette approche semble assez utopique. Les services Web sont une technologie clef (voir au ), en particulier pour l intégration applicative, avec une granularité au niveau de «une application» mais leur utilisation à un niveau de granularité intra applicatif sera sans doute vouée à un succès limité. Un macro composant applicatif encapsulé par des services Web présente l énorme avantage d être accessible universellement en mode service par toute application moderne ou modernisée

73 4.7 - FRAMEWORKS L architecture applicative désigne l art et la manière d utiliser au mieux les outils d un modèle de composants pour implémenter les besoins fonctionnels de l application. Le besoin d une architecture applicative au dessus de l architecture technique des modèles de composants est lié à la relative complexité de ces modèles, liée elle-même à leur puissance. Ceci se matérialise par la notion de «Design Patterns». Le concept de «design pattern» existe bien avant Java et C#, mais prend actuellement toute sa valeur. Un certains nombre de patterns s insèrent dans l approche MVC*, comme Modèle Vue - Contrôleur. Le modèle MVC distingue trois fonctions : Le «modèle» implémente la logique métier, La «vue» implémente l interface utilisateur, Le «contrôleur» régit les interactions entre la vue et le modèle. Le modèle MVC isole proprement le métier et la présentation, et les parties statiques et dynamiques de la présentation. Ces patterns peuvent ne pas rester sous forme papier et se matérialiser par l intermédiaire des «frameworks». (On pourrait utiliser en français l expression «cadre de programmation» pour traduire framework, mais ce n est pas une pratique courante). Les frameworks les plus connus sont struts et cocoon, disponibles en logiciel libre. Des produits commerciaux apparaissent, comme Wakesoft. Le framework inverse l approche programmatique, par rapport à une librairie. Le programme est autonome et appelle une librairie. Le framework est très structurant et appelle les méthodes écrites par le programmeur selon les actions de l utilisateur. Un framework est donc plus puissant qu une librairie mais aussi plus coercitif. Composants Composants Framework Serveur Applicatif Il y a un seul framework pour un projet, au service de tous les composants applicatifs. Techniquement, les frameworks aident à répondre aux questions suivantes :

74 Où implémenter ma logique métier? Comment utiliser les différents types de composants? Comment gérer la persistance? Les avantages du framework sont un gain de temps et donc d argent, et une diminution du risque. Le prix à payer est l investissement amont pour sélectionner l outil et former les programmeurs. Cela induit une relative dépendance vis à vis du framework choisi Les composants techniques des frameworks Ils répondent aux fonctions suivantes : Présentation : o Présentation sur le serveur, o Navigation, o Echanges XML. Logique métier : o Objets métier, o Cache des objets, o Logging. Données : o Persistence, o Mapping objet-relationnel. Dans le paysage actuel de l informatique, les notions de «design pattern» et de framework ne sont populaires que parmi les programmeurs Java et le monde du libre. Le monde Microsoft semble peu enclin à utiliser ces concepts. Ceci peut s expliquer culturellement par le fait que Visual.NET, pour prendre la dernière mouture de l atelier logiciel de Microsoft, propose en lui-même un cadre de programmation assez directif, d ailleurs conforme au modèle MVC et constitue donc en quelque sorte un framework. Le programmeur moyen est bien guidé, le programmeur expérimenté peut se plaindre d être bridé. Quoi qu il en soit, les design patterns les plus utilisées sont les «design patterns for Java», les frameworks décrits ci-dessous étant tous écrits en Java Struts Struts est un framework qui structure les composants V et C du modèle MVC2. Il ne s intéresse donc pas à la logique métier. Il s'agit d'un projet du groupe Jakarta d'apache* ayant débuté en mai Jakarta est le groupe de la fondation Apache en charge de développer, maintenir et fournir des solutions autour de la plate-forme Java Cocoon

75 Il adopte aussi le modèle MVC mais est structuré autour de XML et XSL. Le contrôleur est un transformateur XSL*, étendu par le concept de XSP (XML Server Pages). En conclusion, la notion de framework est encore peu connue et utilisée seulement par les programmeurs les plus avancés, ce qui est en quelque sorte paradoxal puisqu ils seraient les mieux à même de s en passer. Elle semble néanmoins pleine d avenir pour améliorer la productivité

76 5 - APPROCHES COMPLEMENTAIRES Ce chapitre regroupe un certain nombre de considérations qui semblent éclairer les architectures applicatives sans pour autant s inscrire dans les modèles architecturaux du chapitre précédent. C est pourquoi cette liste est relativement arbitraire. Elle cherche à couvrir un ensemble de problématiques d actualité pertinentes sans tomber dans une trop grande diversité : o Quelques considérations liées aux bases de données, o Les particularités du décisionnel, o Les Services Web, o L intégration des applications LES BASES DE DONNEES Dans le cadre de cette étude, la dichotomie architecturale la plus significative pour les SGBDs est de distinguer les applications transactionnelles avec des taux d écriture significatifs, et les autres applications Bases transactionnelles en lecture/écriture Ce secteur représente le gros du marché. Il est absolument dominé pour toutes les applications récentes ou nouvelles par les bases de données relationnelles et centralisées. Relationnel : il faut bien constater que les bases de données objet n ont pas percé et ont été reléguées dans des marchés de niche, malgré le succès du modèle objet au niveau applicatif. Cet échec n est pas forcément seulement technique, il s explique aussi par la domination du marché des SGBD par des acteurs dominants (Oracle, IBM, Microsoft, ). Centralisé : les SGBD distribués ont également échoué en tant que technologie d utilité générale, en particulier pour les applications transactionnelles. C est une technique difficile à mettre en œuvre dans la réalité, avec des coûts d administration élevés. Grosse base sur petits serveurs : mythe ou réalité? Il faut envisager avec prudence les déclarations régulières de différents acteurs annonçant que la base de données distribuée va enfin marcher. Ces déclarations sont motivées presque exclusivement par des considérations économiques : qui profite des marges financières liées à ces achats? Actuellement, l essentiel va chez le trio des vendeurs de gros SMP UNIX (et chez les vendeurs de bases de données). Il serait plus avantageux pour certains acteurs que le matériel associé puisse être des serveurs Intel à coût réduit. D où la vogue médiatique de bases distribuées sur des clusters Linux ou Windows. Le modèle de la base de données unique centralisée est simple et efficace. L existence de grosses machines SMP* UNIX permet à ce modèle de suivre la demande de croissance même pour les plus grosses applications comme amazon.com ou les gros sites SAP

77 Il est important de noter que les données corrélées sont stockées autant que faire se peut dans une base unique. Bien sûr, très souvent, l historique ou l organisation de l entité empêche cette centralisation. Parfois aussi des considérations de performance ou de disponibilité conduisent à distribuer les données dans plusieurs bases distinctes Décisionnel Pour les applications décisionnelles, le modèle distribué marche mieux, dans la mesure où les accès sont principalement en lecture ; de plus, il est souvent possible de partitionner les données suivant un critère simple, géographique ou temporel, et donc de minimiser les interactions entre les nœuds. Le volume des données est souvent beaucoup plus conséquent en raison des historisations et redondances nécessaires et la typologie des traitements (extraction/reporting à la volée, Hypercubes, Datamining,...) fait appel à des systèmes de stockages de données très différents (MOLAP, ROLAP, HOLAP, VOLAP, Hybride, propriétaires). De plus il existe des SGBDs spécialisés pour le décisionnel et le mode grappe, comme NCR Teradata. Néanmoins, avec un SGBDR «classique», le modèle SMP reste le plus simple en décisionnel, mais peut être pas le moins cher Bases en lecture principalement Il existe une catégorie d applications à la limite du transactionnel et du décisionnel (par exemple une base de données servant surtout comme moteur de recherche) où le SGBD sert principalement en lecture, avec des écritures peu fréquentes. Souvent ces SGBDs sont faciles à partitionner DECISIONNEL OLAP Ce décrit la problématique particulière du décisionnel et aborde les points suivants : Historique et émergence, Définition et positionnement, Présentation des différentes fonctions de l informatique décisionnelle, La typologie des données, Les profils utilisateurs, La gestion des flux, Le référentiel des méta-données, Les outils Définition L informatique décisionnelle regroupe l ensemble des structures informatiques permettant à l entreprise de connaître, d analyser et d optimiser ses différentes activités pour répondre au mieux à ses différentes missions ou objectifs

78 Elle fournit l ensemble des éléments d aide à la décision nécessaires pour faire évoluer les différentes activités de l entreprise (connaissance de l entreprise, des clients, des fournisseurs, de la concurrence, des partenaires, etc.), lui permettant ainsi d être réactive dans un contexte de forte concurrence et d exigence en matière de qualité de service et de productivité. Aujourd'hui, l'informatique décisionnelle ne se conçoit plus comme une démarche unitaire mais plutôt comme un processus global d entreprise. La démarche de Data Warehousing répond à ce processus. Bâti autour du concept de Data Warehouse, le processus de Data Warehousing se décline en dispositifs permettant d exploiter l information à disposition de l entreprise (informations que peuvent délivrer les systèmes de production, informations externes à l entreprise, etc.). Data Warehouse Les données d un Data Warehouse obéissent à des critères spécifiques: elles sont intégrées, orientées sujet, historisées et non volatiles Historique et Emergence Actuellement, l offre en matière de Data Warehousing est très dense, éclectique, et très fortement orientée Marketing (On propose souvent des emballages de concepts et de modèles). Tous les constructeurs/éditeurs/intégrateurs proposent une offre Data Warehouse. Il n existe pas vraiment de normes, de méthodes, d architectures matérielles et logicielles qui soient spécifiquement orientées Data Warehouse. Certes, il existe bien un OLAP Council CWM (Common Warehouse Metadata), et quelques gourous du décisionnel dont William Inn qui ont formalisé quelque peu le Data Warehouse, en énonçant des principes comme : l orientation métier, l intégration et la cohérence des données de production, la non-volatilité et l historisation des données Positionnement Pour représenter un SI en intégrant l informatique traditionnelle (informatique qui assiste l entreprise dans ses tâches quotidiennes) et l informatique décisionnelle, il est commode d utiliser modèle suivant :

79 Positionnement des Systèmes d Informations Collectif Alimente Opérationnel Systèmes d'information de Production Systèmes d'information Décisionnels Aide à la Décision Données Externes Individuel Il est à noter que les SID sont alimentés par les données de production et éventuellement par des données externes (données concernant la concurrence, données de prospection,...) Typologies des Données La démarche d architecture globale du Système d Information Décisionnel met en évidence différentes typologies de données qui sont illustrées par le schéma suivant. Sources de Données IP Collectif Opérationnel Batch Processing Contrôle Opérationnel infocentre à Valeur Ajoutée DW Data Warehouse Datamart ID SIAD/EIS Aide à la Décision Individuel

80 Les pointillés IP regroupent l ensemble des Infocentres de Production : Batch Processing, Les applications de Contrôles Opérationnels, Les Applications Infocentres à Valeur Ajoutée. On considère que ces schémas de données sont tous assez proches de schémas de production. Les pointillés DW (Data Warehouse) regroupent : Les Applications Entrepôts de Données (Data Warehouse), Les Applications Magasins de Données (DataMart). On retiendra dans le cadre d un Système d Information Décisionnel les typologies de données suivantes : 1. Les Applications Entrepôts de Données (Data Warehouse), 2. Les Applications Magasins de Données (DataMart), 3. Les Applications Décisionnelles et de Pilotage (SIAD/EIS) Adéquation aux Profils Utilisateurs Les profils utilisateurs viennent compléter la vision générique des sources de données et par là même conforter la définition des besoins génériques. Car n oublions pas que des besoins identifiés comme requête ad hoc, de pilotage ou de Datamining, aboutissent à des choix d architecture et d outils structurants. Ainsi, le schéma ci-après représente une approche intuitive qui permet de cerner les différents profils utilisateurs : Adéquation aux Profils Utilisateurs Collectif Périodique Expert Décideur Occasionnel Opérationnel Analyste Aide à la Décision Individuel Flux

81 Véritable partie immergée de l iceberg SID, la gestion des flux est étroitement liée au dispositif d alimentation des données cibles, mais aussi à l administration et à l exploitation du SID d où l importance des outils ETL* (Extraction Transport Loading). La problématique des flux par les données peut être abordée, mais ceci n est pas suffisant. En effet, avec un peu de recul, on s aperçoit que l ensemble des flux concerne beaucoup plus d éléments que le dispositif d alimentation des données décisionnelles déjà complexe. Ainsi, les flux portent également sur : Les connexions (aspect sécurité), La régulation et l ordonnancement des requêtes (asynchrones et synchrones), La régulation et l ordonnancement des tâches (asynchrones et synchrones), L analyse et le suivi de l activité du SID, Le routage des serveurs (load balancing), La synchronisation des dictionnaires dédiés aux outils utilisés : le plus difficile en attendant que les normes CWM (Métadonnées en XML) soient adoptées par tous les éditeurs. Le déploiement de l informatique décisionnelle nécessite donc une complète maîtrise des flux. Ces flux sont générés par la transition des données de production en données décisionnelles et par les traitements issus des utilisateurs de l informatique décisionnelle. Ainsi, pour couvrir l ensemble de la problématique des flux, il est nécessaire de procéder à une triple approche : Approche par les données, Approche par les traitements, Approche fonctionnelle (administration et exploitation)

82 Système d'information de Production Les Flux PUSH Relatifs aux Données PULL Système d'information Décisionnel Application Application P1 Application P1 Application P1 Application P1 Application P1 Pn ALIMENTATION Identification Extraction Transformation Transport Intégration Data Warehouse Application Application P1 Application P1 Application P1 Application P1 Datamart P1 SIAD EIS SYNCHRONISATION Data Mining Le Référentiel Il est nécessaire de mettre en place un référentiel des méta-données. Les traitements d alimentation s appuient sur ce référentiel, soit au niveau de l exécution (interprétation des règles), soit au niveau de la génération du leur code. Les actions de maintenance se résument alors à de simples actes d administration Critères de Positionnement des Produits Le positionnement des produits liés à une activité d informatique décisionnelle s envisage selon plusieurs pôles d intérêts. Ainsi, une représentation sous forme d axes d analyse permet d appréhender au mieux le ciblage de ces différents produits. Les axes d analyse retenus ici sont : La couverture fonctionnelle par rapport aux besoins, L adéquation aux modèles de données, L adéquation aux profils utilisateurs, Le volume des données traitées LES SERVICES WEB Les services Web sont une technologie permettant à des applications de dialoguer à distance via internet et ceci indépendamment des plates-formes sur lesquelles elles reposent. Un service Web doit tout d abord être décrit à l aide du langage de description WSDL (the Web Service Description Language), ensuite, il doit être enregistré dans le registre UDDI (the Universal Description, and Discovery Integration). Finalement,

83 il pourra être découvert et invoqué par le biais d un protocole de transport, idéalement SOAP (Simple Object Access Protocol). En d autres termes, les services Web permettent à des applications externes de localiser, d exécuter d autres applications résidants sur un réseau local ou public et, par la même occasion, retourner l information via de simples messages basés sur XML. Dans leur acception la plus stricte, les Services Web désignent une pile protocolaire permettant la communication entre applications (voir encadré). Dans leur acception large, elle sert de tremplin aux adeptes des architectures orientées service, supposées révolutionner l informatique de demain. Attardons nous sur la pile protocolaire. Ce n est pas la première tentative de standardisation de la communication applicative à un niveau d abstraction assez élevé. La fabuleuse aventure de TCP-IP a toujours voulu être rééditée. Mais toutes les Services Web, un nom bien mal choisi? Il semble effectivement a priori pouvoir désigner n importe quel service accessible via Internet, y compris un service de traduction ou de livraison de pizzas. Il s agit pourtant exclusivement de services pour les applications informatiques. tentatives précédentes ont échoué, qu elles aient été mené de manière «impérialiste» à partir de positions de domination sur le marché (IBM SAA*, Microsoft DNA*) ou qu elles aient émané de processus plus «démocratiques» comme DCE* de l OSF* ou CORBA* de l OMG*. Le point commun à tous ces échecs était l absence de consensus. Les opposants ont toujours réussi à torpiller la tentative d unification. Ce qui caractérise les services Web n est donc pas leur aspect d innovation technologique (ils peuvent être décrits comme un super RPC*) mais le fait que tous les acteurs significatifs du marché sont derrière avec plus ou moins d énergie. Citons en tout premier lieu IBM et Microsoft. La stratégie de ces acteurs est bien sûr liée à leur intérêt bien compris, qui se trouve dans ce cas particulier coïncider avec l intérêt général, c est du moins l avis de nombre d experts. Contrairement à DCE ou CORBA, les Services Web ne sont que des interfaces (APIs*) et des protocoles. Ils ne cherchent nullement à définir un modèle applicatif. En tant que tel, ils se plaquent donc relativement facilement sur toute architecture existante. Ils sont considérés comme une «colle universelle» acceptée par tous pour relier les applications, comme IP a été accepté pour relier les ordinateurs

84 Description technique Techniquement, la pile des Services Web se présente comme ci-dessous : Décou verte UDDI Application basée Services Web Transaction WS-Tran, BTP... Coordination WS-Coord, WSCI Contrat tpaml... Workflow BPEL4WS (WSFL+ XLANG), BPML... Description: WSDL Enveloppe SOAP, XP, ebxml TR&P Transport HTTP, SMTP, JMS Elle peut paraître complexe. Il convient de retenir que seulement les standards soulignés, SOAP, WSDL et parfois UDDI sont indispensables. Les autres standards des couches supérieures sont dans un état de flux, et non encore stabilisés Application à court terme Les Services Web ne sont qu une technologie de plus. A quoi vont-ils servir? Il existe un consensus assez large selon lequel l application phare dans les 2 ans à venir est l intégration applicative à l intérieur de l entreprise (décrit plus en détail en ). Sur ce point, une demande forte de technologie standard et abordable existe. Par contre les niveaux de sécurité et de robustesse actuels rendent pour le moment difficile leur adoption Une architecture orienté services? Les visionnaires des Services Web prédisent un avenir où les applications seront composées à partir de services disponibles sur Internet. Les critiques insistent en particulier sur le fait que l aspect découverte dynamique lié à UDDI est incompatible avec la nécessité de stabilité et de confiance liée à toute relation entre entités. Sans même envisager cet aspect, il reste fort à faire en matière de standards, de sécurité et de facilité de déploiement avant de voir un tel modèle se déployer Un coup d œil sur l actualité des Services Web

85 Xmethods maintient un répertoire des Web Services: services sont répertoriés en mi-octobre La moitié est accessible en mode RPC*, l autre moitié en mode document XML. Les technologies sous-jacentes : 50% en.net 25% en Apache SOAP, SOAPlite, SOAPx4, Axis 10% en Delphi, 5 % en J2EE (IBM, BEA, Oracle) 10% en «autres technologies» L INTEROPERABILITE APPLICATIVE L orchestration des dialogues entre applications est elle-même une application, même si elle est rarement considérée comme telle de nos jours sur le terrain et est un point structurant dans la problématique associée aux architectures applicatives. Comment communiquer entre applications? La question se pose de manière assez fondamentalement différente selon qu on se place à l intérieur d une entité organisationnelle ou entre plusieurs entités. Par entité, on entend une organisation à l intérieur de la quelle une autorité légitime peut imposer un modèle de communication applicative. De ce point de vue, certains grands ministères sont constitués de plusieurs entités Interopérabilité à l intérieur d une entité Pourquoi un «système de communication» est-il nécessaire? Ne peut-on se contenter de standardiser des langages de description de données et des protocoles de communication? Non, essentiellement parce que l on reconstitue alors systématiquement un modèle de type spaghetti, avec des communications point à point. Il est connu que le coût de possession de ce système augmente comme le carré du nombre d applications. Il est admis depuis une dizaine d années qu il faut se ramener à un problème dont le coût est proportionnel au nombre d applications en jeu. C est le modèle dit moyeu-et-rayons (hub & spoke), où un médiateur central route tous les échanges. Les technologies modernes, que ce soit XML ou SOAP, ne garantissent en rien contre la prolifération des spaghettis. Rien de plus simple que de faire un plat de spaghettis avec des schémas XML et des transformations XSLT par exemple. Le moyeu central est un «serveur d intégration» équipé d une part d adaptateurs pour interfacer les applications et d autre part d un moteur pour router les flux. Le cas échéant, ce moyeu peut être animé par un moteur de workflow d entreprise ou Business Process Manager (BPM*). La standardisation de ce moyeu est relativement prématurée. Elle passe par l émergence d un standard pour les langages de workflow. La récente initiative d IBM et Microsoft autour de BPEL4WS est intéressante à cet égard

86 Seule est donc réaliste dans le court terme la standardisation de la liaison moyeu rayons. Le candidat le plus raisonnable est les Services Web (SOAP + WSDL). Dans ce modèle, chaque application exporte une interface «Services Web» et le BPM orchestre ces services : Application J2EE Application ERP BPM basé Services Web Application CRM Application.NET L e un déploiement pratique de ce modèle exige que les propriétés suivantes soient disponibles : Asynchronisme : en effet, l EAI a montré qu un modèle asynchrone est préférable, avec une sémantique bien définie (queues de messages et «publish and subscribe») Fiabilité des échanges : une sémantique garantie de type une-fois-et-une-seule est nécessaire pour toute application Standard : il ne doit pas y avoir de dépendance avec un produit particulier à déployer au bout de chaque rayon. Malheureusement, en cette fin 2002, aucune technologie ne satisfait complètement ces 3 critères : SOAP sur HTTP est un standard, mais ni asynchrone au sens ci-dessus, ni vraiment fiable du fait de HTTP ; SOAP sur JMS est asynchrone et fiable mais non standard. En effet JMS est une API vers les MOMs*, mais il n y pas de protocole sous jacent standardisé. Il faut donc pour le moment utiliser des produits non standards en attendant que l industrie se mette d accord sur la technologie d avenir. On parle souvent alors d IAI, comme Integration d Applications Internet. Une approche réaliste possible à court terme, qui permet de se placer en position de profiter de la baisse des coûts logiciels liée à l émergence des Services Web : choix d un MOM avec interface JMS ou MSMQ* ;

87 utilisation par les applications d un interface SOAP avec «binding» JMS ou MSMQ (en fait BizTalk) ; pour le BPM, choix d un produit qui semble en ligne avec les impulsions données par les leaders du marché Interopérabilité entre des entités Le domaine évoqué dans cette partie concerne celui du B2B dans le cadre de l industrie, ou de l interministériel dans le cadre de l administration. Tous les problèmes soulevés en intra-entité sont pertinents, et de nouveaux apparaissent : o La définition des schémas XML partagés devient plus complexe ; des négociations longues sont à prévoir. o La topologie d interconnexion est complexe. Autant il est possible d espérer imposer dans une entité une topologie moyeu et rayons avec un moyeu unique, autant ceci semble irréaliste pour l ensemble de l administration. Ceci tient à la multitude et à l hétérogénéité des acteurs communicants. Faut-il pour autant se résigner à une architecture spaghetti où tous les acteurs interagissent en point à point avec tous leurs partenaires? Un bon compromis pourrait être une topologie multi-hubs (moyeux) avec un nombre limité de «places d échange» servant de médiateurs de communication. o Les protocoles nécessitent plus de fiabilité : le consortium ebxml, dont on pouvait espérer voir sortir une solution dans l espace B2B, ne semble pour le moment pas avoir assez de support des grands acteurs. Les initiatives ws-* issues du duo IBM - Microsoft sont une autre piste à suivre. o La sécurité devient clef dans la mesure où la confiance mutuelle est plus faible qu en intra-entité. Les outils actuels (SOAP sur https et des certificats X.509) offrent des possibilités. A terme, WS-Security, piloté par l organisme OASIS, semble être un cadre intéressant à évaluer

88 6 - ANNEXES GLOSSAIRE.NET ACID Apache API applet ASP bean BMP, CMP BPM BPEL4WS CCI CORBA CRM Cube CVS CWM DataMart Data Warehouse DCE DCOM FAI GRC ICA l architecture de composants de Microsoft (prononcé dotnet en anglais). Atomicité Consistance Isolation Durabilité : les 4 propriétés canoniques d une transaction. Le serveur http en logiciel libre le plus populaire sur le marché. Par extension, un ensemble de logiciel libres gravitant autour de ce serveur Web et la communauté de programmeurs qui s y rattache. Voir Application Programming Interface : interface programmatique Composant de code en Java pouvant s exécuter dans le cadre d un navigateur Advanced Server Pages : le modèle de composants de présentation Web de Microsoft Composant logiciel écrit en Java Bean Managed Persistence, Container - - : 2 modes de gestion de la persistance des données dans le modèle J2EE Business Process manager : gestionnaire informatisé de processus d entreprise Business Process Langage for Web Services : proposition IBM Microsoft de langage de workflow pour les Services Web Cadre Commun d Interopérabilité de l ATICA Common Object Request Broker Architecture : architecture d composants de l OMG Customer Relationship Management : voir GRC. Matérialisation d une base de données dédiée au décisionnel, stockant les données sous la forme d un tableau multidimensionnel Gestionnaire de source en logiciel libre Common Warehouse Metamodel :méta modèle décisionnel de l OMG "Magasin de données". Base de données orientée sur un sujet fonctionnel (métier) constituée à partir de la base de données du Data Warehouse. "Entrepôt de données". Le Data Warehouse est une base de données dédiée pour l'informatique décisionnelle dont les données sont intégrées, orientées sujet, non volatiles et historisées. Distributed Concurrent Environment : modèle distribué développé par l OSF (maintenant OpenGroup) dans les années 90 Distributed Component Object Model: protocole de communication applicatif de Microsoft DNA Fournisseur d Accès Internet Gestion de la Relation Client : partie du système informatique qui permet au personnel de l entité de gérer les interactions avec les clients,, ou aux clients eux-même d interagir en self-service avec le système. Independent Computing Architecture : protocole de présentation du client ultra léger de Citrix

89 IETF IIOP J2EE JCA JMS JSP JTA JTS LAMP LDAP LSB Internet Engineering Task Force : organisme de standardisation de l Internet (les célèbres RFCs) Internet Inter ORB Protocol : protocole de communication entre ORBs et entre serveurs J2EE hétérogènes Java 2 Enterprise Edition : le modèle de composants d entreprise (comprendre transactionnel) avec Java Java Connector Architecture : cadre standard de connexion entre un serveur J2EE et des applications patrimoniales de type mainframe ou PGIs Java Messaging System : API Java et modèle sémantique de MOM Java Server Pages : composant de présentation de pages dynamiques du modèle J2EE Java Transaction API : API permettant de programmer des transactions ACID au modèle XA Java Transaction Server : protocole de transaction distribué implémentant le modèle XA Linux Apache MySQL Perl : un ensemble de logiciels libres complémentaires pour un site Web Light Directory Access Protocol : le standard d accès aux répertoires de noms Linux Standard Base : tentative de standardisation des APIs Linux MOM Message Oriented Middleware :interstitiel de communication par message (Ex. : MQseries MPP Massively Parallel Processor : modèle de machine en grappe avec un réseau de communication très rapide et propriétaire MSMQ Produit et protocole MOM de Microsoft multidimensionnel multithread NAS NUMA OLAP OMG ORB OSF OSI Perl PGI PHP Technique d'organisation des données qui consiste à caractériser les données numériques (indicateurs) par des attributs qualitatifs homogènes (dimensions) pour exprimer les indicateurs dans un système de coordonnées construits à partir des dimensions. Modèle de multiprogrammation à l intérieur de l espace d un processus d OS Network Attached Storage: système de partage de données à travers un réseau et via des protocoles d accès fichiers comme NFS ou CIFS Non Uniform Memory Access : modèle de multiprocesseur où les temps d accès mémoire sont différentiés selon la distance CPU - Mémoire On Line Analytical Processing. Caractéristiques techniques d'un système construit autour de données multidimensionnelles. Variantes MOLAP, ROLAP, Object Management Group : promoteur de l architecture CORBA et du CWM Object Request Broker : middleware de gestion d un modèle de composant objet, souvent CORBA Open Software Foundation : coalition des vendeurs UNIX au siècle dernier Open System Interconnection: modèle de communication entre ordinateurs développé par l ISO dans les années 80 Langage de programmation d applications interprété Progiciel de Gestion Intégré Langage de programmation d applications de présentation Web

90 Python Portlet RDF RDP RMI RPC Langage de programmation d applications de présentation Web Composant élémentaire de la page d un portail Resource Description Framework : modèle et langage de description de la sémantique du Web Remote Data Protocol : le protocole de client ultra léger de Microsoft Remote Message Invocation: l API de RPC du modèle J2EE Remote Procedure Call : tout protocole d appel de procédure via un réseau SAA System Application Architecture : le modèle d architecture d IBM dans les années 80 SAN Services Web servlet SMP SOAP tpmc MVC W3C Storage Area Network : réseau (en général FibreChannel) reliant serveurs et soussystèmes de stockage Ensemble de protocoles et d APIs de communication entre applications Composant de présentation sur le serveur dans le modèle J2EE Symmetrical Multi Processor : des processeurs qui se partagent une mémoire commune et cohérente de manière symétrique Simple Object Access Protocol: protocole d accès distant de la pile Services Web Transactions par minute C : la métrique du benchmark de référence du TPC (Transaction Processing Council) en OLTP : TPC-C Modèle Vue Contrôleur : une façon structurée de programmer un frontal Web. World Wide Web Consortium : organisme établissant des recommandations pour le Web WebDAV Standard de publication de site Web ; IETF RFC 2518 WML XA XML XP XSL XSP Wireless Markup Language : un HTML pour les téléphones mobiles extended Architecture : modèle de transactions ACID distribuées défini par X/Open extensible Markup Language : langage de description de données fort populaire extreme Programming : une méthodologie minimaliste de développement de logiciel XML Style Sheets : standard de définition de la présentation XML XML Server Pages : une extension propriétaire au framework Cocoon