Choix d'une architecture trois-tiers
L'objectif premier d'un système d'information quel qu'il soit est de permettre à plusieurs utilisateurs d'accéder aux mêmes informations. Pour cela il faut donc regrouper les informations utilisées par l'entreprise. En terme technique, cela se traduit par la centralisation des données au sein d'une base de données. L'évolution des systèmes d'information s'est donc basée sur une meilleure subdivision entre les tâches à réaliser pour permettre l'exploitation de ces données par les utilisateurs finaux. Ceci permet de structurer plus efficacement les informations ce qui entraîne à la fois une meilleure organisation de l'entreprise et une meilleure efficacité technique. Cette subdivision a été facilitée par l'avènement des technologies orientées objets qui s'appliquent aussi bien au modèle client-serveur qu'au modèle Internet. Ces technologies permettent une séparation entre les différents composants du système. Il devient alors possible de réaliser de nouvelles architectures permettant la mise à disposition des informations sous différentes formes tout en diminuant les temps de développement. Ces technologies permettent également de faire collaborer une grande diversité de systèmes. On parle alors d'architecture distribuée. Il est ainsi possible de présenter des données en provenance d'un mainframe mélangées à des données en provenance d'un SGBDR, le tout étant affiché dans un browser sur la même page HTML.
Trois tâches importantes
Tout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage des données, la logique applicative et la présentation. Ces trois parties sont indépendantes les unes des autres: on peut ainsi vouloir modifier la présentation sans modifier la logique applicative. La conception de chaque partie doit également être indépendante, toutefois la conception de la couche la plus basse est utilisée dans la couche d'au dessus. Ainsi la conception de la logique applicative se base sur le modèle de données, alors que la conception de la présentation dépend de la logique applicative.
Stockage et accès aux données
Le système de stockage des données a pour but de conserver une quantité plus ou moins importantes de données de façon structurée. On peut utiliser pour cette partie des systèmes très variés qui peuvent être des systèmes de fichiers, des mainframes, des systèmes de bases de données relationnelles, etc... Le point commun entre toutes ces systèmes est qu'il permettent le partage des données qu'ils contiennent via un réseau. La méthode d'accès à ces données dépendra du type d'organisation de ces données. Dans le cas d'une base de données relationnelle, l'accès peut se faire par des API qui dépendent du langage et de l'environnement. Ainsi en JAVA l'accès se fait via JDBC, alors qu'en C++ il se fera à l'aide d'ODBC. Quel que soit l'API, le langage SQL est utilisé.
Logique applicative
La logique applicative est la réalisation informatique du mode de fonctionnement de l'entreprise. Cette logique constitue les traitements nécessaires sur l'information afin de la rendre exploitable par chaque utilisateur. Les utilisateurs peuvent avoir des besoins très variés et évolutifs. Il devient alors nécessaire de permettre l'évolution du système sans pour autant devoir tout reconstruire. Cette partie utilise les données pour les présenter de façon exploitable par l'utilisateur. Il convient donc de bien identifier les besoins des utilisateurs afin de réaliser une logique applicative utile tout en structurant les données utilisées.
Présentation
La présentation est la partie la plus immédiatement visible pour l'utilisateur. Elle a donc une importance primordiale pour rendre attrayante l'utilisation de l'informatique. Son évolution a été très importante depuis les débuts de l'informatique. Depuis les terminaux en mode texte connectés à des mainframes jusqu'au HTML de nos jours en passant par les applications graphiques développées en client serveur, il y a eu beaucoup de chemin parcouru. Différents types d'interfaces demeurent intéressantes. En effet l'ergonomie d'un site Intranet HTML n'est pas forcément idéal pour tous les types d'applications. Il peut être intéressant de proposer plusieurs types d'interface pour une seule logique applicative. Par exemple une entreprise disposant d'un site de commerce électronique peut proposer un accès à la liste de ses produits sur Internet en HTML mais disposer d'une interface d'administration réalisée à l'aide d'une applet graphique.
Architecture client-serveur
Les architectures client-serveur constituent une étape importante dans l'évolution des systèmes d'informations. Ce type d'architecture est constitué uniquement de deux parties: un client qui gère la présentation et la logique applicative, un serveur qui stocke les données de façon cohérente et gère éventuellement une partie de la logique applicative. L'interface entre ces deux parties est classiquement le langage SQL (dans sa version normalisé ou dans une version propriétaire). Dans ce type d'architecture on constate une certaine indépendance du client par rapport au serveur. La programmation du client peut s'effectuer sans se préoccuper de la mise en place de la base de données. En particulier, les questions concernant l'administration des données ne concerneront pas le développeur du client (dimensionnement des disques, répartition des données sur le système, optimisation des accès aux données, sauvegarde des données,...). Un des objectifs des architectures multi-tiers sera de généraliser ce type de fractionnement en éléments logiciels indépendants les uns des autres. La qualité de ce type d'architecture est basé sur deux technologies éprouvées: la notion de base de données relationnelle et le langage SQL. Toutefois on peut également constater deux inconvénients à cette technologie: elle possède une sécurité limitée et surtout son déploiement demeure long et laborieux.
Avantage: technologies éprouvées
Le modèle relationnel a été introduit par E. Codd en 1970. Il s'appuie sur des considérations théoriques formulées sous la forme de 12 règles formant le cahier des charges initial. Ce modèle est basé sur la notion de relation. Une relation est un ensemble de n-uplet (n est fixe) qui correspondent chacun à une propriété de l'objet à décrire. Ce modèle permet la gestion précise de contraintes d'intégrité qui garantissent la cohérence des données. Les systèmes de gestion de base de données relationnel (SGBDR) sont interfacés à l'aide d'un langage unique: le SQL (Structured Query Language). Ce langage permet d'effectuer l'ensemble des opérations nécessaires sur la base de données. Ce langage permet également la gestion de transaction. Une transaction est définie par quatre propriétés essentielles: Atomicité, Cohérence, Isolation et Durabilité (ACID). Ces propriétés garantissent l'intégrité des données dans un environnement multi-utilisateurs. L'Atomicité permet à la transaction d'avoir un comportement indivisible; soit toutes les modifications sur les données effectuées dans la transaction sont effectives, soit aucune n'est réalisée. On comprend l'intérêt de ce concept dans l'exemple simple d'une transaction débitant un compte A et créditant un autre compte B : il est clair que la transaction n'a de sens que si les deux opérations sont menées à leur terme; L'atomicité de la transaction garantit que la base de donnée passera d'un état cohérent à un autre état cohérent. La Cohérence des données de la base est donc permanente. L'Isolation des transactions signifie que les modifications effectuées au cours d'une transaction ne sont visibles que par l'utilisateur qui effectue cette transaction. Au cours de la transaction, l'utilisateur pourra voir des modifications en cours qui rendent la base apparemment incohérente, mais ces modifications ne sont pas visibles par les autres et ne le seront qu'à la fin de la transaction si celle-ci est correcte (elle ne rend pas la base incohérente). La Durabilité garanti la stabilité de l'effet d'une transaction dans le temps, même en cas de problèmes graves tel que la perte d'un disque. L'ensemble de ces notions sont à la base des systèmes d'information actuels. Les technologies supportant ces notions (en particulier les SGBDR) forment l'aboutissement des recherches des 30 dernières années. Des systèmes comme Oracle offrent désormais des performances intéressantes y compris sur de grosses bases de données. Ces performances ont été obtenues sans faire de compromis sur les concepts théoriques sur lesquels ils se basent (modèle relationnel). Ces systèmes servent donc tout naturellement de base aux futurs systèmes d'information utilisant les nouvelles technologies Internet.
Inconvénients
L'architecture client-serveur possède toutefois des inconvénients. Ce sont ces inconvénients qui poussent les entreprises à utiliser d'autres technologies. Les deux inconvénients principaux sont la difficulté à gérer correctement les questions de sécurité et le coût du déploiement. La sécurité d'un système en architecture client-serveur est gérée au niveau du SGBDR. Celui-ci contrôle l'accès aux données en attribuant des autorisations d'accès aux différents utilisateurs du système. Le problème vient du fait que cette attribution de droit ne peut pas tenir compte des spécificités du logiciel réalisé. Pour pouvoir gérer les droits d'accès de cette façon il faut accorder à chaque utilisateur des droits sur un grand nombre de tables, ce qui devient vite laborieux. En pratique il est souvent plus rapide de ne créer qu'un utilisateur sur le SGBDR avec lequel tous les utilisateurs se connectent. Cette approche ne permet aucune gestion de la sécurité. Il suffit de connaître le login et le mot de passe d'accès à la base pour accéder à l'ensemble des données sans aucune restriction. L'autre problème est souvent considéré comme beaucoup plus important par les entreprises car il est beaucoup plus visible. Il s'agit des durées et coûts de déploiement des logiciels. En effet un logiciel classique, développé en architecture client-serveur, nécessite une installation et une éventuelle configuration sur chaque poste utilisateur. Le déplacement d'un technicien coûte déjà très cher aux entreprises. Mais ce qui reste le plus laborieux est la nécessité de mettre à jour régulièrement le logiciel. Dans une architecture client-serveur, chaque mise à jour du logiciel nécessite un nouveau déploiement accompagné de nombreux coûts.
Architecture trois-tiers
Le principe d'une architecture trois-tiers est relativement simple: il consiste à séparer la réalisation des trois parties vues précédemment (stockage des données, logique applicative, présentation). Nous avons déjà pu entrevoir la possibilité de séparer la conception de ces trois subdivisions, ici il s'agit de séparer leur implantation. Tout comme dans le client-serveur cette séparation signifie qu'il est possible de déployer chaque partie sur un serveur indépendant, toutefois cela n'est pas obligatoire. La mise en place de ce type d'architecture permet dans tous les cas une plus grande évolutivité du système. Il est ainsi possible de commencer par déployer les deux serveurs sur la même machine, puis de déplacer le serveur applicatif sur une autre machine lorsque la charge devient excessive. Les éléments permettant la réalisation classique d'un système en architecture trois tiers sont les suivants:
système de base de donnée relationnel (SGBDR) pour le stockage des données
serveur applicatif pour la logique applicative
navigateur web pour la présentation Il est important de remarquer que l'essentiel du travail de développement sera implanté au niveau du serveur applicatif. Le SGBDR nécessitera un travail d'administration surtout dans le cas d'une quantité de données importante. Le travail de conception de la base de donnée sera la pierre angulaire du système. En effet l'ensemble du développement s'appuiera sur cette conception. Le navigateur web nécessitera la programmation de code spécifique permettant de gérer l'affichage par ce navigateur. Ce code sera placé sur le serveur applicatif pour permettre une mise à jour sans nécessiter de nouveaux déploiements.
Avantages de cette architecture
Cette architecture se développe actuellement au sein des entreprises grâce aux nombreux avantages qu'elle présente. Malgré la différence évidente entre une architecture trois tiers et un système client-serveur (l'apparition d'un serveur pour la logique applicative), le système reste basé sur les technologies éprouvées détaillées précédemment (aspect relationnel et transaction). La logique applicative est déplacée au niveau du serveur d'application mais reste programmée à l'aide des mêmes technologies liées aux bases de données relationnelles. En particulier l'utilisation du langage SQL reste jusqu'à présent la solution la plus intéressante au niveau de la qualité logicielle. Elle présente à la fois une grande fiabilité, une bonne disponibilité, une excellente évolutivité,... Toutefois il faut prendre en compte deux facteurs importants: d'une part le choix du SGBDR (ils n'ont pas tous les même qualités), d'autre part la qualité des programmes utilisant la base de données (aussi bien au niveau de la conception que de la programmation). L'avantage principal d'une architecture multi-tiers est la facilité de déploiement. L'application en elle même n'est déployée que sur la partie serveur (serveur applicatif et serveur de base de données). Le client ne nécessite qu'une installation et une configuration minime. En effet il suffit d'installer un navigateur web compatible avec l'appication pour que le client puisse accéder à l'application, ce navigateur étant par ailleurs souvent installé par défaut sur toutes les machines. Cette facilité de déploiement aura pour conséquence non seulement de réduire le coût de déploiement mais aussi de permettre une évolution régulière du système. Cette évolution ne nécessitera que la mise à jour de l'application sur le serveur applicatif. Ceci est très important car cette évolutivité est un des problèmes majeurs de l'informatique. Le troisième avantage est l'amélioration de la sécurité. Dans un système client-serveur tous les clients accédaient à la base de donnnées ce qui la rendait vulnérable. Avec une architecture multi-tiers l'accès à la base n'est effectué que par le serveur applicatif. Ce serveur est le seul à connaitre la façon de se connecter à cette base. Il ne partage aucune des informations permettant l'accès aux données, en particulier le login et le password de la base. Il est alors possible de gérer la sécurité au niveau de ce serveur applicatif, par exemple en maintenant la liste des utilisateurs avec leurs mots de passe ainsi que leurs droits d'accès aux fonctions du système. On peut même améliorer encore la sécurité par la mise en place d'une architecture réseau interdisant totalement l'accès au serveur de base de données pour les utilisateurs finaux. La mise en place de firewall correctement configuré permettra ceci. Dans le cas de la mise en place d'un workflow au sein de l'entreprise Kallisto, l'avantage le plus intéressant est sans aucun doute l'évolutivité du système. En effet les besoins actuels sont relativement vastes, toutefois la réalisation totale semble relativement longue et difficile à réaliser d'un seul coup. De plus des problèmes risquent de nécessiter une mise à jour répétée du système. Un autre aspect intéressant est la possibilité d'utiliser le système en Extranet, ce qui chez Kallisto permettra de faciliter la communication entre le siège social situé à Lyon et l'agence de Paris.
Architecture multi-tiers
Nous avons vu ce qu'était une architecture trois-tiers, une architecture multi-tiers va plus loin dans le découpage de l'application sur différents serveurs. Une architecture multi-tiers est également appelé architecture distribuée du fait de la distribution des traitements et des données sur différents serveurs. Le découpage de base du système reste toujours le même: une partie gestion de données, une partie gestion de la logique applicative et bien entendu le client assurant la présentation. Toutefois les deux parties développées coté serveur vont pouvoir être déployées chacune sur plusieurs serveurs. L'objectif général de ce type d'architecture est de permettre l'évolutivité du système sous plusieurs aspects: la quantité de données stockée, la disponibilité du serveur, le nombre d'utilisateurs,... Il faut également bien comprendre qu'un système conçu en architecture multi-tiers n'est pas forcément déployé sur plusieurs machines dès le départ. Toutefois son mode de programmation doit permettre de modifier le déploiement du système en cours d'exploitation par un administrateur. Le développeur doit donc rendre le système indépendant du serveur sur lequel il s'éxécute. Il existe deux types de répartition possibles dans une architecture distribuée. Il est possible de répartir les données et de répartir la logique applicative. Chacune de ces deux répartitions permet de résoudre des problèmes de natures différentes. Elles peuvent donc être mises en place soit séparément soit en parallèle sur le même système.
Répartition des données sur différents serveurs
Il s'agit d'utiliser plusieurs sources de données dans une même application. Chaque source possède sa propre structure de données. Chaque serveur de données peut être géré de façon très différente. Toutefois une interface de programmation commune à toutes les sources doit pouvoir exister. Il peut exister des relations entre les données des différents serveurs, il sera alors nécessaire de gérer des transactions distribuées entre des différents serveurs de données. Cette répartition de données correspond à la notion de base de données distribués. Les bases de données distribuées permettent de résoudre deux types de problèmes. La première est la performance du système: la répartition des données permet d'augmenter la disponibilité des données. Toutefois il est nécessaire de bien penser cette répartition afin de ne pas démultiplier le nombre de transactions distribuées nécessaires. Ceci aurrait pour effet de diminuer la performance plus que de l'augmenter. Le deuxième type de problèmes est la réutilisation des systèmes éxistants. En effet de nombreux systèmes informatiques stockent actuellement une grande quantité de données. Toutefois ces systèmes ne sont pas toujours bien coordonnés entre eux. Ceci risque d'entraîner des redondances dans les données et des incohérences entre plusieurs sources de données. L'objectif est donc de réutiliser ces systèmes dans une même application afin de restructurer le système d'information sans pour autant repartir de zéro (ce qui est non seulement un non sens mais est aussi impossible). Les systèmes réutilisés sont bien souvent hétéroclites (mainframe, SGBDR,...) et nécessitent d'être réunis en utilisant diverses technologies (moniteurs transactionnels, serveurs d'applications,...).
Répartition de la logique applicative
La répartition de la logique applicative permet de distribuer les traitements sur différentes machines. Cette distribution est facilitée par l'utilisation de la programmation orientée objet et plus particulièrement de ce qu'on appelle les composants. Un composant possède entre autre la caractèristique d'être accessible à travers le réseau. Un composant peut ainsi être instantié puis utilisé au travers du réseau. Il est également possible de trouver un serveur permettant l'utilisation d'un composant, ce qui permet une forte évolutivité ainsi qu'une résistance aux pannes importantes (le service sera toujours disponible sur un serveur même si une machine tombe en panne). La réalisation de ce type de répartition nécessite l'utilisation de technologies spécifiques. D'une part il faut permettre la communication entre les différents éléments de l'application (RMI), d'autre part le déploiement et l'évolution du sytème doivent pouvoir être assurés (JNDI + fichiers XML). Certaines technologies proposent une architecture cohérente pour la mise en place des différentes technologies intervenant sur un système distribué (EJB). Les buts recherchés lors de la mise en place de ce type d'architecture sont la performance, l'évolutivité, la maintenabilité...
Trois tâches importantes
Tout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage des données, la logique applicative et la présentation. Ces trois parties sont indépendantes les unes des autres: on peut ainsi vouloir modifier la présentation sans modifier la logique applicative. La conception de chaque partie doit également être indépendante, toutefois la conception de la couche la plus basse est utilisée dans la couche d'au dessus. Ainsi la conception de la logique applicative se base sur le modèle de données, alors que la conception de la présentation dépend de la logique applicative.
Stockage et accès aux données
Le système de stockage des données a pour but de conserver une quantité plus ou moins importantes de données de façon structurée. On peut utiliser pour cette partie des systèmes très variés qui peuvent être des systèmes de fichiers, des mainframes, des systèmes de bases de données relationnelles, etc... Le point commun entre toutes ces systèmes est qu'il permettent le partage des données qu'ils contiennent via un réseau. La méthode d'accès à ces données dépendra du type d'organisation de ces données. Dans le cas d'une base de données relationnelle, l'accès peut se faire par des API qui dépendent du langage et de l'environnement. Ainsi en JAVA l'accès se fait via JDBC, alors qu'en C++ il se fera à l'aide d'ODBC. Quel que soit l'API, le langage SQL est utilisé.
Logique applicative
La logique applicative est la réalisation informatique du mode de fonctionnement de l'entreprise. Cette logique constitue les traitements nécessaires sur l'information afin de la rendre exploitable par chaque utilisateur. Les utilisateurs peuvent avoir des besoins très variés et évolutifs. Il devient alors nécessaire de permettre l'évolution du système sans pour autant devoir tout reconstruire. Cette partie utilise les données pour les présenter de façon exploitable par l'utilisateur. Il convient donc de bien identifier les besoins des utilisateurs afin de réaliser une logique applicative utile tout en structurant les données utilisées.
Présentation
La présentation est la partie la plus immédiatement visible pour l'utilisateur. Elle a donc une importance primordiale pour rendre attrayante l'utilisation de l'informatique. Son évolution a été très importante depuis les débuts de l'informatique. Depuis les terminaux en mode texte connectés à des mainframes jusqu'au HTML de nos jours en passant par les applications graphiques développées en client serveur, il y a eu beaucoup de chemin parcouru. Différents types d'interfaces demeurent intéressantes. En effet l'ergonomie d'un site Intranet HTML n'est pas forcément idéal pour tous les types d'applications. Il peut être intéressant de proposer plusieurs types d'interface pour une seule logique applicative. Par exemple une entreprise disposant d'un site de commerce électronique peut proposer un accès à la liste de ses produits sur Internet en HTML mais disposer d'une interface d'administration réalisée à l'aide d'une applet graphique.
Architecture client-serveur
Les architectures client-serveur constituent une étape importante dans l'évolution des systèmes d'informations. Ce type d'architecture est constitué uniquement de deux parties: un client qui gère la présentation et la logique applicative, un serveur qui stocke les données de façon cohérente et gère éventuellement une partie de la logique applicative. L'interface entre ces deux parties est classiquement le langage SQL (dans sa version normalisé ou dans une version propriétaire). Dans ce type d'architecture on constate une certaine indépendance du client par rapport au serveur. La programmation du client peut s'effectuer sans se préoccuper de la mise en place de la base de données. En particulier, les questions concernant l'administration des données ne concerneront pas le développeur du client (dimensionnement des disques, répartition des données sur le système, optimisation des accès aux données, sauvegarde des données,...). Un des objectifs des architectures multi-tiers sera de généraliser ce type de fractionnement en éléments logiciels indépendants les uns des autres. La qualité de ce type d'architecture est basé sur deux technologies éprouvées: la notion de base de données relationnelle et le langage SQL. Toutefois on peut également constater deux inconvénients à cette technologie: elle possède une sécurité limitée et surtout son déploiement demeure long et laborieux.
Avantage: technologies éprouvées
Le modèle relationnel a été introduit par E. Codd en 1970. Il s'appuie sur des considérations théoriques formulées sous la forme de 12 règles formant le cahier des charges initial. Ce modèle est basé sur la notion de relation. Une relation est un ensemble de n-uplet (n est fixe) qui correspondent chacun à une propriété de l'objet à décrire. Ce modèle permet la gestion précise de contraintes d'intégrité qui garantissent la cohérence des données. Les systèmes de gestion de base de données relationnel (SGBDR) sont interfacés à l'aide d'un langage unique: le SQL (Structured Query Language). Ce langage permet d'effectuer l'ensemble des opérations nécessaires sur la base de données. Ce langage permet également la gestion de transaction. Une transaction est définie par quatre propriétés essentielles: Atomicité, Cohérence, Isolation et Durabilité (ACID). Ces propriétés garantissent l'intégrité des données dans un environnement multi-utilisateurs. L'Atomicité permet à la transaction d'avoir un comportement indivisible; soit toutes les modifications sur les données effectuées dans la transaction sont effectives, soit aucune n'est réalisée. On comprend l'intérêt de ce concept dans l'exemple simple d'une transaction débitant un compte A et créditant un autre compte B : il est clair que la transaction n'a de sens que si les deux opérations sont menées à leur terme; L'atomicité de la transaction garantit que la base de donnée passera d'un état cohérent à un autre état cohérent. La Cohérence des données de la base est donc permanente. L'Isolation des transactions signifie que les modifications effectuées au cours d'une transaction ne sont visibles que par l'utilisateur qui effectue cette transaction. Au cours de la transaction, l'utilisateur pourra voir des modifications en cours qui rendent la base apparemment incohérente, mais ces modifications ne sont pas visibles par les autres et ne le seront qu'à la fin de la transaction si celle-ci est correcte (elle ne rend pas la base incohérente). La Durabilité garanti la stabilité de l'effet d'une transaction dans le temps, même en cas de problèmes graves tel que la perte d'un disque. L'ensemble de ces notions sont à la base des systèmes d'information actuels. Les technologies supportant ces notions (en particulier les SGBDR) forment l'aboutissement des recherches des 30 dernières années. Des systèmes comme Oracle offrent désormais des performances intéressantes y compris sur de grosses bases de données. Ces performances ont été obtenues sans faire de compromis sur les concepts théoriques sur lesquels ils se basent (modèle relationnel). Ces systèmes servent donc tout naturellement de base aux futurs systèmes d'information utilisant les nouvelles technologies Internet.
Inconvénients
L'architecture client-serveur possède toutefois des inconvénients. Ce sont ces inconvénients qui poussent les entreprises à utiliser d'autres technologies. Les deux inconvénients principaux sont la difficulté à gérer correctement les questions de sécurité et le coût du déploiement. La sécurité d'un système en architecture client-serveur est gérée au niveau du SGBDR. Celui-ci contrôle l'accès aux données en attribuant des autorisations d'accès aux différents utilisateurs du système. Le problème vient du fait que cette attribution de droit ne peut pas tenir compte des spécificités du logiciel réalisé. Pour pouvoir gérer les droits d'accès de cette façon il faut accorder à chaque utilisateur des droits sur un grand nombre de tables, ce qui devient vite laborieux. En pratique il est souvent plus rapide de ne créer qu'un utilisateur sur le SGBDR avec lequel tous les utilisateurs se connectent. Cette approche ne permet aucune gestion de la sécurité. Il suffit de connaître le login et le mot de passe d'accès à la base pour accéder à l'ensemble des données sans aucune restriction. L'autre problème est souvent considéré comme beaucoup plus important par les entreprises car il est beaucoup plus visible. Il s'agit des durées et coûts de déploiement des logiciels. En effet un logiciel classique, développé en architecture client-serveur, nécessite une installation et une éventuelle configuration sur chaque poste utilisateur. Le déplacement d'un technicien coûte déjà très cher aux entreprises. Mais ce qui reste le plus laborieux est la nécessité de mettre à jour régulièrement le logiciel. Dans une architecture client-serveur, chaque mise à jour du logiciel nécessite un nouveau déploiement accompagné de nombreux coûts.
Architecture trois-tiers
Le principe d'une architecture trois-tiers est relativement simple: il consiste à séparer la réalisation des trois parties vues précédemment (stockage des données, logique applicative, présentation). Nous avons déjà pu entrevoir la possibilité de séparer la conception de ces trois subdivisions, ici il s'agit de séparer leur implantation. Tout comme dans le client-serveur cette séparation signifie qu'il est possible de déployer chaque partie sur un serveur indépendant, toutefois cela n'est pas obligatoire. La mise en place de ce type d'architecture permet dans tous les cas une plus grande évolutivité du système. Il est ainsi possible de commencer par déployer les deux serveurs sur la même machine, puis de déplacer le serveur applicatif sur une autre machine lorsque la charge devient excessive. Les éléments permettant la réalisation classique d'un système en architecture trois tiers sont les suivants:
système de base de donnée relationnel (SGBDR) pour le stockage des données
serveur applicatif pour la logique applicative
navigateur web pour la présentation Il est important de remarquer que l'essentiel du travail de développement sera implanté au niveau du serveur applicatif. Le SGBDR nécessitera un travail d'administration surtout dans le cas d'une quantité de données importante. Le travail de conception de la base de donnée sera la pierre angulaire du système. En effet l'ensemble du développement s'appuiera sur cette conception. Le navigateur web nécessitera la programmation de code spécifique permettant de gérer l'affichage par ce navigateur. Ce code sera placé sur le serveur applicatif pour permettre une mise à jour sans nécessiter de nouveaux déploiements.
Avantages de cette architecture
Cette architecture se développe actuellement au sein des entreprises grâce aux nombreux avantages qu'elle présente. Malgré la différence évidente entre une architecture trois tiers et un système client-serveur (l'apparition d'un serveur pour la logique applicative), le système reste basé sur les technologies éprouvées détaillées précédemment (aspect relationnel et transaction). La logique applicative est déplacée au niveau du serveur d'application mais reste programmée à l'aide des mêmes technologies liées aux bases de données relationnelles. En particulier l'utilisation du langage SQL reste jusqu'à présent la solution la plus intéressante au niveau de la qualité logicielle. Elle présente à la fois une grande fiabilité, une bonne disponibilité, une excellente évolutivité,... Toutefois il faut prendre en compte deux facteurs importants: d'une part le choix du SGBDR (ils n'ont pas tous les même qualités), d'autre part la qualité des programmes utilisant la base de données (aussi bien au niveau de la conception que de la programmation). L'avantage principal d'une architecture multi-tiers est la facilité de déploiement. L'application en elle même n'est déployée que sur la partie serveur (serveur applicatif et serveur de base de données). Le client ne nécessite qu'une installation et une configuration minime. En effet il suffit d'installer un navigateur web compatible avec l'appication pour que le client puisse accéder à l'application, ce navigateur étant par ailleurs souvent installé par défaut sur toutes les machines. Cette facilité de déploiement aura pour conséquence non seulement de réduire le coût de déploiement mais aussi de permettre une évolution régulière du système. Cette évolution ne nécessitera que la mise à jour de l'application sur le serveur applicatif. Ceci est très important car cette évolutivité est un des problèmes majeurs de l'informatique. Le troisième avantage est l'amélioration de la sécurité. Dans un système client-serveur tous les clients accédaient à la base de donnnées ce qui la rendait vulnérable. Avec une architecture multi-tiers l'accès à la base n'est effectué que par le serveur applicatif. Ce serveur est le seul à connaitre la façon de se connecter à cette base. Il ne partage aucune des informations permettant l'accès aux données, en particulier le login et le password de la base. Il est alors possible de gérer la sécurité au niveau de ce serveur applicatif, par exemple en maintenant la liste des utilisateurs avec leurs mots de passe ainsi que leurs droits d'accès aux fonctions du système. On peut même améliorer encore la sécurité par la mise en place d'une architecture réseau interdisant totalement l'accès au serveur de base de données pour les utilisateurs finaux. La mise en place de firewall correctement configuré permettra ceci. Dans le cas de la mise en place d'un workflow au sein de l'entreprise Kallisto, l'avantage le plus intéressant est sans aucun doute l'évolutivité du système. En effet les besoins actuels sont relativement vastes, toutefois la réalisation totale semble relativement longue et difficile à réaliser d'un seul coup. De plus des problèmes risquent de nécessiter une mise à jour répétée du système. Un autre aspect intéressant est la possibilité d'utiliser le système en Extranet, ce qui chez Kallisto permettra de faciliter la communication entre le siège social situé à Lyon et l'agence de Paris.
Architecture multi-tiers
Nous avons vu ce qu'était une architecture trois-tiers, une architecture multi-tiers va plus loin dans le découpage de l'application sur différents serveurs. Une architecture multi-tiers est également appelé architecture distribuée du fait de la distribution des traitements et des données sur différents serveurs. Le découpage de base du système reste toujours le même: une partie gestion de données, une partie gestion de la logique applicative et bien entendu le client assurant la présentation. Toutefois les deux parties développées coté serveur vont pouvoir être déployées chacune sur plusieurs serveurs. L'objectif général de ce type d'architecture est de permettre l'évolutivité du système sous plusieurs aspects: la quantité de données stockée, la disponibilité du serveur, le nombre d'utilisateurs,... Il faut également bien comprendre qu'un système conçu en architecture multi-tiers n'est pas forcément déployé sur plusieurs machines dès le départ. Toutefois son mode de programmation doit permettre de modifier le déploiement du système en cours d'exploitation par un administrateur. Le développeur doit donc rendre le système indépendant du serveur sur lequel il s'éxécute. Il existe deux types de répartition possibles dans une architecture distribuée. Il est possible de répartir les données et de répartir la logique applicative. Chacune de ces deux répartitions permet de résoudre des problèmes de natures différentes. Elles peuvent donc être mises en place soit séparément soit en parallèle sur le même système.
Répartition des données sur différents serveurs
Il s'agit d'utiliser plusieurs sources de données dans une même application. Chaque source possède sa propre structure de données. Chaque serveur de données peut être géré de façon très différente. Toutefois une interface de programmation commune à toutes les sources doit pouvoir exister. Il peut exister des relations entre les données des différents serveurs, il sera alors nécessaire de gérer des transactions distribuées entre des différents serveurs de données. Cette répartition de données correspond à la notion de base de données distribués. Les bases de données distribuées permettent de résoudre deux types de problèmes. La première est la performance du système: la répartition des données permet d'augmenter la disponibilité des données. Toutefois il est nécessaire de bien penser cette répartition afin de ne pas démultiplier le nombre de transactions distribuées nécessaires. Ceci aurrait pour effet de diminuer la performance plus que de l'augmenter. Le deuxième type de problèmes est la réutilisation des systèmes éxistants. En effet de nombreux systèmes informatiques stockent actuellement une grande quantité de données. Toutefois ces systèmes ne sont pas toujours bien coordonnés entre eux. Ceci risque d'entraîner des redondances dans les données et des incohérences entre plusieurs sources de données. L'objectif est donc de réutiliser ces systèmes dans une même application afin de restructurer le système d'information sans pour autant repartir de zéro (ce qui est non seulement un non sens mais est aussi impossible). Les systèmes réutilisés sont bien souvent hétéroclites (mainframe, SGBDR,...) et nécessitent d'être réunis en utilisant diverses technologies (moniteurs transactionnels, serveurs d'applications,...).
Répartition de la logique applicative
La répartition de la logique applicative permet de distribuer les traitements sur différentes machines. Cette distribution est facilitée par l'utilisation de la programmation orientée objet et plus particulièrement de ce qu'on appelle les composants. Un composant possède entre autre la caractèristique d'être accessible à travers le réseau. Un composant peut ainsi être instantié puis utilisé au travers du réseau. Il est également possible de trouver un serveur permettant l'utilisation d'un composant, ce qui permet une forte évolutivité ainsi qu'une résistance aux pannes importantes (le service sera toujours disponible sur un serveur même si une machine tombe en panne). La réalisation de ce type de répartition nécessite l'utilisation de technologies spécifiques. D'une part il faut permettre la communication entre les différents éléments de l'application (RMI), d'autre part le déploiement et l'évolution du sytème doivent pouvoir être assurés (JNDI + fichiers XML). Certaines technologies proposent une architecture cohérente pour la mise en place des différentes technologies intervenant sur un système distribué (EJB). Les buts recherchés lors de la mise en place de ce type d'architecture sont la performance, l'évolutivité, la maintenabilité...
posted by Hayadi Mouâad at
1:37 AM
0 Comments:
Enregistrer un commentaire
<< Home