Etat de l`art des architectures applicatives

Transcription

PROJET
Etude analytique
des architectures applicatives
1 - INTRODUCTION.......................................................................................................... 2
1.1 - Objectif................................................................................................................... 2
1.2 - Périmètre de l’étude ............................................................................................... 2
1.3 - Plan de l’étude........................................................................................................ 2
1.4 - Guide de lecture ..................................................................................................... 3
2 - TYPOLOGIE APPLICATIVE ET CRITERES ......................................................... 4
2.1 - Typologie ............................................................................................................... 4
2.2 - Critères d’évaluation .............................................................................................. 5
3 - ARCHITECTURES APPLICATIVES ...................................................................... 12
3.1 - La technologie J2EE ............................................................................................ 12
3.2 - La technologie .NET ............................................................................................ 16
3.3 - Catégorie Web Interactif ...................................................................................... 17
3.4 - Catégorie Publication ........................................................................................... 32
3.5 - Catégorie Décisionnel .......................................................................................... 41
3.6 - Catégorie Collaboratif.......................................................................................... 46
3.7 - Catégorie PGIs ..................................................................................................... 48
3.8 - Catégorie Intégration applicative ......................................................................... 52
4 - APPROCHE ARCHITECTURALE .......................................................................... 55
4.1 - Modèles décrivant une architecture applicative................................................... 55
4.2 - Protocoles et APIs ................................................................................................ 61
4.3 - Historique des architectures applicatives ............................................................. 65
4.4 - Avantages et inconvénients de l’approche n-tier ................................................. 67
4.5 - Applications et infrastructure............................................................................... 69
4.6 - Composants et réutilisation.................................................................................. 71
4.7 - Frameworks.......................................................................................................... 73
5 - APPROCHES COMPLEMENTAIRES .................................................................... 76
5.1 - Les bases de données ........................................................................................... 76
5.2 - Décisionnel OLAP ............................................................................................... 77
5.3 - Les Services Web................................................................................................. 82
5.4 - L’interopérabilité applicative ............................................................................... 85
6 - ANNEXES..................................................................................................................... 88
6.1 - Glossaire............................................................................................................... 88
Document de travail et d’information
décembre 2002
ATICA
-1-
PROJET
1 - INTRODUCTION
1.1 - OBJECTIF
Cette étude des architectures applicatives vise à favoriser la connaissance dans ce
domaine ; il est perfectible et les lecteurs sont invités à l’enrichir et l’améliorer en
écrivant à l’adresse suivante : [email protected].
1.2 - PERIMETRE DE L’ETUDE
Le périmètre de cette étude est l’ensemble des architectures applicatives
informatiques ; elle ne se limite pas à celles actuellement utilisées dans
l’administration mais à l’ensemble du marché.
Par contre, les architectures des solutions orientées grand public, par exemple les
applications personnelles sur PC (bureautique, monétique …), ne seront pas prises en
compte.
En plus des architectures éprouvées, une exploration des modèles émergents sera
effectuée (par exemple les architectures s’appuyant sur des Services Web*). Dans le
même esprit, les architectures patrimoniales qui fonctionneront encore de
nombreuses années (transactionnels non Web, Mainframes ...) n’ont pas été exclues
du champ de l’étude.
Par contre les architectures pour le temps réel, la conduite de processus ou le calcul
scientifique n’en font pas partie.
1.3 - PLAN DE L’ETUDE
Le chapitre 2 - décrit la typologie de classement fonctionnelle des architectures
applicatives étudiées, et les critères qui les caractérisent, aussi bien du point de vue
général qu’en terme d’interopérabilité.
Le chapitre 3 - décrit chaque architecture et l’évalue par rapport aux critères définis.
Le chapitre 4 - traite la problématique architecturale d’un point de vue plus
analytique. Il comprend un rappel historique et une typologie de différents types
d’architecture (n-tier), puis aborde la thématique des composants et des frameworks.
Le chapitre 5 - traite des approches complémentaires, autour des bases de données et
du décisionnel, et fournit une présentation des Services Web et de l’intégration
applicative.
Le document est complété par un glossaire. Les mots du glossaire sont signalés par
une * à leur première apparition.
-2-
PROJET
1.4 - GUIDE DE LECTURE
Ce document vise des audiences diverses et peut sembler volumineux. Voici un
guide de lecture selon votre profil :
Si vous êtes expert en architecture, vous pouvez lire seulement les chapitres 2 et 3, et
les paragraphes 5.3 et 5.4.
Si vous êtes membre d’une maîtrise d’ouvrage ou d’une équipe projet :
•
Si une remise à niveau architecturale vous semble nécessaire, lisez d’abord
le chapitre 4, et des éléments du chapitre 5 selon vos sujets d’intérêt, avant
de lire les chapitres 2 et 3.
•
Si vous chercher une aide pour un projet précis, identifiez son type d’après
le chapitre 2 et allez directement au paragraphe approprié dans le chapitre 3.
Si vous souhaitez lire l’ensemble du document, commencez par les chapitres 4 et 5,
puis continuez par les chapitres 2 et 3. Cet ordre des chapitres, qui peut paraître
paradoxal, a été choisi pour éviter de présenter d’emblée aux lecteurs experts des
considérations générales qui risquent de leur sembler trop évidentes.
-3-
PROJET
2 - TYPOLOGIE APPLICATIVE ET CRITERES
Ce chapitre propose une description de la façon d’organiser les architectures applicatives
et une série de critères pour les analyser.
2.1 - TYPOLOGIE
La typologie utilisée est pragmatique, destinée à être pertinente non seulement pour les
architectes des systèmes informatiques mais également pour les maîtrises d’ouvrage et les
chefs de projet.
Bien sûr, certains projets imposent de mettre en œuvre plusieurs de ces types de façon
cohérente (par exemple, un web interactif et une gestion documentaire, éventuellement
intégrés dans une architecture de type collaboratif). C’est le travail d’un architecte de
projet d’établir cette cohérence.
• Catégorie Web Interactif : il s’agit d’applications où l’utilisateur interagit avec un
serveur Web, que ce soit en intranet ou en internet, pour accéder à des données ou
des services. L’interaction est personnalisée et ne se limite pas à la recherche
d’information classique traitée dans la catégorie publication.
o Web interactif non critique : non critique en matière d’argent, de vies
humaines ou de réputation mise en jeu ;
o Web interactif critique : critique d’après les mêmes critères ; se
caractérise souvent par la présence de transactions ;
o Mainframes webisé : une application mainframe traditionnelle exportée
sur intranet ou internet ;
o Transactionnel 3-tier webisé : une application transactionnelle exportée
sur intranet ou internet ;
o Client lourd/serveur webisé : une application client lourd traditionnelle
exportée sur intranet ou internet.
Les trois dernières architectures, qualifiées de « wébisées », couvrent les applications
patrimoniales (legacy) existantes, hétérogènes et le plus souvent anciennes mais au
cœur du dispositif. De plus, il n’est souvent pas souhaitable de les retoucher sauf
sous forme de maintenance applicative.
• Catégorie Publication : il s’agit pour l’essentiel de « pousser » de l’information vers
l’utilisateur, en le guidant au mieux :
o Web : Intranet & Internet « classique » - les vitrines des organisations ;
o Gestion de documents « en grand » : sites de journaux, évènements … ;
o Streaming son/vidéo : applications avancées comme par exemple celle de
« La Villette ».
• Catégorie Décisionnel : les applications permettant de prendre des décisions en
analysant un historique de données et de services.
• Catégorie Collaboratif : les applications permettant une meilleure efficacité du
travail en groupe :
-4-
PROJET
o Groupware ;
o Pair à pair ;
o Workflow documentaire.
• Catégorie PGIs* : une analyse de l’architecture actuelle et de la stratégie technique
des principaux acteurs du marché mondial est effectuée.
• Catégorie intégration applicative : intégrer les applications peut être considéré
comme une sorte de méta application. En particulier le programme du BPM*
(Business Process manager) est une application :
o Ad-hoc (spaghetti) : style d’intégration inclus dans les applications,
o EAI « classique » : produits d’EAI du marché,
o Web Services / XML : EAI émergente à base de technologies Services
Web.
2.2 - CRITERES D’EVALUATION
Chaque architecture est évaluée selon des critères généraux mais aussi par rapport à sa
capacité à implémenter facilement les recommandations actuelles ou à venir du Cadre
Commun d’Interopérabilité des systèmes d’information publics.
2.2.1 - Critères généraux
Certains critères nécessitant une explication plus longue sont développés dans
les paragraphes qui suivent.
• Coûts : une architecture applicative donnée induit des coûts d’achat et des
coûts de possession. Elle induit aussi des retours sur investissement et a
donc un impact économique. Ce point trop contextuel ne sera pas abordé
ici.
Les coûts d’achat comprennent les licences de logiciel et les coûts induits
en matériel et formation.
Les coûts de possession comprennent le support logiciel, l’administration
et la maintenance de l’application.
• Flexibilité : ces critères caractérisent la facilité avec laquelle l’architecture
applicative peut s’adapter à des changements au niveau des besoins, que ce
soit sur le plan fonctionnel ou sur le plan non fonctionnel :
o Extensibilité (Scalabilité) en performance (voir 2.2.2 - ),
o Evolutivité fonctionnelle,
o Capacité à intégrer de nouveaux standards,
o Richesse des environnements de développement ;
• Robustesse : ces critères caractérisent la résistance de l’architecture
applicative aux erreurs de toute nature :
o Robustesse intrinsèque du logiciel et des outils associés,
o Robustesse extrinsèque vis à vis des pannes de l’environnement, des
fautes des utilisateurs ou des administrateurs,
o Sécurité : capacité à s’intégrer et à étendre le cadre de sécurité global
du système,
-5-
PROJET
o Haute disponibilité : capacité à gérer des réplications pour la tolérance
aux pannes ;
• Pérennité : ces critères sont liés au fournisseur et au logiciel :
o Présence du fournisseur, éventuellement internationale,
o Parts de marché du logiciel (en effet, la pérennité du fournisseur ne
suffit pas, il peut décider d’abandonner un produit);
Ces points induisent naturellement la création d’un écosystème avec des
tierces parties (formation, TMA, hébergement) et des compétences
disponibles sur le marché du travail.
• Implémentation J2EE / .NET / LAMP : capacité à implémenter
l’architecture avec une de ces trois technologies
L’ensemble des critères généraux est repris dans le tableau en 2.2.4 - .
2.2.2 - Critère d’extensibilité (scalabilité) en performance
L’infrastructure matérielle se caractérise sommairement par ses capacités en terme de
puissance processeur, mémoire et entrées/sorties. La capacité processeur a une
interaction importante avec l’architecture. La capacité mémoire a également un
impact, car certaines applications ne savent pas exploiter des capacités mémoire
supplémentaires, mais cet impact est moindre. Il y a 3 dimensions possibles de
scalabilité en terme de puissance CPU :
• Puissance intrinsèque du CPU, c’est à dire sa fréquence, son architecture et
ses caches : cet aspect n’a pas d’interaction avec l’architecture
applicative ;
• Multiprocesseur symétrique SMP* : ajout de processeurs qui se partagent
la mémoire (NUMA* n’est qu’une variante de SMP) ;
• Grappe (ou cluster, ou MPP*) : ajout des nœuds reliés entre eux par un
réseau de communication.
Pour pouvoir exploiter correctement une Google : un exemple de scalabilité
augmentation de performance dans les cluster exemplaire : le moteur de
dimensions SMP ou cluster, il faut bien sûr que recherche Google est implémenté
les éléments logiciels sous-jacents soient eux- par une gigantesque grappe de plus
même scalables dans cette dimension ; ceci est de 10 000 machines Linux. Ceci est
efficace car l’algorithme de
particulièrement vrai pour l’OS, la base de recherche de Google est écrit pour
données et le serveur applicatif. C’est également ce mode de fonctionnement. Un
vrai pour l’application elle-même, mais ceci sort autre moteur de recherche avec un
du cadre de l’étude puisque maîtrisé par le autre algorithme pourrait être tout a
concepteur de l’application : par exemple, le fait inefficace sur la même
architecture. Pourtant le service
modèle proposé par le serveur applicatif peut être rendu au client est le même !
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.
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
données sur un navigateur
DNS
Serveur de noms de domaines
SMTP
MIME
S/MIME
Protocole et formats d’échange de Capacité à échanger du mél MIME et
mél
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 Capacité à communiquer sur une socket
niveau du transport
« secure »
PKI, X.509
Certificats à clef publique
Capacité
à
utiliser
X.509
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
des Capacité à produire du HTML
Néant
pour
XML, XSL Langage de description de données Capacité à manipuler et produire du XML,
XMLSchema et de meta-données
conformément à des XMLSchemas
SOAP
WSDL
UDDI
Formats
Transport applicatif de XML
Capacité à produire et consommer des
Langage de description d’interface services Web
Annuaire pour les services Web
Capacité à découvrir et publier des
services Web
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
Vers Etat du
ion
std.
Commentaires
Typologie et critères
Standards trans-architectures
RPC universel
SOAP
surtout
métier
1.1
Langage de description
d’interface
WSDL
surtout
métier
1.1
Annuaire de services
UDDI
surtout
métier
2.03
Meta données XML
XML
Schema
tous
1.0
Sécurité : confidentialité et
authentification mutuelle
SSL
TLS
X.509
tous
3.0
1.0
Profil d’utilisation des Services Basic
Web
profile
tous
1.0
A faire
La version 1.2 proposée par le
W3C n’est pas stabilisée
"
"
"
"
"
Un annuaire UDDI n’est pas
indispensable
"
Nécessaire à l’encodage WSDL
"
Schémas d’encryption de SOAP
sur https
Authentification service et client
"
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
"
Communication entre
composants
RMI/IIOP
métier
1.0
"
RPC entre composants
JAX-RPC
surtout
métier
1.0
"
Abusivement, JCA
A éviter en hétérogène ; préférer
les Services Web
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
Implémentation LAMP
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
d’implémentation J2EE et .NET sont décrits.
terme
de
plates-formes
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 et ouverture
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 est généralement considéré comme un cadre plus
ouvert que .NET ; néanmoins, il n’est techniquement pas
impossible à Sun de reprendre plus de contrôle, puisque le
JCP est la loi définie par Sun. L’ouverture de J2EE n’est
paradoxalement garantie que par la relative faiblesse de Sun
dans le secteur du logiciel. Les vrais poids lourds de J2EE,
ceux qui ont des parts de marché et du revenu de produits et
de services associé à cette technologie sont pour l’essentiel
IBM, Oracle et BEA. Un Sun qui deviendrait dominant sur
le marché du logiciel pourrait adopter des pratiques
monopolistiques semblables à celles de Microsoft. Cette
hypothèse est néanmoins très peu vraisemblable.
La certification est un bon exemple de la politique de
contrôle de Sun. La certification J2EE est contrôlée par Sun
et demande le passage d’une suite de vérification et le
paiement de royalties liées aux interfaces. Par le biais de
subtilités juridiques dans la licence Java, qui ont alimenté la
querelle entre Java et le monde du libre, Sun a jusqu’à ce
jour empêché la certification de produits libres J2EE.
(Néanmoins, il semble que l’évolution de JCP 2.5 rende
possible en 2003 la certification J2EE 1.4 de Jonas et Jboss).
Cette certification ne doit donc pas être vue seulement
comme un label de qualité technique, ce qu’elle est
indubitablement, mais aussi comme un outil politicoindustriel.
- 12 -
PROJET
Client léger
Présentation
Conteneur Web
Navigateur
Client lourd
Application /
Applet
RMI
Métier
Conteneur EJB
o JCA
o JMS …
o Servlet
o JSP
JDBC
Données
RMI
Architecture logique J2EE
Deux conteneurs existent de-facto :
• Le conteneur Web s’occupe de la présentation :
o les servlet hébergent le code Java,
o les JSP (Java Server Pages) hébergent du HTML dynamisé par du
Java.
o JDBC permet d’accéder aux données rangées dans un SGBDR
• Le conteneur EJB héberge la partie métier. Sa vertu principale est de
permettre une gestion déclarative de notions complexes à programmer :
o Les sessions : le conteneur gère des beans session, avec ou sans état,
qui représentent l’interaction courante du client avec le système (par
exemple son caddy sur un site de e-commerce).
o Les transactions
o La persistance des objets : le conteneur gère des beans entité qui
représentent les objets persistants, soit en laissant l’initiative au bean
(Bean Managed Persistence, BMP) soit via un système automatique
appelé CMP (Container Managed Persistence)
o Un modèle de sécurité basé sur les rôles
o Le cycle de vie des composants (activation, passivation)
o Un modèle de communication asynchrone avec les Message Driven
Beans et l’API JMS
• Le protocole de communication entre beans est RMI, et plus précisément
RMI/IIOP pour les interactions hétérogènes (Note : en réalité, il n’y a jamais
de communication hétérogène, par exemple entre WebLogic et WebSphere,
au niveau RMI).
Un point important est que le conteneur EJB n’est pas indispensable. On peut
implémenter la partie métier avec le conteneur Web, JDBC pour accéder aux
données et des beans Java classiques.
Ce point est un sujet de polémiques interminables dans la communauté Java :
- 13 -
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
http://www.flashline.com/components/appservermatrix.jsp
sur
Internet :
3.1.4 - Produits commerciaux non certifiés J2EE 1.3
Cette liste n’est pas exhaustive:
• Caucho, Resin-EJB
• HP, HP-AS
• Hitachi, Cosminexus
• Iona, J2EE Technology
• Ironflare, Orion
• Sun, SunOne Application Server
3.1.5 - Produits libres
• Apache + Tomcat 4.1 : cet ensemble ne gère que le conteneur Web, donc les
standards suivants : servlet 2.3, JSP 1.2, JDBC 2.0
• Jboss (+Apache + Tomcat) : Jboss est le conteneur EJB le plus répandu dans le
monde du libre. Il implémente les standards suivants : EJB 2.0, servlet 2.3, JSP
1.2, JDBC 2.0
• Objectweb Jonas (+Apache + Tomcat) : Jonas est une technologie d’origine
Bull, donnée au consortium objectweb. JonAS 2.6 supporte J2EE 1.3 y compris
EJB 2.0 (sauf CMP), JTA 1.0.1, JDBC 2.0, JCA 1.0, JMX 1.0, JNDI 1.2.1,
JMS 1.1, JavaMail 1.3, Servlet 2.3, JSP 1.2.
- 15 -
PROJET
3.2 - LA TECHNOLOGIE .NET
.NET est une marque de Microsoft, un qualificatif pour les produits Windows et
Visual Studio, Visual Basic, ASP, ADO …, mais ni une spécification, ni un standard
formel. C’est néanmoins un facteur majeur sur le marché pour l’architecture
applicative.
Du fait de la polysémie de .NET, il est important de préciser ce dont il est question.
.NET n’est pas le nouveau nom de DCOM ou de MTS. C’est un nouveau modèle de
programmation, sensiblement différent du modèle traditionnel de Microsoft, avec des
stratégies et des outils de migration.
Dans ce document, .NET désigne donc les applications écrites nativement avec
VisualStudio.NET en C# ou en VisualBasic.NET. C# est un langage objet très
similaire à Java. VB.NET est une évolution très significative de Visual Basic vers
l’objet.
Ces applications sont ensuite exécutées sur Windows 2000 avec un certains nombre
de compléments (.NET SDK), et prochainement sur Windows .NET, la nouvelle
version serveur de Windows.
L’architecture de .NET se caractérise par rapport à J2EE, entre autre, par son
aspect multi langages (C#, VB, …) et mono plate-forme (Windows).
Client léger
Présentation
Web
Navigateur
o
o
Métier
SOAP
o
o
ASP.NET
WebForms
Client mi-léger
WinForms
COM
COM+
(MTS)
ADO.NET
Données
SOAP
Architecture logique .NET
Les services sont très similaires à ceux de J2EE, sauf que .NET n’a pas de beans
entité.
.NET utilise intensivement les protocoles Services Web (SOAP et WSDL) pour
la communication entre les composants .NET, que ce soit en distribué ou en
local. Des optimisations de performance sont faites en homogène .NET et en
local, par rapport à une communication vers d’autres univers.
L’essentiel de l’innovation .NET porte sur la partie frontale et le modèle global
de communication et de distribution. Pour la partie métier (l’équivalent du
conteneur EJB), .NET s’appuie fortement sur le moniteur transactionnel MTS et
sur la persistance ADO.NET pour l’accès aux données relationnelles.
- 16 -
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 proactivement à la communauté informatique :
o HTML, XML, LDAP,
o Services Web : SOAP, WSDL …
3.3 - CATEGORIE WEB INTERACTIF
3.3.1 - Web interactif non critique
3.3.1.1 - Le besoin
Il s’agit de fournir un accès Web en Intranet ou en mode Internet à une
application interactive. L’application n’est pas critique au sens que ni des
sommes considérables ni la réputation de l’organisation ne sont en jeu si
l’exploitation s’arrête quelques heures. De plus les performances exigées ne sont
pas aux limites de la technologie en terme de débit ou de temps de réponse.
Un besoin similaire existe quand l’approche peut être qualifiée d’opportuniste ;
il s’agit de tester rapidement la validité d’un concept avant de le déployer de
manière systématique et pérenne.
3.3.1.2 - L’architecture
C’est une architecture 3-tier classique avec un client Web léger.
3.3.1.3 - Les implémentations et leurs parts de marché
Trois variantes sont possibles : LAMP, J2EE/libre et .NET.
- 17 -
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 biprocesseurs.
Il existe des variantes où Oracle est utilisé comme SGBD, souvent dans
des grands comptes avec des licences site Oracle au niveau du groupe. On
trouve aussi parfois, mais très rarement, PostgreSQL comme SGBD en
libre. Il est généralement admis que PostgreSQL est plus proche d’un
« vrai » SGBDR que MySQL en termes de propriétés ACID*.
Très rarement, on observe une sous-espèce « AMP sur UNIX », souvent en
réutilisation de serveurs UNIX un peu anciens.
• J2EE/libre : variante Java de la précédente, tout en logiciel libre, avec
Linux comme OS, Apache + Tomcat comme serveur Web, MySQL
comme SGBDR et Java comme langage de programmation. Les serveurs
sont des machines Intel. Il peut parfois être utile d’ajouter un conteneur
EJB comme Jonas ou Jboss.
• .NET : architecture tout Microsoft avec Windows 2000 ou .NET comme
OS, IIS comme serveur Web, VisualBasic, C++, VisualBasic.NET ou C#
comme langage et SQLserver comme SGBDR. Les serveurs sont des
machines Intel.
En se basant sur les analyses de Netcraft (www.netcraft.com)
LAMP+J2EE/libre possède 2/3 du marché et .NET 1/4. Microsoft est plus
avantagé à l’intérieur des entreprises. Il est difficile de départager LAMP et
J2EE/libre, sans doute autour de 45% pour LAMP et 20% pour J2EE/libre. Le
J2EE commercial est minoritaire sur ce segment.
3.3.1.4 - Standards associés
Dans tous les cas : HTML, DHTML
•
LAMP : à la mode du libre
•
J2EE/libre : servlet, JSP, JDBC, parfois EJB et JMS
•
.NET : à la mode Microsoft
3.3.1.5 - Analyse multi critères
Elle est différente dans les trois cas :
- 18 -
PROJET
LAMP
Critère
Commentaires
Coûts d’achat
logiciel gratuit, matériel peu coûteux
variables selon compétences du client
0
Faible en SMP (2-CPU), bonne en cluster
0
Ad-hoc
+
OK pour .coms
Développement
0
Faible (évaluation sujette à polémiques)
0
raisonnable
Sécurité
+
raisonnable
++ 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
Critère
Commentaires
Coûts d’achat
logiciel gratuit, matériel peu coûteux
variables selon compétences client
+
Faible en SMP (2-CPU), bonne en
cluster
Evolutivité fonctionnelle ++ composants
+ raisonnable
0
Sécurité
+ raisonnable
Développement
+ Ateliers Java
++ partout et nulle part
Parts de marché
+ Autour de 15% sur Internet
raisonnable
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
facile à développer et opérer
+
Raisonnable, SMP, grappe
+
-
0
Sécurité
--
Attendons les preuves avec Windows .NET
Développement
++
Reconnu comme un des meilleurs
++
Incontournable
Parts de marché
++
Elevées, 50% globalement
Attendons les preuves avec Windows .NET
HTML
++
Natif
XML
++
Natif
Composants
++
Architecture composants
Standards
-
Services Web
++
Interop J2EE
0
Interop .NET
++
Selon la stratégie business de Microsoft
Natif
Services Web
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.
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.
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
Critère
Note
Commentaires
Coûts d’achat
Moins cher que le TP 3-tier propriétaire, souvent associé à UNIX qui est
relativement coûteux
Compétences maintenant largement disponibles ; plus cher que .NET
néanmoins
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
++
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
Présence
fournisseur
du
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.
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.
Historiquement on eut lieu une phase de simple émulation de terminaux
mainframes dans un navigateur, puis de rhabillage HTML ; ces approches ont
rencontré des limites et il est apparu plus avantageux pour les applications
mainframes correctement architecturées, c’est à dire où présentation synchrone
et transactions étaient correctement séparées, de situer l’interface avec le
mainframe au niveau de la visibilité métier.
Les mainframes exposent très rarement leurs données en direct. Le plus souvent,
ces données sont encapsulées dans des transactions métiers, comme « créer un
nouveau client ». Il s’agit donc de donner accès à ces transactions à partir de
l’univers du Web. Les deux principaux fournisseurs de mainframe du marché
(IBM et Bull) ont choisi J2EE comme frontal privilégié, tout en fournissant aussi
des adaptateurs pour .NET mais sans les pousser.
La norme de connexion est Java Connector Architecture (souvent raccourcie par
erreur en JCA).
Serveur
J2EE
Java
Connector
Mainframe
Protocole
propriétaire
Protocole J2EE
- 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.
Comme pour « Web interactif critique », voir 3.3.2.4 - en insistant
particulièrement sur Java Connector Architecture.
- 27 -
PROJET
Critère
Note
Commentaires
Coûts d’achat
modèles de prix Mainframe
modèles de prix Mainframe
+
-
Difficile , accès aux compétences
++
qualité mainframe
++
qualité mainframe
Sécurité
++
qualité mainframe
Développement
0
via Java, sinon assez anciens
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
Services Web
0
Composants
-
Standards
--
Réactivité moyenne
Interop. .NET
+
des produits existent
Interop. J2EE
++
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.
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.
Identiques au cas « mainframe wébisé », voir 3.3.3.4 3.3.4.5 - Analyse multi critères
- 29 -
PROJET
Critère
Note
Commentaires
Coûts d’achat
Elevé
Elevé
++
+
++
++
Sécurité
++
Développement
0
+
Parts de marché
+
Implément. J2EE
++
Implément. .NET
0
figé
Choix préféré des fournisseurs
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 ultraléger (pratiquement du 3270 !).
Navigateur
+ applet
ICA/RDP
ICA / RDP
Client lourd
inchangé
Serveur
SGBD
inchangé
Client natif
ICA/RDP
PCs
Nouveau
Serveur
Windows 2000
Serveur
existant
Le client lourd s’exécute maintenant sur un serveur Windows.
Ce modèle présente l’avantage du faible coût de mise en œuvre mais garde des
contraintes importantes :
o Il est nécessaire de « valider » le fonctionnement en mode ultra-léger.
Beaucoup d’éditeurs n’autorisent pas ce mode. D’autres le promeuvent
(par exemple Siebel et SAP).
o La charge réseau est fortement dépendante du style d’interface de
l’application.
Citrix Metaframe a réussi à garder plus de 70% (Giga) de ce marché, en parti
grâce à des fonctions supérieures à celles présentes nativement dans Windows.
Les protocoles propriétaires ICA (Citrix) et RDP (Microsoft).
- 31 -
PROJET
Critère
Note
Commentaires
Coûts d’achat
faible à modéré
le principal argument de vente
0
--
0
0
Sécurité
0
Développement
+
+
Parts de marché
++
Implément. J2EE
--
Inadéquat
Implément. .NET
++
Etudié pour
Implément LAMP
-
Néant
besoins minimes
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
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.
Une architecture Web 3-tier convient parfaitement. La logique métier est
inexistante et il n’est pas indispensable d’utiliser un SGBD, un système de
fichiers est souvent suffisant.
Navigateurs
Présentation
HTML WML
Données
XML
Architecture Web de publication
Si la diffusion d’information est multi-canaux, en particulier vers des tablettes
Web ou des téléphones mobiles WML, ce besoin est pris en compte par le
serveur Web.
Il est recommandé mais pas toujours possible de stocker les données au format
XML. Un framework de type Cocoon (pour Java) ou une librairie comme expat
(pour PHP) est dans ce cas recommandée.
Selon les besoins de performance, les documents HTML et/ou WML sont
générés dynamiquement à la demande ou statiquement, par exemple au moment
de la publication ou chaque nuit.
Un portail peut être utile pour apporter la personnalisation si elle est nécessaire.
Le marché est partagé entre LAMP (voir 3.3.1.3 - ) pour 2/3 et Microsoft IIS
pour 1/3 à peu près.
Le marché des portails commerciaux est complexe et non stabilisé. En logiciel
libre, PHP-Nuke, construit sur LAMP, peut être cité.
Voir aussi Zope en 3.4.2.3 -
HTML, XML, http.
Il n’existe malheureusement pas encore de standard pour les portails, en
particulier les modèles de portlet* sont propriétaires.
- 33 -
PROJET
LAMP et .NET ne sont pas différentiés significativement vis à vis des critères.
Critère
Note
Commentaires
Coûts d’achat
faibles
faibles
+
0
+
+
Sécurité
0
Développement
++
++
Parts de marché
++
Implément. J2EE
-
Les besoins sont modérés
Nombreux et variés
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.
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.
Zope
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 est un framework en logiciel libre,
permettant de construire des solutions
de gestion de contenu ou de groupware.
Il est basé sur un modèle LAMP avec
Python comme langage. Zope a un club
assez actif. Les revenus de Zope
Corporation, le créateur de Zope, sont
générés en mode service.
Les solutions de cache réseau sont soit orientées produits, à acheter par les
FAIs* (NetworkAppliance, F5 …) soit orientées services, à acheter par le
fournisseur de contenu (Akamai). Ce choix n’est pas sans impact sur
l’application elle-même.
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 … .
Critère
Note
Commentaires
Coûts d’achat
souvent élevés
élevés
+
++
+
+
Sécurité
+
Développement
+
Nombreux outils
0
selon le fournisseur
Parts de marché
0
Implément. J2EE
+
possible
Implément .NET
+
possible
Implément LAMP
-
un peu juste
Outils souples
HTML
+
XML
+
Services Web
0
En gestation
Composants
0
Standards
+
En gestation
Interop. .NET
0
Interop. J2EE
0
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é).
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, … .
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.
Critère
Note
Commentaires
Coûts d’achat
en baisse
peu de retour d’expérience
(équilibrage de charge et débit
ajustable)
++
0
-
Produits encore jeunes
-
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.tvradio.com émanation de TDF. Une explication possible de ce frein est le
déploiement des sites de diffusion MPEG2 pas encore amortis par les opérateurs
TV et la frilosité contextuelle des opérateurs télécommunications.
Un axe de développement est la communication d’entreprise, à travers la
vidéoconférence et la formation qui permet de réduire les déplacements et
l’indisponibilité des personnes.
- 40 -
PROJET
3.5 - CATEGORIE DECISIONNEL
3.5.1 - Le besoin
Le besoin émane des acteurs de l ‘entreprise qui, pour remplir leurs
objectifs/missions doivent prendre des décisions et piloter.
Ces décisions, pour être pertinentes, nécessitent des clichés et des analyses des
données de production de l’entreprise adaptés (Datawarehouse) aux exigences
des utilisateurs.
Ces différents clichés n’existent pas toujours, d’où des besoins inopinés (à la
volée, impromptus) qui peuvent réclamer l’ensemble des données de production
aménagées, voire leur historique (pour des analyse de tendance par exemple).
Il s’agit par ailleurs de mettre à disposition des ces utilisateurs des outils qui leur
permettent de réaliser des clichés/analyses eux-mêmes à discrétion.
Bien évidemment, la rapidité des décisions est un facteur clé de réussite, ainsi la
fraîcheur des clichés de données/historiques oblige les architectures résultantes à
être équipées de composants bien ciblés quant aux types & nombre
d’utilisateurs, aux volumes brassés, à la cohérence des données manipulées, aux
clichés/analyses potentiellement possibles et à la matérialisation de ceux-ci.
3.5.2 - Les architectures
Ce sont des architectures 3-tier classiques ou hybrides selon les besoins de
l’entreprise :
1. Au niveau du serveur de données, il est possible d’avoir des contentions au
niveau CPU et/ou au niveau E/S. Pour répondre à ces deux problèmes, le
parallélisme (intrinsèque CPU et/ou données) d’une part et d’autre part la
possibilité d’accroître les ressources le plus linéairement possible peuvent
être introduits. Les architectures résultantes peuvent être de type SMP ou
grappe.
2. Les serveurs d’applications sont plutôt considérés comme des serveurs
intermédiaires (l’application n’étant à priori définie ; seul le besoin
générique est connu). La combinatoire entre ces deux niveaux de serveurs
fait appel à un mapping de l’exploitation des données essentiellement
dépendant des besoins et du volume de celles-ci. Ainsi, selon la
combinatoire, on aura à faire à du MOLAP, ROLAP ou du HOLAP.
3. Trois variantes sont possibles pour matérialiser/router/publier les restitutions
: LAMP, J2EE/libre et .NET (voir 3.3.1.3 - ). En revanche, le Data Mining la
plupart du temps s’inscrit en mode client/serveur traditionnel (publiable ou
non en Web) ; ceci est dû principalement à l’ancienneté des outils (origine
Mainframe) qui utilisent des algorithmes connus depuis plus de 20 ans
(Fortran, APL, ...) et au faible nombre d’utilisateurs potentiels.
3.5.3 - Les implémentations et leurs parts de marché
- 41 -
PROJET
Les 10 acteurs les plus importants du marché sont :
1
Oracle
2
SAS
3
IBM
4
COGNOS
5
CA
6
Teradata
7
Microsoft
8
SAP
9
Micro Strategy
10
People Soft
3.5.4 - Standards associés
Concernant le décisionnel, le seul standard vraiment spécifique est la conformité
au CWM* qui implique par ailleurs XML. Les autres normes sont déjà traitées
dans le cadre des architectures traditionnelles.
3.5.5 - Analyse multi critères
Les offres majeures sont celles d’ORACLE, IBM DB2 et Microsoft (une offre
ouverte, une offre propriétaire, un challenger). En effet, les autres offres sont de
toutes façons juxtaposables/combinables aux trois offres retenues.
TERADATA, peu répandu en France (TRANSPAC, La Poste, Chronopost,...)
est exclusivement réservé aux grands comptes et connu depuis fort longtemps.
- 42 -
PROJET
Oracle
Critère
Commentaires
Coûts d’achat
Licences assez chères
selon compétences pré-requises.
++ Bon en SMP & NUMA, moins convainquant en MPP.
++ Ad-hoc
+
Selon configurations
+
Selon configurations
Sécurité
+
Dans son univers
Développement
+
Ecosystème varié
++ 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
- 43 -
PROJET
IBM DB2
Critère
Commentaires
Coûts d’achat
Licences propriétaires chères
selon compétences pré-requises.
+
++ Ad-hoc selon Outils juxtaposés
++ Atout propriétaire
Sécurité
Développement
+
++ Bonne
Parts de marché
+
Assez complet
N° 1 propriétaire
HTML
+
XML
+
Associé au CWM
Composants
0
Peu pertinent
Standards
+
Flexible
Services Web
+
Portail
Interop. J2EE
++ WebSphere, fonction de la combinatoire
Interop. .NET
0
Possible en greffant SAS, BO, COGNOS,
...
- 44 -
PROJET
Microsoft
Critère
Commentaires
Coûts d’achat
Modéré,
acquises
selon compétences pré-requises, souvent le cas
grâce à son implantation clients
0
++
extension
Licences
souvent
déjà
Moyen en SMP peu prouvé.
Ad-hoc, ACCESS,
juxtaposés
Excel,
selon
0
Origine SYBASE + AdOne
0
selon réputation
Sécurité
0
réputation connue
+
Surtout forte en bureautique et réseau
Parts de marché
0
Challenger pour l’instant (VLDB ?)
Outils
HTML
+
XML
0
XML oui mais pas membre du CWM
Composants
0
Peu pertinent
Standards
-
Selon la stratégie du vendeur
Services Web
+
Portail
Interop. J2EE
+
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
source OSIS
Collectif
EIS
Tableaux
de bord
Applicatifs
Métier
Fonction
Outils de
mise en forme
Infocentre
Opérationnel
SIAD
Aide à la
Décision
Data Mining
Tableurs
Individuel
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 interopé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 -
PROJET
Critère
Note
Commentaires
Coûts d’achat
parfois élevés
significatifs
0
0
0
0
Sécurité
0
Développement
+
0
Parts de marché
0
Implément. J2EE
++
Implément .NET
0
seulement pour le milieu de gamme
Implément LAMP
-
rare (pour le moment ?)
Selon le produit, mais aussi J2EE
choix préféré
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.
Règles métier
Business Process Manager
Routage & Transformation des données
Message Oriented Middleware
Sémantique
applicative
Communication
• EAI « classique » : chaque produit a tendance à avoir son architecture,
même si tous partagent plus ou moins un schéma en couches comme cidessous :
Presque tous les produits sont bâtis sur une architecture de type serveur
d’application, mais certains plus récents utilisent une base J2EE ou .NET.
mais de toute façon, les formats pivots utilisés, les transformateurs de
données, l’architecture des adaptateurs et le langage de workflow (BPM)
sont spécifiques.
• Web Services / XML : dans ce modèle émergent, le moyeu interagit avec
les applications autant que faire se peut via des protocoles Web Services
(SOAP sur HTTP ou JMS). Si les applications fournissent elle-même un
interface SOAP (voir 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)
1 (1)
2 (2)
3 (5)
4 (8)
5 (4)
6 (7)
7 (10)
8 (3)
9 (6)
10 (9)
Vendeur
IBM
TIBCO
WebMethods
SeeBeyond
Vitria
GXS
Sun (iPlanet)
Sybase
Mercator
BEA
Autres
Parts de marché %
15.0
12.6
10.5
8.7
6.1
6.0
5.0
4.7
4.7
4.2
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
Critère
Note
Commentaires
Coûts d’achat
Les produits sont encore chers
Les services à associer sont conséquents
+
Basés sur des serveurs d’application 3-tier
++
Un BPM est très souple
0
Produits peu matures, en forte évolution
+
Architecture saine
Sécurité
+
Développement
+
En plein essor
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
XML
++
Services Web
++
Composants
0
Sans grande importance
Peu pertinent
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é.
Un tier, deux tiers, trois tiers, n-tier …
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
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 ntier en anglais s’écrit sans s. On a adopté
dans ce document le mot tier et
l’orthographe anglaise pour n-tier.
o Les couches du modèle n-tier : généralement
représentées comme horizontales, de gauche à
droite du client aux données sur les schémas. Pour éviter la confusion, ces couches
verticales seront dénommées tiers.
Ces deux modèles sont orthogonaux et donc complémentaires.
Nous les décrivons ci-dessous. Il paraît toutefois important de préciser que le modèle OSI
n’est plus vraiment utilisé de nos jours pour décrire les architectures applicatives et que dans
le reste du document, la vision par tier sera privilégiée.
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
APIs
Chaque nœud du réseau contient un sous ensemble plus ou moins complet du
modèle : il est possible de supprimer des couches en partant du haut et d’avoir
ainsi des nœuds de « commutation » à divers niveaux (2 à 6).
Ce modèle un peu ancien a plus ou moins bien résisté à l’évolution de
l’informatique ces derniers vingt ans, mais il reste dans l’ensemble assez
pertinent :
o Les couches 1-4, dites couches de transport représentent bien la pile
TCP-IP qui est devenu le standard quasi unique de communication.
o Les couches 5-7, dites couches applicatives, ont plus de mal à suivre
l’évolution. En particulier, les modèles de communication de type appel
de procédure à distance (RPC*) ont tendance à mêler des éléments de
type session et des éléments de type présentation.
La communication entre couches se fait par des interfaces applicatives appelées
APIs*. Une API est en général lié à un langage informatique.
La communication entre nœuds du réseau se fait par des protocoles.
Souvent un même acronyme désigne l’API et le protocole, ce qui entretient une
certaine confusion.
- 56 -
PROJET
Protocoles
Nom
Nom
7 Application
7 Application
6 Présentation
6 Présentation
5 Session
5 Session
4
4
Transport
Transport
3 Réseau
3 Réseau
2 Liaison
2 Liaison
1 Physique
1 Physique
4.1.2 - Modèle n-tier
Un « tier» caractérise une fonction particulière de l’application. D’une manière
simpliste, une première séparation entre données et traitement est apparue. Ensuite
les traitements ont été scindés en deux aspects : métier et présentation. Actuellement
le modèle de référence repose sur une architecture en 4-tier puisque les clients sont
parfois représentés comme un tier à par entière.
Client
Présentation
Métier
Données
Architecture logique 4-tier
•
Le tier présentation s’occupe de l’interaction avec l’utilisateur, en entrée et en
sortie,
•
Le tier métier prend en charge les traitements en fonction des processus
métiers,
•
Le tier données s’occupe de la persistance des données.
Attention, il ne faut pas confondre le tier présentation du modèle en tiers et la couche
présentation du modèle en couches OSI.
Rigoureusement, le client n’est pas un tier ; ce client peut être considéré comme
faisant partie de la présentation, ou n’appartenant pas à cette typologie. Il est
néanmoins pratique et donc pratiqué de représenter ainsi le modèle.
Le modèle à 4-tier peut être condensé en 3-tier ou étendu en 5-tier ou 6-tier selon la
complexité du problème à résoudre et selon l’organisation.
- 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 :
Présentation
humaine
Utilisateurs
Métier
Données
Présentation
applicative
Applications
Architecture logique 4-tier complète
Cette représentation n’est pas totalement conventionnelle. Certains représentent le
concept de « présentation applicative » ou « intégration » comme une fonction
externe au modèle 3-tier. Il est délicat de trancher, et surtout de vouloir modéliser
l’architecture informatique aussi simplement.
Le modèle n-tier est une représentation d’une architecture logique ; elle signifie
simplement que le code de l’application est composé de modules qui implémentent
chacun un tier particulier, sans référence particulière aux ordinateurs servant à
instancier l’architecture.
Les deux modèles complémentaires peuvent être globalement représentés ainsi :
7 Application
Client
Présenta
tion
Métier
Données
6 Présentation
5 Session
APIs
4 Transport
3 Réseau
2 Liaison
1 Physique
Protocoles
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 2’
Utilisateurs
Serveur 1
Serveur 2
Serveur 3
Serveur 4
Architecture physique 5-tier
Il existe des dizaines de manières de plaquer une architecture logique n-tier sur une
architecture physique n-tier. La décision est prise selon les critères généraux de
l’entité qui met en oeuvre et ceux spécifiques au projet. L’analyse de cet aspect
n’entre pas dans le champ de la présente étude, néanmoins voici quelques critères
pertinents :
o Rapport prix performance des serveurs
o Capacité des OS choisis pour le multi applicatif
o Scalabilité des plate-formes en SMP et en grappe (voir 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.
Poids du client : le client lourd est
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.
relativement bien défini. Il contient
tout le code applicatif, présentation et
métier. Par contre, il n’existe pas de
définition universellement acceptée
du client léger, ou fin. On s’est
efforcé d’utiliser dans ce rapport une
terminologie homogène :
• Un client mi-léger gère seulement
de la présentation. Ce peut être
un gestionnaire de formulaires
fait par exemple avec un
navigateur avec une grosse
applet* ;
• Un client léger est un navigateur
sans applets significatives ;
• Un client ultra-léger ne gère que
du graphique. C’est un terminal
évolué, s’appuyant par exemple
sur les technologies CITRIX
ICA* ou Microsoft RDP*.
Historiquement, ces trois modèles se sont succédés comme des architectures de
référence. Ils cohabitent, mais la bonne pratique recommandée actuellement est le ntier. 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 miléger ou léger. Le modèle logiciel FORMS d’Oracle par exemple est un client miléger qui ne gère que la présentation FORMS avec un tier « Métier + Données »
agrégé autour de la base de données Oracle avec ses procédures stockées. Du faux 3tier diront certains.
A l’inverse, un modèle Web, avec le client léger qu’est le navigateur, rapatrie la
totalité de la présentation dans les
serveurs. Du vrai 3-tier pour les puristes.
Front office et back office
Le front office est l’informatique en relation
Il est important de noter que l’apparition avec le client. Le back office est
du Web autour de 1995 a imposé le client l’informatique de production des biens ou
léger. Il s’est en effet avéré difficile de des services. Le back office a longtemps
gérer du code de présentation sur le poste constitué le cœur de l’informatique de
client,
même
par
téléchargement gestion. La GRC* (ou CRM) a fait émerger
le front office.
automatique. Il est important de noter le Du point de vue de l’architecture applicative,
relatif échec des applets Java sur le poste cette distinction n’est pas très structurante.
client, au moins sur Internet du fait de la Les applications de ces deux compartiments
faible bande passante. Il y a donc eu une (et du middle-office que certains identifient
conjonction d’intérêts à un moment entre les deux) ne se différencient pas
significativement par leur architecture
donné : le modèle Web exigeait un client applicative (voir 3.7 - ).
léger et le modèle n-tier avait besoin d’une
« application phare ». D’où l’apparition du serveur d’applications Web.
Cette description historique montre que les arguments d’architecture applicative ne
sont pas forcément primordiaux et en tout cas mobilisés au service des stratégies
économiques des acteurs.
4.4 - AVANTAGES ET INCONVENIENTS DE L’APPROCHE N-TIER
Il importe de revisiter à froid les vrais avantages architecturaux des architectures ntier 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 cidessous est de préciser leurs limites respectives.
Deux frontières se présentent : celle qui sépare infrastructure et applications, et celle qui
sépare une application d’une autre.
Application
Application
Application
Infrastructure
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 La notion de bonne
« bonnes pratiques » (voir encadré). Il est recommandé pratique : à un instant
par nombre d’analystes d’identifier et de gérer donné, un consensus se
l’infrastructure informatique comme un projet en tant dégage parmi les experts
que tel, avec son cycle de vie, relativement indépendant d’un secteur selon lequel tel
problème est mieux résolu
de celui des applications, même si l’infrastructure est à avec telle solution. En
leur service.
informatique, ces bonnes
Au fil du temps, et à mesure que les technologies se
standardisent et deviennent des « commodités », elles
« tombent » dans l’infrastructure.
L’infrastructure contient de manière consensuelle les
éléments suivants :
pratiques se dégagent en
général au niveau
international, souvent de
manière horizontale, mais
parfois dans un
environnement sectoriel.
•
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 Couplage applicatif : on dit que le
communication
entre
applications
est couplage entre deux éléments est fort
si une évolution de l’un a de fortes
asynchrone, faiblement couplée, et à gros gain.
Du point de vue de l’organisation qui la met en
œuvre, une application est ce qui rend un
service bien défini à un groupe d’utilisateurs
bien identifié.
Selon le point de vue de l’observateur, les deux
problématiques, technique et organisationnelle,
ne vont pas toujours coïncider,. Une adaptation
au cas pas cas sera effectuée.
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.
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.
Composants
Composants
Framework
Serveur Applicatif
Il y a un seul framework pour un projet, au service de tous les composants
applicatifs.
Techniquement, les frameworks aident à répondre aux questions suivantes :
- 73 -
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 Grosse base sur petits serveurs : mythe ou
dominants
(Oracle,
IBM, réalité ?
Il faut envisager avec prudence les
Microsoft,…).
déclarations régulières de différents acteurs
•
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.
annonçant que la base de données distribuée
va enfin marcher. Ces déclarations sont
motivées presque exclusivement par des
considérations économiques : qui profite des
marges financières liées à ces achats ?
Actuellement, l’essentiel va chez le trio des
vendeurs de gros SMP UNIX (et chez les
vendeurs de bases de données). Il serait plus
avantageux pour certains acteurs que le
matériel associé puisse être des serveurs
Intel à coût réduit. D’où la vogue médiatique
de bases distribuées sur des clusters Linux
ou Windows.
Le modèle de la base de données
unique centralisée est simple et efficace. L’existence de grosses machines SMP*
UNIX permet à ce modèle de suivre la demande de croissance même pour les
plus grosses applications comme amazon.com ou les gros sites SAP.
- 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
Collectif
Opérationnel
Systèmes
d'Information
de
Production
Systèmes
d'Information
Décisionnels
Aide à la
Décision
Alimente
Données
Externes
Individuel
Il est à noter que les SID sont alimentés par les données de production et
éventuellement par des données externes (données concernant la concurrence,
données de prospection, ...).
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
infocentre
à
Valeur Ajoutée
Contrôle
Opérationnel
SIAD/EIS
DW
Data Warehouse
Datamart
ID
Individuel
- 79 -
Décision
Opérationnel
Batch
Processing
Aide à la
IP
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
Périodique
Décideur
Expert
Individuel
5.2.6 - Flux
- 80 -
Décision
Analyste
Aide à la
Opérationnel
Occasionnel
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
Les Flux Relatifs aux Données
Système
d'Information
de Production
PUSH
Application
Application
P1
Application
P1
Application
P1
Application
P1
Application
P1
Pn
PULL
ALIMENTATION
Identification
Extraction
Transformation
Transport
Intégration
Système
d'Information
Décisionnel
Data
Warehouse
Application
Application
P1
Application
P1
Application
P1
Application
P1
Datamart
P1
SIAD
EIS
Data Mining
SYNCHRONISATION
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.
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.
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.
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 :
Application basée Services Web
Décou
verte
UDDI
Contrat tpaML...
Transaction
WS-Tran, BTP...
Coordination
Workflow
BPEL4WS (WSFL+
XLANG), BPML...
WS-Coord, WSCI
Description: WSDL
Enveloppe
SOAP, XP, ebXML TR&P …
Transport
HTTP, SMTP, JMS
Elle peut paraître complexe. Il convient de retenir que seulement les standards
soulignés, SOAP, WSDL et parfois UDDI sont indispensables. Les autres standards
des couches supérieures sont dans un état de flux, et non encore stabilisés.
5.3.2 - Application à court terme
Les Services Web ne sont qu’une technologie de plus. A quoi vont-ils servir ? Il
existe un consensus assez large selon lequel l’application phare dans les 2 ans à
venir est l’intégration applicative à l’intérieur de l’entreprise (décrit plus en
détail en 5.4 - ). Sur ce point, une demande forte de technologie standard et
abordable existe. Par contre les niveaux de sécurité et de robustesse actuels
rendent pour le moment difficile leur adoption.
5.3.3 - Une architecture orienté services ?
Les visionnaires des Services Web prédisent un avenir où les applications seront
composées à partir de services disponibles sur Internet. Les critiques insistent en
particulier sur le fait que l’aspect découverte dynamique lié à UDDI est
incompatible avec la nécessité de stabilité et de confiance liée à toute relation
entre entités. Sans même envisager cet aspect, il reste fort à faire en matière de
standards, de sécurité et de facilité de déploiement avant de voir un tel modèle se
déployer.
5.3.4 - Un coup d’œil sur l’actualité des Services Web
- 84 -
PROJET
Xmethods maintient un répertoire des Web Services: www.xmethods.net. 250
services sont répertoriés en mi-Octobre 2002. La moitié est accessible en mode
RPC*, l’autre moitié en mode document XML.
Les technologies sous-jacentes :
•
•
•
•
•
50% en .NET
25% en Apache SOAP, SOAPlite, SOAPx4, Axis …
10% en Delphi,
5 % en J2EE (IBM, BEA, Oracle)
10% en « autres technologies »
5.4 - L’INTEROPERABILITE APPLICATIVE
L’orchestration des dialogues entre applications est elle-même une application,
même si elle est rarement considérée comme telle de nos jours sur le terrain et est un
point structurant dans la problématique associée aux architectures applicatives.
Comment communiquer entre applications ?
La question se pose de manière assez fondamentalement différente selon qu’on se
place à l’intérieur d’une entité organisationnelle ou entre plusieurs entités. Par entité,
on entend une organisation à l’intérieur de la quelle une autorité légitime peut
imposer un modèle de communication applicative. De ce point de vue, certains
grands ministères sont constitués de plusieurs entités.
5.4.1 - Interopérabilité à l’intérieur d’une entité
Pourquoi un « système de communication » est-il nécessaire ? Ne peut-on se
contenter de standardiser des langages de description de données et des protocoles de
communication ? Non, essentiellement parce que l’on reconstitue alors
systématiquement un modèle de type spaghetti, avec des communications point à
point. Il est connu que le coût de possession de ce système augmente comme le carré
du nombre d’applications. Il est admis depuis une dizaine d’années qu’il faut se
ramener à un problème dont le coût est proportionnel au nombre d’applications en
jeu. C’est le modèle dit moyeu-et-rayons (hub & spoke), où un médiateur central
route tous les échanges.
Les technologies modernes, que ce soit XML ou SOAP, ne garantissent en rien
contre la prolifération des spaghettis. Rien de plus simple que de faire un plat de
spaghettis avec des schémas XML et des transformations XSLT par exemple.
Le moyeu central est un « serveur d’intégration » équipé d’une part d’adaptateurs
pour interfacer les applications et d’autre part d’un moteur pour router les flux. Le
cas échéant, ce moyeu peut être animé par un moteur de workflow d’entreprise ou
Business Process Manager (BPM*).
La standardisation de ce moyeu est relativement prématurée. Elle passe par
l’émergence d’un standard pour les langages de workflow. La récente initiative
d’IBM et Microsoft autour de BPEL4WS est intéressante à cet égard.
- 85 -
PROJET
Seule est donc réaliste dans le court terme la standardisation de la liaison moyeu
rayons. Le candidat le plus raisonnable est les Services Web (SOAP + WSDL). Dans
ce modèle, chaque application exporte une interface « Services Web » et le BPM
orchestre ces services :
Application
J2EE
Application
ERP
BPM basé
Services Web
Application
.NET
Application
CRM
L
e
un déploiement pratique de ce modèle exige que les propriétés suivantes soient
disponibles :
•
Asynchronisme : en effet, l’EAI a montré qu’un modèle asynchrone est
préférable, avec une sémantique bien définie (queues de messages et
« publish and subscribe »)
•
Fiabilité des échanges : une sémantique garantie de type une-fois-et-une-seule
est nécessaire pour toute application
•
Standard : il ne doit pas y avoir de dépendance avec un produit particulier à
déployer au bout de chaque rayon.
Malheureusement, en cette fin 2002, aucune technologie ne satisfait complètement
ces 3 critères :
•
SOAP sur HTTP est un standard, mais ni asynchrone au sens ci-dessus, ni
vraiment fiable du fait de HTTP ;
•
SOAP sur JMS est asynchrone et fiable mais non standard. En effet JMS est
une API vers les MOMs*, mais il n’y pas de protocole sous jacent
standardisé.
Il faut donc pour le moment utiliser des produits non standards en attendant que
l’industrie se mette d’accord sur la technologie d’avenir.
On parle souvent alors d’IAI, comme Integration d’Applications Internet.
Une approche réaliste possible à court terme, qui permet de se placer en position de
profiter de la baisse des coûts logiciels liée à l’émergence des Services Web :
• choix d’un MOM avec interface JMS ou MSMQ* ;
- 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
API
Atomicité Consistance Isolation Durabilité : les 4 propriétés canoniques d’une
transaction.
Le serveur http en logiciel libre le plus populaire sur le marché. Par extension, un
ensemble de logiciel libres gravitant autour de ce serveur Web et la communauté de
programmeurs qui s’y rattache. Voir www.apache.org.
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
Business Process manager : gestionnaire informatisé de processus d’entreprise
Apache
BPM
CCI
Business Process Langage for Web Services : proposition IBM Microsoft de langage de
workflow pour les Services Web
Cadre Commun d’Interopérabilité de l’ATICA
CORBA
Common Object Request Broker Architecture : architecture d composants de l’OMG
CRM
Customer Relationship Management : voir GRC.
Cube
CVS
Matérialisation d’une base de données dédiée au décisionnel, stockant les données sous
la forme d’un tableau multidimensionnel
Gestionnaire de source en logiciel libre
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.
"Entrepôt de données". Le Data Warehouse est une base de données dédiée pour
l'informatique décisionnelle dont les données sont intégrées, orientées sujet, non
volatiles et historisées.
Distributed Concurrent Environment : modèle distribué développé par l’OSF
(maintenant OpenGroup) dans les années 90
Distributed Component Object Model: protocole de communication applicatif de
Microsoft DNA
Fournisseur d’Accès Internet
BPEL4WS
Data Warehouse
DCE
DCOM
FAI
GRC
ICA
Gestion de la Relation Client : partie du système informatique qui permet au personnel
de l’entité de gérer les interactions avec les clients, , ou aux clients eux-même
d’interagir en self-service avec le système.
Independent Computing Architecture : protocole de présentation du client ultra léger de
Citrix
- 88 -
PROJET
IETF
IIOP
J2EE
JCA
Internet Engineering Task Force : organisme de standardisation de l’Internet (les
célèbres RFCs)
Internet Inter ORB Protocol : protocole de communication entre ORBs et entre serveurs
J2EE hétérogènes
Java 2 Enterprise Edition : le modèle de composants d’entreprise (comprendre
transactionnel) avec Java
Java Connector Architecture : cadre standard de connexion entre un serveur J2EE et des
applications patrimoniales de type mainframe ou PGIs
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
LDAP
Linux Apache MySQL Perl : un ensemble de logiciels libres complémentaires pour un
site Web
Light Directory Access Protocol : le standard d’accès aux répertoires de noms
LSB
Linux Standard Base : tentative de standardisation des APIs Linux
MOM
Message Oriented Middleware :interstitiel de communication par message (Ex . :
MQseries
Massively Parallel Processor : modèle de machine en grappe avec un réseau de
communication très rapide et propriétaire
Produit et protocole MOM de Microsoft
MPP
MSMQ
multidimensionnel
multithread
NAS
NUMA
Technique d'organisation des données qui consiste à caractériser les données
numériques (indicateurs) par des attributs qualitatifs homogènes (dimensions) pour
exprimer les indicateurs dans un système de coordonnées construits à partir des
dimensions.
Modèle de multiprogrammation à l’intérieur de l’espace d’un processus d’OS
Network Attached Storage: système de partage de données à travers un réseau et via des
protocoles d’accès fichiers comme NFS ou CIFS
Non Uniform Memory Access : modèle de multiprocesseur où les temps d’accès
mémoire sont différentiés selon la distance CPU - Mémoire
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
- 89 -
PROJET
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 soussystè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
- 90 -