Pour résoudre les inconvénients du modèle client/serveur, dépendance trop forte entre le client et le serveur, répartition des traitements sur le client, le modèle 3-tiers est proposé. Le premier tiers se charge de la présentation, le troisième tiers se charge de la persistance des données, tandis que le nouveau tiers, intermédiaire, est en charge du traitement des informations. Nous synthétisons sur la figure suivante (fig. 5.4) une représentation de ce nouveau modèle.
Lorsqu’il y a un serveur Web dans cette architecture, celle-ci peut aussi prendre le nom d’un modèle 4-tiers. Dans un souci de lisibilité, nous resterons sur la dénomination 3-tiers.
Les différentes couches du modèle jouent les rôles suivants :
– présentation (1-tiers) : le poste client devient donc un poste léger. Il a en charge la présentation des interfaces et le dialogue avec le serveur de traitement. Généralement, on utilise un navigateur Web ;
70 CHAPITRE 5. ARCHITECTURE D’ERP
Fig. 5.4 – Modèle 3-tiers
– traitement (2-tiers) : le serveur de traitement est en charge de deux activités. L’une correspond à la génération de l’interface utilisateur tandis que l’autre correspond au traitement des informations. Il existe donc un dialogue entre le serveur de traitement et le client, mais aussi entre le serveur de traitement et le serveur de données ;
– persistance (3-tiers) : le serveur de base de données assure principalement la gestion des données dans la base.
Nous détaillerons dans la prochaine section les caractéristiques de ces différentes couches (§ 5.4.1). L’avantage de ce type d’architecture est la relative indépendance des couches. Avec le modèle 2-tiers, une modification d’une couche pouvait engendrer des coûts très importants pour préserver la logique de communication entre les parties. Avec une architecture 3-tiers, seules les interfaces entre les différentes couches sont touchées par une modification. Un chan- gement du côté du serveur perturbera moins le bon fonctionnement du poste client.
5.4.1 Un exemple d’architecture n-tiers avec la technologie J2EE
Dans cette section, nous souhaitons illustrer une architecture n-tiers basée sur une techno- logie Java (J2EE). Le schéma suivant (fig. 5.5) présente l’organisation générale de ce type d’architecture. Il montre bien les effets sur l’architecture logique d’une évolution de l’architec- ture physique. Le fonctionnement repose sur des communications organisées entre des parties distribuées sur plusieurs machines et qui remplissent de concert les fonctions pour lesquelles elles sont programmées (saisie de données, édition d’interface, connecteur de base de données, connecteur d’application, ...).
Ce type d’architecture apporte les avantages suivants :
– indépendance de la plate-forme de déploiement : un des avantages de Java est la pos- sibilité d’installer une application sur des plates-formes systèmes différentes (Windows, Linux, Unix) sans avoir à modifier le code ;
– utilisation d’un poste léger côté client : ce type d’architecture envoie des pages Web vers le navigateur du client. Il n’y a plus d’application lourde réalisant des traitements ; – utilisation d’un cadre (framework) de conception : on utilise un « Modèle Vue Contrô-
leur » (MVC), un guide défini par des architectes comme une « bonne pratique » : – le modèle s’applique au serveur d’application. Il se charge des principaux traite-
Fig. 5.5 – Architecture logique d’un système basé sur J2EE
– la vue correspond à la production des interfaces. Un serveur de type JSP se charge de générer les pages Web qui vont être affichées sur le navigateur ;
– le contrôleur se charge de la vérification des données qui vont être transférées entre la vue et le modèle. Il s’agit d’un servlet sur l’exemple ci-dessus...
5.5
Synthèse
L’architecture de Système d’Information n’est pas un art facile. Elle doit évoluer suivant les exigences des consommateurs/utilisateurs, toujours croissantes, et puiser dans les nou- velles technologies qui imposent une cadence rapide d’innovation. L’exercice de l’art implique d’accepter des sauts technologiques, et de savoir les négocier, dans un climat de « tout com- municant ». Les mots clé de processus, de modèles, d’interopérabilité sont au cœur de la pratique actuelle de cet art et sont devenus des pièces maîtresses des tendances comme l’EAI, l’urbanisme, et les Web services. Toute expérience relative à cette architecture de Système d’Information, et donc en particulier d’ERP, doit tenir compte de ces sources de progrès sous peine d’obsolescence rapide.
En termes de démarche de conception, le principe de « componentisation » (David Sprott, 2000) est commun à beaucoup de disciplines d’ingénierie. Que ce soit des fabrications d’au- tomobiles, d’ordinateurs ou encore des téléphones portables, ils sont assemblés à partir d’un ensemble de composants, selon une approche modulaire, composants qui collaborent dans une
72 CHAPITRE 5. ARCHITECTURE D’ERP
architecture commune dite intégrée. Les solutions architecturales existent maintenant pour qu’il trouve une application dans le domaine qui nous intéresse. Kuldeep Kumar et Jos van Hillegersberg (2000) ont proposé de concevoir un ERP à base de composants afin de répondre aux problématiques de variété et de complexité des fonctionnalités. Comme le dit David Sprott, cela doit se faire avec le souci d’améliorer les quatre critères suivants :
– intégration, – adaptabilité,
– facilité de mise à jour, – facilité de mise en œuvre.
Parmi ces quatre critères, celui sur la facilité de mise en œuvre ramène à la relation entre le point de vue fonctionnel et les autres points de vue de l’architecture. Et cela ne fait que renforcer l’idée d’une meilleure utilisation du modèle à tous les niveaux.
Si toutes les technologies sont présentes pour répondre à la majorité des exigences du client, l’architecte doit faire des compromis entre pas de communication et trop de communication. Parmi ces compromis1, nous citerons :
– cohérence vs. performance : la gestion de la cohérence est une partie sensible d’un SI. L’information est saisie une seule fois et elle est utilisée par plusieurs modules. Il est nécessaire de s’assurer que cette information soit viable. Pour cela, nous pouvons mettre en place une surveillance par des règles permettant de tester si l’information est valide. Il est clair que plus il y aura de règles, plus la performance du système sera dégradée ; – sécurité vs. ouverture : la mise en place d’une sécurité est quelque part contradictoire
avec la volonté d’ouverture du système. Afin de faire ces ouvertures avec un maximum de garantie, il est nécessaire d’engager plus de moyens pour assurer les contrôles d’accès ; – sécurité vs. coûts : la mise en place d’une sécurité, pour authentifier les utilisateurs,
crypter les flux d’informations, a des coûts d’administration et de réseaux.