etude analytique des architectures...
TRANSCRIPT
PROJET
Etude analytique des architectures applicatives
1 - INTRODUCTION.......................................................................................................... 2 1.1 - Objectif................................................................................................................... 2 1.2 - Périmètre de l’étude ............................................................................................... 2 1.3 - Plan de l’étude........................................................................................................ 2 1.4 - Guide de lecture ..................................................................................................... 3
2 - TYPOLOGIE APPLICATIVE ET CRITERES ......................................................... 4 2.1 - Typologie ............................................................................................................... 4 2.2 - Critères d’évaluation .............................................................................................. 5
3 - ARCHITECTURES APPLICATIVES ...................................................................... 12 3.1 - La technologie J2EE ............................................................................................ 12 3.2 - La technologie .NET ............................................................................................ 16 3.3 - Catégorie Web Interactif ...................................................................................... 17 3.4 - Catégorie Publication ........................................................................................... 32 3.5 - Catégorie Décisionnel .......................................................................................... 41 3.6 - Catégorie Collaboratif.......................................................................................... 46 3.7 - Catégorie PGIs ..................................................................................................... 48 3.8 - Catégorie Intégration applicative ......................................................................... 52
4 - APPROCHE ARCHITECTURALE .......................................................................... 55 4.1 - Modèles décrivant une architecture applicative................................................... 55 4.2 - Protocoles et APIs ................................................................................................ 61 4.3 - Historique des architectures applicatives ............................................................. 65 4.4 - Avantages et inconvénients de l’approche n-tier ................................................. 67 4.5 - Applications et infrastructure............................................................................... 69 4.6 - Composants et réutilisation.................................................................................. 71 4.7 - Frameworks.......................................................................................................... 73
5 - APPROCHES COMPLEMENTAIRES .................................................................... 76 5.1 - Les bases de données ........................................................................................... 76 5.2 - Décisionnel OLAP ............................................................................................... 77 5.3 - Les Services Web................................................................................................. 82 5.4 - L’interopérabilité applicative ............................................................................... 85
6 - ANNEXES..................................................................................................................... 88 6.1 - Glossaire............................................................................................................... 88
Document de travail et d’information décembre 2002 ATICA - 1 -
PROJET
1 - INTRODUCTION
1.1 - OBJECTIF
Cette étude des architectures applicatives vise à favoriser la connaissance dans ce domaine ; il est perfectible et les lecteurs sont invités à l’enrichir et l’améliorer en écrivant à l’adresse suivante : [email protected].
1.2 - PERIMETRE DE L’ETUDE
Le périmètre de cette étude est l’ensemble des architectures applicatives informatiques ; elle ne se limite pas à celles actuellement utilisées dans l’administration mais à l’ensemble du marché.
Par contre, les architectures des solutions orientées grand public, par exemple les applications personnelles sur PC (bureautique, monétique …), ne seront pas prises en compte.
En plus des architectures éprouvées, une exploration des modèles émergents sera effectuée (par exemple les architectures s’appuyant sur des Services Web*). Dans le même esprit, les architectures patrimoniales qui fonctionneront encore de nombreuses années (transactionnels non Web, Mainframes ...) n’ont pas été exclues du champ de l’étude.
Par contre les architectures pour le temps réel, la conduite de processus ou le calcul scientifique n’en font pas partie.
1.3 - PLAN DE L’ETUDE
Le chapitre 2 - décrit la typologie de classement fonctionnelle des architectures applicatives étudiées, et les critères qui les caractérisent, aussi bien du point de vue général qu’en terme d’interopérabilité.
Le chapitre 3 - décrit chaque architecture et l’évalue par rapport aux critères définis.
Le chapitre 4 - traite la problématique architecturale d’un point de vue plus analytique. Il comprend un rappel historique et une typologie de différents types d’architecture (n-tier), puis aborde la thématique des composants et des frameworks.
Le chapitre 5 - traite des approches complémentaires, autour des bases de données et du décisionnel, et fournit une présentation des Services Web et de l’intégration applicative.
Le document est complété par un glossaire. Les mots du glossaire sont signalés par une * à leur première apparition.
- 2 -
PROJET
1.4 - GUIDE DE LECTURE
Ce document vise des audiences diverses et peut sembler volumineux. Voici un guide de lecture selon votre profil :
Si vous êtes expert en architecture, vous pouvez lire seulement les chapitres 2 et 3, et les paragraphes 5.3 et 5.4.
Si vous êtes membre d’une maîtrise d’ouvrage ou d’une équipe projet :
• Si une remise à niveau architecturale vous semble nécessaire, lisez d’abord le chapitre 4, et des éléments du chapitre 5 selon vos sujets d’intérêt, avant de lire les chapitres 2 et 3.
• Si vous chercher une aide pour un projet précis, identifiez son type d’après le chapitre 2 et allez directement au paragraphe approprié dans le chapitre 3.
Si vous souhaitez lire l’ensemble du document, commencez par les chapitres 4 et 5, puis continuez par les chapitres 2 et 3. Cet ordre des chapitres, qui peut paraître paradoxal, a été choisi pour éviter de présenter d’emblée aux lecteurs experts des considérations générales qui risquent de leur sembler trop évidentes.
- 3 -
PROJET
2 - TYPOLOGIE APPLICATIVE ET CRITERES
Ce chapitre propose une description de la façon d’organiser les architectures applicatives et une série de critères pour les analyser.
2.1 - TYPOLOGIE
La typologie utilisée est pragmatique, destinée à être pertinente non seulement pour les architectes des systèmes informatiques mais également pour les maîtrises d’ouvrage et les chefs de projet.
Bien sûr, certains projets imposent de mettre en œuvre plusieurs de ces types de façon cohérente (par exemple, un web interactif et une gestion documentaire, éventuellement intégrés dans une architecture de type collaboratif). C’est le travail d’un architecte de projet d’établir cette cohérence.
• Catégorie Web Interactif : il s’agit d’applications où l’utilisateur interagit avec un serveur Web, que ce soit en intranet ou en internet, pour accéder à des données ou des services. L’interaction est personnalisée et ne se limite pas à la recherche d’information classique traitée dans la catégorie publication.
o Web interactif non critique : non critique en matière d’argent, de vies humaines ou de réputation mise en jeu ;
o Web interactif critique : critique d’après les mêmes critères ; se caractérise souvent par la présence de transactions ;
o Mainframes webisé : une application mainframe traditionnelle exportée sur intranet ou internet ;
o Transactionnel 3-tier webisé : une application transactionnelle exportée sur intranet ou internet ;
o Client lourd/serveur webisé : une application client lourd traditionnelle exportée sur intranet ou internet.
Les trois dernières architectures, qualifiées de « wébisées », couvrent les applications patrimoniales (legacy) existantes, hétérogènes et le plus souvent anciennes mais au cœur du dispositif. De plus, il n’est souvent pas souhaitable de les retoucher sauf sous forme de maintenance applicative.
• Catégorie Publication : il s’agit pour l’essentiel de « pousser » de l’information vers l’utilisateur, en le guidant au mieux :
o Web : Intranet & Internet « classique » - les vitrines des organisations ; o Gestion de documents « en grand » : sites de journaux, évènements … ; o Streaming son/vidéo : applications avancées comme par exemple celle de « La Villette ».
• Catégorie Décisionnel : les applications permettant de prendre des décisions en analysant un historique de données et de services.
• Catégorie Collaboratif : les applications permettant une meilleure efficacité du travail en groupe :
- 4 -
PROJET
o Groupware ; o Pair à pair ; o Workflow documentaire.
• Catégorie PGIs* : une analyse de l’architecture actuelle et de la stratégie technique des principaux acteurs du marché mondial est effectuée.
• Catégorie intégration applicative : intégrer les applications peut être considéré comme une sorte de méta application. En particulier le programme du BPM* (Business Process manager) est une application :
o Ad-hoc (spaghetti) : style d’intégration inclus dans les applications, o EAI « classique » : produits d’EAI du marché, o Web Services / XML : EAI émergente à base de technologies Services
Web.
2.2 - CRITERES D’EVALUATION
Chaque architecture est évaluée selon des critères généraux mais aussi par rapport à sa capacité à implémenter facilement les recommandations actuelles ou à venir du Cadre Commun d’Interopérabilité des systèmes d’information publics.
2.2.1 - Critères généraux
Certains critères nécessitant une explication plus longue sont développés dans les paragraphes qui suivent.
• Coûts : une architecture applicative donnée induit des coûts d’achat et des coûts de possession. Elle induit aussi des retours sur investissement et a donc un impact économique. Ce point trop contextuel ne sera pas abordé ici. Les coûts d’achat comprennent les licences de logiciel et les coûts induits en matériel et formation. Les coûts de possession comprennent le support logiciel, l’administration et la maintenance de l’application.
• Flexibilité : ces critères caractérisent la facilité avec laquelle l’architecture applicative peut s’adapter à des changements au niveau des besoins, que ce soit sur le plan fonctionnel ou sur le plan non fonctionnel : o Extensibilité (Scalabilité) en performance (voir 2.2.2 - ), o Evolutivité fonctionnelle, o Capacité à intégrer de nouveaux standards, o Richesse des environnements de développement ;
• Robustesse : ces critères caractérisent la résistance de l’architecture
applicative aux erreurs de toute nature : o Robustesse intrinsèque du logiciel et des outils associés, o Robustesse extrinsèque vis à vis des pannes de l’environnement, des
fautes des utilisateurs ou des administrateurs, o Sécurité : capacité à s’intégrer et à étendre le cadre de sécurité global
du système,
- 5 -
PROJET
o Haute disponibilité : capacité à gérer des réplications pour la tolérance aux pannes ;
• Pérennité : ces critères sont liés au fournisseur et au logiciel : o Présence du fournisseur, éventuellement internationale, o Parts de marché du logiciel (en effet, la pérennité du fournisseur ne
suffit pas, il peut décider d’abandonner un produit); Ces points induisent naturellement la création d’un écosystème avec des tierces parties (formation, TMA, hébergement) et des compétences disponibles sur le marché du travail.
• Implémentation J2EE / .NET / LAMP : capacité à implémenter l’architecture avec une de ces trois technologies
L’ensemble des critères généraux est repris dans le tableau en 2.2.4 - .
2.2.2 - Critère d’extensibilité (scalabilité) en performance
L’infrastructure matérielle se caractérise sommairement par ses capacités en terme de puissance processeur, mémoire et entrées/sorties. La capacité processeur a une interaction importante avec l’architecture. La capacité mémoire a également un impact, car certaines applications ne savent pas exploiter des capacités mémoire supplémentaires, mais cet impact est moindre. Il y a 3 dimensions possibles de scalabilité en terme de puissance CPU :
• Puissance intrinsèque du CPU, c’est à dire sa fréquence, son architecture et ses caches : cet aspect n’a pas d’interaction avec l’architecture applicative ;
• Multiprocesseur symétrique SMP* : ajout de processeurs qui se partagent la mémoire (NUMA* n’est qu’une variante de SMP) ;
• Grappe (ou cluster, ou MPP*) : ajout des nœuds reliés entre eux par un réseau de communication.
Pour pouvoir exploiter correctement une augmentation de performance dans les dimensions SMP ou cluster, il faut bien sûr que les éléments logiciels sous-jacents soient eux-mê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 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.
Google : un exemple de scalabilité cluster exemplaire : le moteur de recherche Google est implémenté par une gigantesque grappe de plus de 10 000 machines Linux. Ceci est efficace car l’algorithme de recherche de Google est écrit pour ce mode de fonctionnement. Un autre moteur de recherche avec un autre algorithme pourrait être tout a fait inefficace sur la même architecture. Pourtant le service rendu au client est le même !
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 -
PROJET
son rendement relativement indépendant de la programmation de l’application ; par contre, le rendement de la dimension cluster est extrêmement dépendant de la nature de l’application. Malheureusement, la croissance dans la dimension SMP est plus chère car les gros multiprocesseurs (8, 16, 32 processeurs) sont plus chers « au ktpmC* » que les petites machines (typiquement mono, bi ou même quadri processeurs).
2.2.3 - Critères relatifs au CCI
Le CCI Version 1 recommande un certain nombre de standards ; certains sont pertinents vis à vis des architectures applicatives.
Certains standards sont à l’état de candidat dans le CCI Version 1. Ils sont listés en italique. Le CCI Version 2 proposera d’autres standards, listés ici de manière spéculative, également en italique.
Sont listés ci-dessous les standards et leur possible impact applicatif ; « néant » ou « Minime » signifie que l’architecture applicative est pas ou peu concernée par le standard. Soit il s’agit d’un standard d’infrastructure, soit l’impact est lié à la programmation de l’application et pas à son architecture.
Standard Définition Impact applicatif
CCI Version 1
IP V4 V6 Protocole de transport et de réseau Capacité à communiquer sur une socket
HTML Langage de présentation des données sur un navigateur
Capacité à produire du HTML
DNS Serveur de noms de domaines Néant
SMTP MIME S/MIME
Protocole et formats d’échange de mél
Capacité à échanger du mél MIME et S/MIME
FTP Protocole d’échange de fichiers Minime
LDAP Format et protocole d’annuaire Capacité à consulter l’annuaire
SSL Protocole de transfert sécurisé au niveau du transport
Capacité à communiquer sur une socket « secure »
PKI, X.509 Certificats à clef publique Capacité à utiliser X.509 pour l’autorisation et l’authentification
Accessibilité Faciliter l’accès aux handicapés Minime, c’est la programmation, pas l’architecture qui est impactée
XML, XSL XMLSchema
Langage de description de données et de meta-données
Capacité à manipuler et produire du XML, conformément à des XMLSchemas
SOAP WSDL
Transport applicatif de XML Langage de description d’interface
Capacité à produire et consommer des services Web
UDDI Annuaire pour les services Web Capacité à découvrir et publier des services Web
Formats et SGML, MPEG, GIF … Minime, c’est la programmation, pas
- 7 -
PROJET
supports l’architecture applicative qui est impactée
CCI Version 2 (Propositions)
Composant Standard Tiers concernés
Version
Etat du std.
Commentaires Typologie et critères
Standards trans-architectures
RPC universel SOAP surtout métier
1.1 A faire La version 1.2 proposée par le W3C n’est pas stabilisée
Langage de description d’interface WSDL surtout
métier 1.1 " " " "
Annuaire de services UDDI surtout métier
2.03 " Un annuaire UDDI n’est pas indispensable
Meta données XML XML Schema
tous 1.0 " Nécessaire à l’encodage WSDL
Sécurité : confidentialité et authentification mutuelle
SSL TLS X.509
tous 3.0 1.0
" Schémas d’encryption de SOAP sur https Authentification service et client
Profil d’utilisation des Services Web
Basic profile
tous 1.0 " Emane de ws-i.org, récent (Octobre 2002)
Standards J2EE
Framework J2EE J2EE tous 1.3 "
Composant de présentation JSP présentation 1.2 "
Composant de présentation Servlet présentation 2.3 "
Composant métier EJB métier 2.0 "
Messagerie JMS métier 1.0.2 "
Accès SGBDR JDBC métier données
2.0 "
Accès mainframes & PGIs J2EE Connector
métier données
1.0 " Abusivement, JCA
Communication entre composants RMI/IIOP métier 1.0 " A éviter en hétérogène ; préférer
les Services Web
RPC entre composants JAX-RPC surtout métier
1.0 " Pour accéder à SOAP en Java
La liste des standards d’interopérabilité étant longue, une synthèse a été réalisée sous la forme des 7 critères suivants :
1. HTML : capacité de génération du HTML
2. XML : capacité à produire et consommer du XML
- 8 -
PROJET
3. Services Web : capacité à produire et consommer des Services Web
4. Composants : capacité à tirer partie de l’approche composants
5. Standards : capacité à intégrer de nouveaux standards
6. J2EE : capacité à interopérer avec le monde J2EE
7. .NET : capacité à interopérer avec le monde .NET
Dans le tableau global ci-après, ils permettront de caractériser les architectures applicatives.
- 9 -
PROJET
2.2.4 - Liste synthétique des critères
Critère Définition
Critères généraux
Coûts d’achat
Coûts de possession
Scalabilité performance
Evolutivité fonctionnelle
Robustesse intrinsèque … du logiciel
Robustesse extrinsèque vis à vis de l’environnement
Sécurité Capacité à s’intégrer et enrichir le cadre de sécurité
Développement Richesse des environnements de développement
Présence du fournisseur
Parts de marché … du logiciel
Implémentation J2EE Capacité à implémenter l’architecture avec cette technologie
Implémentation .NET Capacité à implémenter l’architecture avec cette technologie
Implémentation LAMP Capacité à implémenter l’architecture avec cette technologie
Critères d’interopérabilité
HTML Manipulation du HTML
XML Manipulation du XML
Services Web Capacité à produire et consommer des Services Web
Composants Capacité à tirer partie de l’approche composants
Standards Capacité à intégrer de nouveaux standards
Interop. .NET Capacité d’interaction avec les architectures .NET
Interop. J2EE Capacité d’interaction avec les architectures J2EE
Pour chaque critère et chaque architecture, une cotation sur l’échelle suivante a été attribuée :
++ : très capable + : bon 0 : neutre, ou le critère n’est pas pertinent pour cette architecture - : faible -- : incapable
- 10 -
PROJET
Il ne faut pas attribuer à cette approche plus de valeur qu’elle n’en a, et surtout pas additionner les + et les -. Il est plus instructif de lire la colonne commentaires.
De plus, pour les coûts, il n’a pas été attribué de cotation (qui pourrait être trompeuse), mais seulement un commentaire qualitatif. En effet, seule une analyse projet peut être menée quantitativement.
Certains critères n’ont aucun sens pour certaines architectures, vu que le modèle n’est pas orthogonal, c'est-à-dire par exemple, le critère « interopérabilité .NET » pour l’architecture « Web interactif non critique .NET ». Dans ce cas là, le critère est supprimé du tableau.
- 11 -
PROJET
3 - ARCHITECTURES APPLICATIVES
Chaque architecture est décrite, analysée par rapport aux critères définis en 2.2 - puis illustrée par un cas d’utilisation typique, si possible dans le contexte de l’administration.
Pour chaque architecture, les standards à suivre sont définis, quand cela est pertinent.
En préalable, les deux principaux protagonistes en terme de plates-formes d’implémentation J2EE et .NET sont décrits.
3.1 - LA TECHNOLOGIE J2EE
Java 2 Enterprise Edition est le modèle de composants promu par Sun et ses partenaires pour les applications d’entreprise. Il existe d’autres modèles de composants Java plus simples, pour les applications embarquées par exemple (J2ME) ou J2SE pour le poste client, mais elles n’entrent pas dans le champ de cette étude. J2EE est du point de vue marketing le nom phare autour duquel se structure l’affrontement économique avec Microsoft .NET.
J2EE au sens strict est une spécification, pas une implémentation. Cette spécification est contrôlée par Sun Microsystems. Il ne s’agit donc nullement d’un standard au sens formel. L’évolution de J2EE est régie par une charte, le Java Community Process (JCP*), qui a été négociée entre Sun et ses partenaires.
3.1.1 - Description technique
La spécification J2EE définit la notion de conteneur, qui est un objet logiciel implémentant une fonction macroscopique.
J2EE et ouverture J2EE est généralement considéré comme un cadre plus ouvert que .NET ; néanmoins, il n’est techniquement pas impossible à Sun de reprendre plus de contrôle, puisque le JCP est la loi définie par Sun. L’ouverture de J2EE n’est paradoxalement garantie que par la relative faiblesse de Sun dans le secteur du logiciel. Les vrais poids lourds de J2EE, ceux qui ont des parts de marché et du revenu de produits et de services associé à cette technologie sont pour l’essentiel IBM, Oracle et BEA. Un Sun qui deviendrait dominant sur le marché du logiciel pourrait adopter des pratiques monopolistiques semblables à celles de Microsoft. Cette hypothèse est néanmoins très peu vraisemblable. La certification est un bon exemple de la politique de contrôle de Sun. La certification J2EE est contrôlée par Sun et demande le passage d’une suite de vérification et le paiement de royalties liées aux interfaces. Par le biais de subtilités juridiques dans la licence Java, qui ont alimenté la querelle entre Java et le monde du libre, Sun a jusqu’à ce jour empêché la certification de produits libres J2EE. (Néanmoins, il semble que l’évolution de JCP 2.5 rende possible en 2003 la certification J2EE 1.4 de Jonas et Jboss). Cette certification ne doit donc pas être vue seulement comme un label de qualité technique, ce qu’elle est indubitablement, mais aussi comme un outil politico-industriel.
- 12 -
PROJET
Client lourd Application /
Applet
Architecture logique J2EE
Client léger Navigateur
Métier Conteneur EJB o JCA o JMS …
Présentation Conteneur Webo Servlet o JSP
Données
RMI
RMIJDBC
Deux conteneurs existent de-facto :
• Le conteneur Web s’occupe de la présentation : o les servlet hébergent le code Java, o les JSP (Java Server Pages) hébergent du HTML dynamisé par du
Java. o JDBC permet d’accéder aux données rangées dans un SGBDR
• Le conteneur EJB héberge la partie métier. Sa vertu principale est de permettre une gestion déclarative de notions complexes à programmer :
o Les sessions : le conteneur gère des beans session, avec ou sans état, qui représentent l’interaction courante du client avec le système (par exemple son caddy sur un site de e-commerce).
o Les transactions o La persistance des objets : le conteneur gère des beans entité qui
représentent les objets persistants, soit en laissant l’initiative au bean (Bean Managed Persistence, BMP) soit via un système automatique appelé CMP (Container Managed Persistence)
o Un modèle de sécurité basé sur les rôles o Le cycle de vie des composants (activation, passivation) o Un modèle de communication asynchrone avec les Message Driven
Beans et l’API JMS • Le protocole de communication entre beans est RMI, et plus précisément
RMI/IIOP pour les interactions hétérogènes (Note : en réalité, il n’y a jamais de communication hétérogène, par exemple entre WebLogic et WebSphere, au niveau RMI).
Un point important est que le conteneur EJB n’est pas indispensable. On peut implémenter la partie métier avec le conteneur Web, JDBC pour accéder aux données et des beans Java classiques.
Ce point est un sujet de polémiques interminables dans la communauté Java :
- 13 -
PROJET
Une école de pensée trouve que le modèle EJB est « trop compliqué » pour les choses simples, ou même trop compliqué tout court et préfère se limiter au conteneur Web agrémenté d’un pattern d’accès aux données.
L’autre école de pensée considère que le conteneur EJB fait un meilleur travail que le programmeur moyen, s’améliore dans le temps et est donc un cadre sécurisant et rentable à moyen terme, même si la courbe d’apprentissage est reconnue comme importante. En résumé, ce n’est pas le modèle EJB qui est complexe, c’est le problème des applications transactionnelles d’entreprise.
Logiquement, le conteneur EJB ne peut être utilisé que si le programmeur profite des valeurs qu’il apporte autour des transactions, de la persistance et de l’asynchronisme. Ce point doit être jugé application par application, et non pas dans l’absolu. Il est par contre regrettable de ne pas utiliser le conteneur EJB par manque de formation.
J2EE est une architecture mono langage (Java) et multi plate-formes (Windows, Linux, UNIX, OS/390).
3.1.2 - Le « standard » J2EE 1.3
J2EE n’est pas un standard en soi, mais un ensemble de standards ayant leur cycle de vie propre. A un instant donné, un ensemble cohérent est baptisé « J2EE version x.y » :
La dernière version publiée est J2EE 1.3 (Automne 2001) qui contient l’ensemble d’APIs suivants (par ordre alphabétique) :
• EJB (Enterprise JavaBeans) 2.0 • JAAS (Java Authentication and Authorization Service) 1.0 • JavaMail 1.1 • Java RMI (Remote Method Invocation) 1.0 • JAXP (the Java API for XML Processing) 1.1 • JDBC (Java Database Connectivity) 2.0 • JMS (Java Message Service) 1.0.2 • JNDI (Java Naming and Directory Interface) 1.2 • JSP (JavaServer Pages) 1.2 • JTA (Java Transaction API) 1.0.1 • J2EE Connector Architecture 1.0 • RMI/IIOP (Internet Inter-ORB Protocol) 1.0 • Servlets 2.3
La prochaine version, J2EE 1.4, est depuis Août 2002 à l’état de « final draft ». Les évolutions sont centrées autour des points suivants :
• Support des Services Web : JAX-RPC, JAXR, SAAJ • Support de XML : JAXP • Management : JMX • EJB 2.1 • JCA 1.5
- 14 -
PROJET
La spécification J2EE est implémentée par de nombreux acteurs dans le monde commercial et dans le monde du libre.
3.1.3 - Produits commerciaux certifiés J2EE
Il y a 11 vendeurs certifiés J2EE 1.3 en Novembre 2002 :
1. BEA, WebLogic : le leader du marché 2. Borland, Enterprise Server 3. Fujitsu, Interstage 4. IBM, WebSphere : le challenger, pas loin derrière BEA 5. Macromedia, Jrun server 6. Oracle, 9iAS 7. Pramati, Pramati Server 8. Silverstream eXtend 9. SunOne Application Server 7 10. Sybase, Enterprise Application Server 11. Trifork, Enterprise Application Server
Certains produits sont « en avance » sur J2EE, par exemple implémentent déjà la spécification EJB 2.1.
Une synthèse souvent bien à jour est disponible sur Internet : http://www.flashline.com/components/appservermatrix.jsp
3.1.4 - Produits commerciaux non certifiés J2EE 1.3
Cette liste n’est pas exhaustive:
• Caucho, Resin-EJB • HP, HP-AS • Hitachi, Cosminexus • Iona, J2EE Technology • Ironflare, Orion • Sun, SunOne Application Server
3.1.5 - Produits libres
• Apache + Tomcat 4.1 : cet ensemble ne gère que le conteneur Web, donc les standards suivants : servlet 2.3, JSP 1.2, JDBC 2.0
• Jboss (+Apache + Tomcat) : Jboss est le conteneur EJB le plus répandu dans le monde du libre. Il implémente les standards suivants : EJB 2.0, servlet 2.3, JSP 1.2, JDBC 2.0
• Objectweb Jonas (+Apache + Tomcat) : Jonas est une technologie d’origine Bull, donnée au consortium objectweb. JonAS 2.6 supporte J2EE 1.3 y compris EJB 2.0 (sauf CMP), JTA 1.0.1, JDBC 2.0, JCA 1.0, JMX 1.0, JNDI 1.2.1, JMS 1.1, JavaMail 1.3, Servlet 2.3, JSP 1.2.
- 15 -
PROJET
3.2 - LA TECHNOLOGIE .NET
.NET est une marque de Microsoft, un qualificatif pour les produits Windows et Visual Studio, Visual Basic, ASP, ADO …, mais ni une spécification, ni un standard formel. C’est néanmoins un facteur majeur sur le marché pour l’architecture applicative.
Du fait de la polysémie de .NET, il est important de préciser ce dont il est question. .NET n’est pas le nouveau nom de DCOM ou de MTS. C’est un nouveau modèle de programmation, sensiblement différent du modèle traditionnel de Microsoft, avec des stratégies et des outils de migration.
Dans ce document, .NET désigne donc les applications écrites nativement avec VisualStudio.NET en C# ou en VisualBasic.NET. C# est un langage objet très similaire à Java. VB.NET est une évolution très significative de Visual Basic vers l’objet.
Ces applications sont ensuite exécutées sur Windows 2000 avec un certains nombre de compléments (.NET SDK), et prochainement sur Windows .NET, la nouvelle version serveur de Windows.
3.2.1 - Description technique
L’architecture de .NET se caractérise par rapport à J2EE, entre autre, par son aspect multi langages (C#, VB, …) et mono plate-forme (Windows).
SOAP
Client mi-léger WinForms
Architecture logique .NET
Client léger Navigateur
Métier o COM o COM+
(MTS)
Présentation Web
o ASP.NET o WebForms
Données
SOAP
ADO.NET
Les services sont très similaires à ceux de J2EE, sauf que .NET n’a pas de beans entité.
.NET utilise intensivement les protocoles Services Web (SOAP et WSDL) pour la communication entre les composants .NET, que ce soit en distribué ou en local. Des optimisations de performance sont faites en homogène .NET et en local, par rapport à une communication vers d’autres univers.
L’essentiel de l’innovation .NET porte sur la partie frontale et le modèle global de communication et de distribution. Pour la partie métier (l’équivalent du conteneur EJB), .NET s’appuie fortement sur le moniteur transactionnel MTS et sur la persistance ADO.NET pour l’accès aux données relationnelles.
- 16 -
PROJET
3.2.2 - Implémentation
Il n’existe bien sûr qu’un seul .NET, celui de Microsoft, actuellement disponible sur Windows 2000 et en natif sur Windows .NET. La date de GA (General Availability) de Windows .NET est prévue en début 2003. Ceci montre la relative jeunesse de la plate-forme .NET, bien qu’il soit puisse de faire du .NET soit avec Windows 2000 soit avec les pre-releases de Windows .NET.
Il existe un projet d’émulation de .NET en libre, MONO. L’opinion des auteurs de ce projet est assez partagée. Certains experts disent qu’il est quasiment impossible de faire le « reverse engineering » d’une architecture aussi évoluée que .NET sans la complicité de Microsoft et d’autres pensent que ce projet est prometteur et qu’il commence à donner des résultats. Il ne faut pas comparer cela à SAMBA par exemple qui a réussi sur le segment très bien défini d’un système de fichiers distribué.
3.2.3 - Microsoft et les standards
Avec l’apparition du Web et les conséquences du procès anti-trust, l’attitude de Microsoft face aux standards a beaucoup évolué. La compagnie contribue maintenant très valablement à l’émergence d’un certain nombres de standards importants, soit en les implémentant dans Windows, soit en les proposant pro-activement à la communauté informatique :
o HTML, XML, LDAP,
o Services Web : SOAP, WSDL …
3.3 - CATEGORIE WEB INTERACTIF
3.3.1 - Web interactif non critique
3.3.1.1 - Le besoin Il s’agit de fournir un accès Web en Intranet ou en mode Internet à une application interactive. L’application n’est pas critique au sens que ni des sommes considérables ni la réputation de l’organisation ne sont en jeu si l’exploitation s’arrête quelques heures. De plus les performances exigées ne sont pas aux limites de la technologie en terme de débit ou de temps de réponse.
Un besoin similaire existe quand l’approche peut être qualifiée d’opportuniste ; il s’agit de tester rapidement la validité d’un concept avant de le déployer de manière systématique et pérenne.
3.3.1.2 - L’architecture
C’est une architecture 3-tier classique avec un client Web léger.
3.3.1.3 - Les implémentations et leurs parts de marché
Trois variantes sont possibles : LAMP, J2EE/libre et .NET.
- 17 -
PROJET
• 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 bi-processeurs. Il existe des variantes où Oracle est utilisé comme SGBD, souvent dans des grands comptes avec des licences site Oracle au niveau du groupe. On trouve aussi parfois, mais très rarement, PostgreSQL comme SGBD en libre. Il est généralement admis que PostgreSQL est plus proche d’un « vrai » SGBDR que MySQL en termes de propriétés ACID*.
Très rarement, on observe une sous-espèce « AMP sur UNIX », souvent en réutilisation de serveurs UNIX un peu anciens. • J2EE/libre : variante Java de la précédente, tout en logiciel libre, avec
Linux comme OS, Apache + Tomcat comme serveur Web, MySQL comme SGBDR et Java comme langage de programmation. Les serveurs sont des machines Intel. Il peut parfois être utile d’ajouter un conteneur EJB comme Jonas ou Jboss.
• .NET : architecture tout Microsoft avec Windows 2000 ou .NET comme OS, IIS comme serveur Web, VisualBasic, C++, VisualBasic.NET ou C# comme langage et SQLserver comme SGBDR. Les serveurs sont des machines Intel.
En se basant sur les analyses de Netcraft (www.netcraft.com) LAMP+J2EE/libre possède 2/3 du marché et .NET 1/4. Microsoft est plus avantagé à l’intérieur des entreprises. Il est difficile de départager LAMP et J2EE/libre, sans doute autour de 45% pour LAMP et 20% pour J2EE/libre. Le J2EE commercial est minoritaire sur ce segment.
3.3.1.4 - Standards associés Dans tous les cas : HTML, DHTML
• LAMP : à la mode du libre
• J2EE/libre : servlet, JSP, JDBC, parfois EJB et JMS
• .NET : à la mode Microsoft
3.3.1.5 - Analyse multi critères
Elle est différente dans les trois cas :
- 18 -
PROJET
LAMP
Critère Commentaires
Critères généraux
Coûts d’achat logiciel gratuit, matériel peu coûteux
Coûts de possession variables selon compétences du client
Scalabilité performance 0 Faible en SMP (2-CPU), bonne en cluster
Evolutivité fonctionnelle 0 Ad-hoc
Robustesse intrinsèque + OK pour .coms
Développement 0 Faible (évaluation sujette à polémiques)
Robustesse extrinsèque 0 raisonnable
Sécurité + raisonnable
Présence du fournisseur ++ partout et nulle part
Parts de marché ++ les .com, autour de 50% sur Internet
Critères d’interopérabilité
HTML ++ C’est fait pour ça
XML ++ Xerces, Xalan, expat
Services Web ++ Axis
Composants 0 Peu structuré
Standards + Souple
Interop. J2EE + Services Web
Interop. .NET + Services Web
- 19 -
PROJET
J2EE Libre
Critère Commentaires
Critères généraux
Coûts d’achat logiciel gratuit, matériel peu coûteux
Coûts de possession variables selon compétences client
Scalabilité performance + Faible en SMP (2-CPU), bonne en cluster
Evolutivité fonctionnelle ++ composants
Robustesse intrinsèque + raisonnable
Robustesse extrinsèque 0 raisonnable
Sécurité + raisonnable
Développement + Ateliers Java
Présence du fournisseur ++ partout et nulle part
Parts de marché + Autour de 15% sur Internet
Critères d’interopérabilité
HTML ++ C’est fait pour ça
XML ++ Xerces, Xalan
Composants ++
Standards + Processus JCP
Services Web ++ Axis
Interop. J2EE ++ Conteneur Web
Interop. .NET + Services Web
- 20 -
PROJET
.NET
Critère Note Commentaires
Critères généraux
Coûts d’achat logiciel peu cher, matériel peu cher
Coûts de possession 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
3.3.1.6 - 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
- 21 -
PROJET
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.
3.3.1.7 - 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)
3.3.2 - Web interactif critique
3.3.2.1 - 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.
3.3.2.2 - L’architecture Les impératifs de performance et de transaction limitent le choix à des architectures n-tier avec frontal Web.
3.3.2.3 - Les implémentations et leurs parts de marché
L’architecture J2EE répond bien à l’ensemble de ces besoins. (Voir 3.1 - ).
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 ?
- 22 -
PROJET
• 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
- 23 -
PROJET
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.
3.3.2.4 - 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 3.1.2 - L’aspect Java Connector Architecture est particulièrement important car la connexion avec des systèmes patrimoniaux ou des PGIs est presque indispensable.
3.3.2.5 - Analyse multi critères
- 24 -
PROJET
Critère Note Commentaires
Critères généraux
Coûts d’achat Moins cher que le TP 3-tier propriétaire, souvent associé à UNIX qui est relativement coûteux
Coûts de possession Compétences maintenant largement disponibles ; plus cher que .NET néanmoins
Scalabilité performance ++ Fonctionne sur les plus gros SMP et possède des modes cluster sophistiqués
Evolutivité fonctionnelle ++ 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 du fournisseur ++ 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.
3.3.2.6 - 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),
- 25 -
PROJET
• 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.
3.3.3 - Mainframes wébisés
3.3.3.1 - 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.
3.3.3.2 - 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).
Protocole J2EE
Serveur J2EE Java
Connector Protocolepropriétaire
Mainframe
3.3.3.3 - Les implémentations et leurs parts de marché
- 26 -
PROJET
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.
3.3.3.4 - Standards associés Comme pour « Web interactif critique », voir 3.3.2.4 - en insistant particulièrement sur Java Connector Architecture.
3.3.3.5 - Analyse multi critères
- 27 -
PROJET
Critère Note Commentaires
Critères généraux
Coûts d’achat modèles de prix Mainframe
Coûts de possession 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 ++
3.3.3.6 - Outils et méthodes associés
Les mêmes que pour « Web interactif critique », voir 3.3.2.6 - .
3.3.4 - Transactionnel 3-tier webisé
3.3.4.1 - 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 3.3.3 - , 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.
3.3.4.2 - L’architecture
- 28 -
PROJET
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.
3.3.4.3 - 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.
3.3.4.4 - Standards associés
Identiques au cas « mainframe wébisé », voir 3.3.3.4 -
3.3.4.5 - Analyse multi critères
- 29 -
PROJET
Critère Note Commentaires
Critères généraux
Coûts d’achat Elevé
Coûts de possession 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 +
3.3.4.6 - Outils et méthodes associés
Les mêmes que pour « Web interactif critique », voir 3.3.2.6 - .
3.3.5 - Client lourd/serveur webisé
3.3.5.1 - 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 ?
3.3.5.2 - 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.
- 30 -
PROJET
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 ultra-léger (pratiquement du 3270 !).
Client lourdinchangé
Serveur SGBD
Client natif ICA/RDP
Navigateur + applet ICA/RDP P
s
Le client lourd s
Ce modèle préscontraintes impo
o Il est néBeaucou(par exem
o La charl’applica
3.3.5.3 - Les impléCitrix Metaframgrâce à des fonc
3.3.5.4 - Standards
Les protocoles p
3.3.5.5 - Analyse m
ICA / RD
inchangé
Serveur existant
Nouveau Serveur
Windows 2000
PC’exécute maintenant sur un serveur Windows.
ente l’avantage du faible coût de mise en œuvre mais garde des rtantes :
cessaire de « valider » le fonctionnement en mode ultra-léger. p d’éditeurs n’autorisent pas ce mode. D’autres le promeuvent
ple Siebel et SAP).
ge réseau est fortement dépendante du style d’interface de tion.
mentations et leurs parts de marché e a réussi à garder plus de 70% (Giga) de ce marché, en parti tions supérieures à celles présentes nativement dans Windows.
associés
ropriétaires ICA (Citrix) et RDP (Microsoft).
ulti critères
- 31 -
PROJET
Critère Note Commentaires
Critères généraux
Coûts d’achat faible à modéré
Coûts de possession 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
3.3.5.6 - 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.
3.4 - CATEGORIE PUBLICATION
3.4.1 - Web : Intranet & Internet « classique »
- 32 -
PROJET
3.4.1.1 - Le besoin 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.
3.4.1.2 - 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.
Présentation HTML WML
Navigateurs Données XML
Si la diffusion d’informWeb ou des téléphoneserveur Web.
Il est recommandé maiXML. Un framework d(pour PHP) est dans ce
Selon les besoins de générés dynamiquemende la publication ou cha
Un portail peut être util
3.4.1.3 - Les implémentatLe marché est partagé pour 1/3 à peu près.
Le marché des portailslibre, PHP-Nuke, constr
Voir aussi Zope en 3.4.2
3.4.1.4 - Standards associ
HTML, XML, http.
Il n’existe malheureusparticulier les modèles d
Architecture Web de publication
ation est multi-canaux, en particulier vers des tablettes s mobiles WML, ce besoin est pris en compte par le
s pas toujours possible de stocker les données au format e type Cocoon (pour Java) ou une librairie comme expat cas recommandée.
performance, les documents HTML et/ou WML sont t à la demande ou statiquement, par exemple au moment que nuit.
e pour apporter la personnalisation si elle est nécessaire.
ions et leurs parts de marché entre LAMP (voir 3.3.1.3 - ) pour 2/3 et Microsoft IIS
commerciaux est complexe et non stabilisé. En logiciel uit sur LAMP, peut être cité.
.3 -
és
ement pas encore de standard pour les portails, en e portlet* sont propriétaires.
- 33 -
PROJET
3.4.1.5 - 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 faibles
Coûts de possession 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
3.4.1.6 - Outils et méthodes associés
Voir 3.3.1.6 -
3.4.2 - Gestion de documents « en grand »
3.4.2.1 - 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
- 34 -
PROJET
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.
3.4.2.2 - 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.
3.4.2.3 - 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 avePython 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.
c
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.
3.4.2.4 - 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,
- 35 -
PROJET
• la norme de méta-données du Dublin Core (DCMI*).
Il y a bien sûr des standards de formats pour les documents eux-mêmes : SGML, HTML, XML, RTF, PDF, PostScript, Office … .
3.4.2.5 - Analyse multi critères Critère Note Commentaires
Critères généraux
Coûts d’achat souvent élevés
Coûts de possession é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 0
3.4.2.6 - 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.
3.4.3 - Streaming son/vidéo
- 36 -
PROJET
3.4.3.1 - Le besoin 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).
3.4.3.2 - 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.
- 37 -
PROJET
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é).
3.4.3.3 - 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, … .
3.4.3.4 - 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
- 38 -
PROJET
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.
3.4.3.5 - Analyse multi critères Critère Note Commentaires
Critères généraux
Coûts d’achat en baisse
Coûts de possession peu de retour d’expérience
Scalabilité performance ++ (é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 +
3.4.3.6 - Outils et méthodes associés
- 39 -
PROJET
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.
3.4.3.7 - 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 : www.tv-radio.com é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.
- 40 -
PROJET
3.5 - CATEGORIE DECISIONNEL
3.5.1 - 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.
3.5.2 - 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 3.3.1.3 - ). 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.
3.5.3 - Les implémentations et leurs parts de marché
- 41 -
PROJET
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
3.5.4 - 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.
3.5.5 - 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.
- 42 -
PROJET
Oracle
Critère Commentaires
Critères généraux
Coûts d’achat Licences assez chères
Coûts de possession selon compétences pré-requises.
Scalabilité performance ++ Bon en SMP & NUMA, moins convainquant en MPP.
Evolutivité fonctionnelle ++ 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 ++ Bonne
Parts de marché ++ 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
- 43 -
PROJET
IBM DB2
Critère Commentaires
Critères généraux
Coûts d’achat Licences propriétaires chères
Coûts de possession 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, ...
- 44 -
PROJET
Microsoft
Critère Commentaires
Critères généraux
Coûts d’achat Modéré, extension Licences souvent déjà acquises
Coûts de possession 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.
3.5.6 - 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 :
- 45 -
PROJET
Collectif
Individuel
Opé
ratio
nnel
Aid
e à
laD
écis
ion
Info
cent
re
SIAD EISTableaux de bord
Tableurs
ApplicatifsMétier
FonctionOutils de
mise en forme
source OSIS
Data Mining
3.5.7 - 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).
3.6 - CATEGORIE COLLABORATIF
3.6.1 - Le besoin
- 46 -
PROJET
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.
3.6.2 - 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
- 47 -
PROJET
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.
3.6.3 - 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 3.4.2.3 - ), 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.
3.6.4 - 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.
3.6.5 - Analyse multi critères
Les produits sont trop divers pour qu’une telle analyse ait un sens.
3.6.6 - Outils et méthodes associés
Ils dépendent du logiciel sélectionné.
3.7 - 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.
3.7.1 - Historique et émergence des PGIs
Les Progiciels de Gestion ont pratiquement toujours existé (au moins depuis 1957, premier plan comptable).
- 48 -
PROJET
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 :
• 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.
3.7.2 - Le besoin
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.
3.7.3 - 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.
- 49 -
PROJET
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.
3.7.4 - 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 inter-opérant à travers un EAI (voir 3.8 - ).
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 (www.compiere.org), un PGI pour PME (ERP et CRM, écrit en Java, SGBD Oracle pour le moment).
3.7.5 - 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, …).
3.7.6 - Analyse multi critères
Elle est faite pour les leaders du marché des grands PGIs.
- 50 -
PROJET
Critère Note Commentaires
Critères généraux
Coûts d’achat parfois élevés
Coûts de possession 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
3.7.7 - 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 3.3.2.6 - ).
3.7.8 - 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 2001-2006.
- 51 -
PROJET
3.8 - CATEGORIE INTEGRATION APPLICATIVE
3.8.1 - 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.
3.8.2 - 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
• EAI « classique » : chaque produit a tendance à avoir son architecture, même si tous partagent plus ou moins un schéma en couches comme ci-dessous : 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.
Message Oriented Middleware
Routage & Transformation des données
Règles métier
Sémantique applicative
Communication
• 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 3.7.4 - ), 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*.
- 52 -
PROJET
3.8.3 - 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 15.0 2 (2) TIBCO 12.6 3 (5) WebMethods 10.5 4 (8) SeeBeyond 8.7 5 (4) Vitria 6.1 6 (7) GXS 6.0
7 (10) Sun (iPlanet) 5.0 8 (3) Sybase 4.7 9 (6) Mercator 4.7
10 (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 ».
3.8.4 - Standards associés
XML, XSLT, SOAP, WSDL, JCA, JMS, BPEL4WS.
3.8.5 - 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.
- 53 -
PROJET
Critère Note Commentaires
Critères généraux
Coûts d’achat Les produits sont encore chers
Coûts de possession 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 La plus crédible pour le hub
Implément. .NET 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
3.8.6 - 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).
- 54 -
PROJET
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.
4.1 - 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 § 4.3 - 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
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.
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.
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.
4.1.1 - Modèle OSI à 7 couches
Ce modèle a été conçu dans les années 70-80 pour structurer une architecture informatique distribuée. Il est constitué de 7 couches :
- 55 -
PROJET
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
TCP, SCSI3
3 Réseau adressage, routage fragmentation
IP
2 Liaison trame, contrôle d’erreur IEEE 802.2
1 Physique matériel Ethernet 100baseT
s
Chaque nœud du réseau contient un sous ensemble plus ou moins complet modèle : il est possible de supprimer des couches en partant du haut et d’avainsi des nœuds de « commutation » à divers niveaux (2 à 6).
Ce modèle un peu ancien a plus ou moins bien résisté à l’évolution l’informatique ces derniers vingt ans, mais il reste dans l’ensemble aspertinent :
o Les couches 1-4, dites couches de transport représentent bien la pTCP-IP qui est devenu le standard quasi unique de communication.
o Les couches 5-7, dites couches applicatives, ont plus de mal à suil’évolution. En particulier, les modèles de communication de type apde procédure à distance (RPC*) ont tendance à mêler des élémentstype session et des éléments de type présentation.
La communication entre couches se fait par des interfaces applicatives appelAPIs*. Une API est en général lié à un langage informatiqLa communication entre nœuds du réseau se fait par des protocoSouvent un même acronyme désigne l’API et le protocole, ce qui entretient ucertaine confusion.
- 56 -
API
du oir
de sez
ile
vre pel de
ées ue. les. ne
PROJET
Nom
7 Application
6 Présentation
5 Session
4 Transport
3 Réseau
2 Liaison
1 Physique
Nom
4.1.2 - Modèle n-tier
Un « tier» caractérise une fonctiosimpliste, une première séparation les traitements ont été scindés en dle modèle de référence repose sur parfois représentés comme un tier à
Client Présentatio
Architectu
• Le tier présentation s’occupsortie,
• Le tier métier prend en chmétiers,
• Le tier données s’occupe de
Attention, il ne faut pas confondre lprésentation du modèle en couches
Rigoureusement, le client n’est pafaisant partie de la présentation, néanmoins pratique et donc pratiqué
Le modèle à 4-tier peut être condencomplexité du problème à résoudre
Protocoles
7 Application
6 Présentation
5 Session
4 Transport
3 Réseau
2 Liaison
1 Physique
n particulière de l’application. D’une manière entre données et traitement est apparue. Ensuite
eux aspects : métier et présentation. Actuellement une architecture en 4-tier puisque les clients sont par entière.
n Métier Données
re logique 4-tier
e de l’interaction avec l’utilisateur, en entrée et en
arge les traitements en fonction des processus
la persistance des données.
e tier présentation du modèle en tiers et la couche OSI.
s un tier ; ce client peut être considéré comme ou n’appartenant pas à cette typologie. Il est de représenter ainsi le modèle.
sé en 3-tier ou étendu en 5-tier ou 6-tier selon la et selon l’organisation.
- 57 -
PROJET
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 :
Applications Présentation
applicative
Présentationhumaine
Métier
Utilisateurs
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
6 Présentation
5 Session
4 Transport
3 Réseau
2 Liaison
1 Physique
Présentation
Métier Client
Données
APIs
Protocoles
4.1.3 - Structure du tier client
Selon son « poids », le tier client est structuré différemment :
- 58 -
PROJET
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 3.3.5.2 - ). Aucune « programmation » n’est disponible.
4.1.4 - 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 3.2.1 - ) 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.
4.1.5 - 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 4.6 - . Le
- 59 -
PROJET
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.
4.1.6 - 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.
4.1.6.1 - 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 5.1 - et 2.2.2 - .
4.1.6.2 - 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
- 60 -
PROJET
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 3.7 - et 3.3.3 - .
4.2 - 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.
4.2.1 - Protocoles et APIs génériques
Dans le cadre de cette étude, les couches OSI 1-2-3 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.
- 61 -
PROJET
Certains RPCs ont des instantiations multi langages (par exemple dans .NET, voir 3.2.1 - , SOAP* ou plus anciennement le RPC de DCE*), d’autres sont mono langage (par exemple Java RMI, voir 3.1.1 - )
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 5.3.1 - ) : 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 5.3 - ), 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. § 3.1 - ) 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
- 62 -
PROJET
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 5.4 - ).
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.
4.2.2 - 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 4.2.5 - ).
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
4.2.3 - Protocoles et APIs spécifiques au tier présentation
- 63 -
PROJET
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 4.2.5 - ) 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.
4.2.4 - 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 4.2.5 - ).
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.
4.2.5 - 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.
- 64 -
PROJET
• 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 …).
4.2.6 - 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 1
Serveur 2’
Serveur 2 Serveur 4Serveur 3 Utilisateurs
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 2.2.2 - )
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 5.2 -
4.3 - HISTORIQUE DES ARCHITECTURES APPLICATIVES
- 65 -
PROJET
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 rappoterminologie homogène :
rt une
• teur
•
le
ICA* ou Microsoft RDP*.
• 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 grosseapplet* ; Un client léger est un navigasans applets significatives ; Un client ultra-léger ne gère que du graphique. C’est un terminal évolué, s’appuyant par exempsur les technologies CITRIX
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
- 66 -
PROJET
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 mi-léger ou léger. Le modèle logiciel FORMS d’Oracle par exemple est un client mi-lé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.
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.
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 3.7 - ).
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.
4.4 - 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
- 67 -
PROJET
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.
- 68 -
PROJET
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.
4.5 - 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 ci-dessous 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.
ApplicationApplication
Application
Infrastructure
4.5.1 - 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
- 69 -
PROJET
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 « bonnes pratiques » (voir encadré). Il est recommandé par nombre d’analystes d’identifier et de gérer l’infrastructure informatique comme un projet en tant que tel, avec son cycle de vie, relativement indépendant de celui des applications, même si l’infrastructure est à leur service.
La notion de bonne pratique : à un instant donné, un consensus se dégage parmi les experts d’un secteur selon lequel tel problème est mieux résolu avec telle solution. En informatique, ces bonnes pratiques se dégagegénéral au niveau international, souvent de manière horizonparfois dans un
nt en
tale, mais
environnement sectoriel.
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
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é.
4.5.2 - Frontière entre application et application
- 70 -
PROJET
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é.
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.
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.
4.6 - 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,
- 71 -
PROJET
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 § 5.3 - ), 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.
- 72 -
PROJET
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.
Il y a un seul framapplicatifs. Techniquement, les fr
Composants
Framew
Serveur Ap
ework pour un proje
ameworks aident à rép
- 73 -
Composants
ork
plicatif
t, au service de tous les composants
ondre aux questions suivantes :
PROJET
• 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.
4.7.1 - 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.
4.7.2 - 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 2000. Jakarta est le groupe de la fondation Apache en charge de développer, maintenir et fournir des solutions autour de la plate-forme Java.
4.7.3 - Cocoon
- 74 -
PROJET
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é.
- 75 -
PROJET
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.
5.1 - 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.
5.1.1 - 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.
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.
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édiatiqude bases distribuées sur des clusters Linux ou Window
e
s.
- 76 -
PROJET
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.
5.1.2 - 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.
5.1.3 - 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.
5.2 - 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.
5.2.1 - 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.
- 77 -
PROJET
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.
5.2.2 - 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.
5.2.3 - 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 :
- 78 -
PROJET
Positionnement des Systèmes d’Informations
Systèmesd'Information
deProduction
Individuel
Opé
ratio
nnel
Aid
e à
laD
écis
ion
Collectif
Systèmesd'InformationDécisionnels
DonnéesExternes
Alimente
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, ...).
5.2.4 - 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
Collectif
Individuel
Opé
ratio
nnel
Aid
e à
la
Déc
isio
n
DW
Datamart
BatchProcessing
infocentreà
Valeur Ajoutée
ID
IP
Data Warehouse
SIAD/EIS
ContrôleOpérationnel
- 79 -
PROJET
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).
5.2.5 - 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
Individuel
Opé
ratio
nnel
Aid
e à
la
Déc
isio
n
Expert Décideur
Analyste
Périodique
Occasionnel
5.2.6 - Flux
- 80 -
PROJET
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).
- 81 -
PROJET
Systèmed'Informationde Production
Systèmed'Information
Décisionnel
ApplicationP1Application
P1ApplicationP1Application
P1ApplicationP1Application
Pn
DataWarehouseALIMENTATION
IdentificationExtraction
TransformationTransport
Intégration
ApplicationP1Application
P1ApplicationP1Application
P1ApplicationP1Datamart
SYNCHRONISATION
Les Flux Relatifs aux Données
SIADEIS
Data Mining
PUSH PULL
5.2.7 - 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.
5.2.7.1 - 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.
5.3 - 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,
- 82 -
PROJET
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 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.
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.
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.
- 83 -
PROJET
5.3.1 - Description technique
Techniquement, la pile des Services Web se présente comme ci-dessous :
Elle peut pasoulignés, Sdes couches
5.3.2 - Applica
Les Servexiste uvenir esdétail enabordabrendent
5.3.3 - Une arc
Les visicomposéparticuliincompaentre enstandarddéploye
5.3.4 - Un coup
Application basée Services Web Coordination
WS-Coord, WSCI
TransactionWS-Tran, BTP...
Contrat tpaMWorkflow
BPEL4WS (WSFXLANG), BPML
oute DI
SOAP, X …
HTTP
raître complexe. IlOAP, WSDL et parfsupérieures sont dan
tion à court terme
ices Web ne sont qun consensus assez lat l’intégration appl 5.4 - ). Sur ce po
le existe. Par contrpour le moment diffi
hitecture orienté se
onnaires des Servicees à partir de servicer sur le fait que tible avec la nécesstités. Sans même ens, de sécurité et de fr.
d’œil sur l’actualit
Transport , SMTP, JMS
Enveloppe P, ebXML TR&P
convient de reteois UDDI sont inds un état de flux, e
’une technologie drge selon lequel l’icative à l’intérieuint, une demande e les niveaux de cile leur adoption.
rvices ?
s Web prédisent unes disponibles sur l’aspect découve
ité de stabilité et visager cet aspect,acilité de déploiem
é des Services We
- 84 -
L...
niris
t n
eapr fo
sé
aIntrtede ilen
b
L+...
Description: WSDL
DécverUD
que seulement les standards pensables. Les autres standards on encore stabilisés.
plus. A quoi vont-ils servir ? Il plication phare dans les 2 ans à de l’entreprise (décrit plus en rte de technologie standard et
curité et de robustesse actuels
venir où les applications seront ernet. Les critiques insistent en dynamique lié à UDDI est confiance liée à toute relation reste fort à faire en matière de t avant de voir un tel modèle se
PROJET
Xmethods maintient un répertoire des Web Services: www.xmethods.net. 250 services sont répertoriés en mi-Octobre 2002. 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 »
5.4 - 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.
5.4.1 - 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.
- 85 -
PROJET
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 :
Le un déploiement pratique de ce modèle ex
Application CRM
Application J2EE
BPM basé Services Web
Application.NET
ApplicationERP
ige que les propriétés suivantes soient disponibles :
• antique bien définie (queues de messages et
« publish and subscribe »)
• ue garantie de type une-fois-et-une-seule est nécessaire pour toute application
• dépendance avec un produit particulier à déployer au bout de chaque rayon.
ette fin 2002, aucune technologie ne satisfait complètement ces 3 critères :
• mais ni asynchrone au sens ci-dessus, ni vraiment fiable du fait de HTTP ;
• rs les MOMs*, mais il n’y pas de protocole sous jacent
standardisé.
tandards 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.
tion 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* ;
Asynchronisme : en effet, l’EAI a montré qu’un modèle asynchrone est préférable, avec une sém
Fiabilité des échanges : une sémantiq
Standard : il ne doit pas y avoir de
Malheureusement, en c
SOAP sur HTTP est un standard,
SOAP sur JMS est asynchrone et fiable mais non standard. En effet JMS est une API ve
Il faut donc pour le moment utiliser des produits non s
Une approche réaliste possible à court terme, qui permet de se placer en posi
- 86 -
PROJET
• 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é.
5.4.2 - 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.
- 87 -
PROJET
6 - ANNEXES
6.1 - GLOSSAIRE
.NET l’architecture de composants de Microsoft (prononcé dotnet en anglais).
ACID Atomicité Consistance Isolation Durabilité : les 4 propriétés canoniques d’une transaction.
Apache 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 www.apache.org.
API Application Programming Interface : interface programmatique
applet Composant de code en Java pouvant s’exécuter dans le cadre d’un navigateur
ASP Advanced Server Pages : le modèle de composants de présentation Web de Microsoft
bean Composant logiciel écrit en Java
BMP, CMP Bean Managed Persistence, Container - - : 2 modes de gestion de la persistance des données dans le modèle J2EE
BPM Business Process manager : gestionnaire informatisé de processus d’entreprise
BPEL4WS Business Process Langage for Web Services : proposition IBM Microsoft de langage de workflow pour les Services Web
CCI Cadre Commun d’Interopérabilité de l’ATICA
CORBA Common Object Request Broker Architecture : architecture d composants de l’OMG
CRM Customer Relationship Management : voir GRC.
Cube 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
CVS Gestionnaire de source en logiciel libre
CWM Common Warehouse Metamodel :méta modèle décisionnel de l’OMG
DataMart "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.
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.
DCE Distributed Concurrent Environment : modèle distribué développé par l’OSF (maintenant OpenGroup) dans les années 90
DCOM Distributed Component Object Model: protocole de communication applicatif de Microsoft DNA
FAI Fournisseur d’Accès Internet
GRC 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.
ICA Independent Computing Architecture : protocole de présentation du client ultra léger de Citrix
- 88 -
PROJET
- 89 -
IETF Internet Engineering Task Force : organisme de standardisation de l’Internet (les célèbres RFCs)
IIOP Internet Inter ORB Protocol : protocole de communication entre ORBs et entre serveurs J2EE hétérogènes
J2EE Java 2 Enterprise Edition : le modèle de composants d’entreprise (comprendre transactionnel) avec Java
JCA Java Connector Architecture : cadre standard de connexion entre un serveur J2EE et des applications patrimoniales de type mainframe ou PGIs
JMS Java Messaging System : API Java et modèle sémantique de MOM
JSP Java Server Pages : composant de présentation de pages dynamiques du modèle J2EE
JTA Java Transaction API : API permettant de programmer des transactions ACID au modèle XA
JTS Java Transaction Server : protocole de transaction distribué implémentant le modèle XA
LAMP Linux Apache MySQL Perl : un ensemble de logiciels libres complémentaires pour un site Web
LDAP Light Directory Access Protocol : le standard d’accès aux répertoires de noms
LSB 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 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.
multithread Modèle de multiprogrammation à l’intérieur de l’espace d’un processus d’OS
NAS 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
NUMA 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
OLAP
On Line Analytical Processing. Caractéristiques techniques d'un système construit autour de données multidimensionnelles. Variantes MOLAP, ROLAP, …
OMG Object Management Group : promoteur de l’architecture CORBA et du CWM
ORB Object Request Broker : middleware de gestion d’un modèle de composant objet, souvent CORBA
OSF Open Software Foundation : coalition des vendeurs UNIX au siècle dernier
OSI Open System Interconnection: modèle de communication entre ordinateurs développé par l’ISO dans les années 80
Perl Langage de programmation d’applications interprété
PGI Progiciel de Gestion Intégré
PHP Langage de programmation d’applications de présentation Web
PROJET
- 90 -
Python Langage de programmation d’applications de présentation Web
Portlet Composant élémentaire de la page d’un portail
RDF Resource Description Framework : modèle et langage de description de la sémantique du Web
RDP Remote Data Protocol : le protocole de client ultra léger de Microsoft
RMI Remote Message Invocation: l’API de RPC du modèle J2EE
RPC 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 Storage Area Network : réseau (en général FibreChannel) reliant serveurs et sous-systèmes de stockage
Services Web Ensemble de protocoles et d’APIs de communication entre applications
servlet Composant de présentation sur le serveur dans le modèle J2EE
SMP Symmetrical Multi Processor : des processeurs qui se partagent une mémoire commune et cohérente de manière symétrique
SOAP Simple Object Access Protocol: protocole d’accès distant de la pile Services Web
tpmC Transactions par minute C : la métrique du benchmark de référence du TPC (Transaction Processing Council) en OLTP : TPC-C
MVC Modèle Vue Contrôleur : une façon structurée de programmer un frontal Web.
W3C World Wide Web Consortium : organisme établissant des recommandations pour le Web
WebDAV Standard de publication de site Web ; IETF RFC 2518
WML Wireless Markup Language : un HTML pour les téléphones mobiles
XA eXtended Architecture : modèle de transactions ACID distribuées défini par X/Open
XML eXtensible Markup Language : langage de description de données fort populaire
XP eXtreme Programming : une méthodologie minimaliste de développement de logiciel
XSL XML Style Sheets : standard de définition de la présentation XML
XSP XML Server Pages : une extension propriétaire au framework Cocoon