Etude analytique des architectures applicativestshaaw.free.fr/autres/articles/panorama_architectures_applicatives.pdf · écrivant à l’adresse suivante : [email protected]

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 -

mailto:[email protected]

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 -

http://www.flashline.com/components/appservermatrix.jsp

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.


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 -

http://www.netcraft.com/

PROJET

LAMP

Critère Commentaires


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


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



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


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


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


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.


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.


- 24 -

PROJET



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


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


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


- 27 -

PROJET



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


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.


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


- 29 -

PROJET



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


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 +


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 ?


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



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


Sécurité 0

Développement + besoins minimes


Parts de marché ++

Implément. J2EE -- Inadéquat

Implément. .NET ++ Etudié pour

Implément LAMP - Tentatives inabouties


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


LAMP et .NET ne sont pas différentiés significativement vis à vis des critères.



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


HTML ++

XML +

Services Web 0 inutile

Composants + widgets

Standards + demande stabilisée

Interop. .NET 0 inutile

Interop. J2EE 0 inutile


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.


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


Coûts d’achat souvent élevés

Coûts de possession élevés


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


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


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


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)


Robustesse intrinsèque - Produits encore jeunes

Robustesse extrinsèque - Produits encore jeunes

Sécurité -- Problèmes de piratage


Parts de marché 0

Implément. J2EE +

Implément. .NET +

Implément. LAMP +


HTML ++

XML +

Services Web ++

Composants 0 dépend du fournisseur

Standards + en gestation

Interop. .NET 0 dépend du fournisseur

Interop. J2EE +


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

http://www.tv-radio.com/

http://www.tv-radio.com/

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



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


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



Coûts d’achat Licences propriétaires chères

Coûts de possession selon compétences pré-requises.


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



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



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



XML 0 XML oui mais pas membre du CWM


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.


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.


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.


Les produits sont trop divers pour qu’une telle analyse ait un sens.


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.


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.


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


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, …).


Elle est faite pour les leaders du marché des grands PGIs.

- 50 -

http://www.compiere.org/

PROJET



Coûts d’achat parfois élevés

Coûts de possession significatifs

Scalabilité performance 0


Robustesse intrinsè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 ?)


HTML 0

XML 0

Services Web 0

Composants + A la mode Java

Standards 0 Peu réactifs

Interop. .NET + Correcte

Interop. J2EE ++ Bonne


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.


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


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 ».


XML, XSLT, SOAP, WSDL, JCA, JMS, BPEL4WS.


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



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 »


HTML 0 Sans grande importance

XML ++

Services Web ++


Standards ++ C’est l’objectif

Interop. .NET + via les Services Web

Interop. J2EE + via les Services Web


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


Pn

DataWarehouseALIMENTATION

IdentificationExtraction

TransformationTransport

Intégration

ApplicationP1Application


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


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 -

http://www.xmethods.net/

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