Technologie client-serveur. Diverses solutions architecturales utilisées lors de la mise en œuvre de bases de données multi-utilisateurs. bref aperçu du subd

Systèmes client-serveur. Partie 2

Architecture client-serveur : définition, prérequis d'application, avantages et inconvénients

Qu’est-ce que l’architecture client-serveur ? Options de création d'applications

Alors parlons enfin de

Qu'est-ce qu'un client-serveur exactement ? . À proprement parler, il convient de distinguer la technologie client-serveur au sens large, qui peut être utilisée dans n'importe quel domaine. systèmes informatiques de l'architecture client-serveur elle-même par rapport à demandes d'informations en général et les systèmes automatisés de gestion d'entreprise en particulier.

D'après le dictionnaire en ligne termes informatiques, client-serveur est une sorte système distribué, dans lequel se trouve un serveur qui répond aux demandes des clients, et le serveur et le client communiquent entre eux en utilisant l'un ou l'autre protocole.

Un client est un programme qui utilise des ressources, et un serveur (en anglais, un serviteur) est un programme qui répond aux demandes des clients pour un certain type de ressource. Une définition aussi large inclut presque toutes les technologies logicielles impliquant plusieurs programmes, dont les fonctions sont réparties de manière asymétrique. En conséquence, ils parlent de la technologie CS en relation avec les systèmes d'exploitation, locaux et réseaux mondiaux etc.

Une définition aussi large crée une certaine confusion. Ainsi, un système de serveur de fichiers utilise également la technologie client-serveur, mais du point de vue de l'architecture du programme d'application, ce qui est important est le type de ressources que le serveur fournit aux clients.

Le concept d'architecture client-serveur dans les systèmes de gestion d'entreprise est associé à la division de tout programme d'application en trois composants ou couches principaux. Ces trois composantes sont

composant de présentation (visualisation) des données ;

composant de logique appliquée ;

composant de gestion de base de données.

En effet, tout programme informatisant l'exécution d'une tâche applicative particulière doit échanger des informations avec l'utilisateur, effectuer le traitement proprement dit de ces informations dans le cadre de l'automatisation d'un processus métier particulier et, enfin, stocker les données utilisées dans le programme. sur l'un ou l'autre support permanent.

Pour les applications locales qui s'exécutent entièrement sur un PC (par exemple Word ou Excel), tous ces composants sont rassemblés et ne peuvent pas être distribués entre eux. divers ordinateurs. Un tel programme est monolithique et n'utilise pour son exécution que les ressources de l'ordinateur sur lequel il est exécuté.

Dans les applications de serveur de fichiers, certains composants de stockage sont transférés vers le serveur de fichiers. Cependant, toutes les manipulations avec les structures de données sont effectuées sur la machine client et le code programme utilisateur fonctionne également uniquement sur lui.

Le critère permettant de classer programmes d'applicationÀ architecture client-serveur est qu'au moins un de ses trois composants fonctionne entièrement sur un autre ordinateur, et l'interaction entre les composants sur différents ordinateurs effectué via un environnement réseau particulier en transmettant des requêtes pour recevoir une ressource particulière.

L’architecture client-serveur étant un cas particulier de la technologie client-serveur, elle comporte nécessairement un client et un serveur. En conséquence, les côtés client et serveur de l'application sont distingués. Côté client l’application fonctionne sur le lieu de travail de l’utilisateur, qui dans la grande majorité des cas est joué par Ordinateur personnel. Du côté serveur fonctionne sur un complexe spécialisé qui comprend du matériel puissant, l'ensemble requis de logiciels standard, un système de gestion de base de données et les structures de données elles-mêmes.

L'interaction entre les parties client et serveur de l'application s'effectue via un réseau - local ou global. Parallèlement, du point de vue du client et du serveur, l'interaction s'effectue de manière transparente, respectivement composant réseau comprend ici la totalité des éléments nécessaires équipement de réseau, trousse technologies logicielles, assurant le transfert de données entre les nœuds du réseau, ainsi que le ou les protocoles réels d'échange des requêtes et les résultats de leur exécution.

Le composant de visualisation des tâches d'application fournit des informations saisies par l'utilisateur à l'aide de certains moyens, ainsi que l'affichage d'informations à l'écran et à l'impression. Le composant de visualisation de l'architecture client-serveur est toujours exécuté sur le poste de travail de l'utilisateur (puisqu'il doit observer les résultats du programme).

Le composant logique appliqué résout en fait l'un ou l'autre problème lié au traitement des données dans l'un ou l'autre Domaine. Ce composant peut être réparti entre le client et le serveur de différentes manières selon le modèle utilisé.

Le composant de stockage de base de données effectue des opérations physiques liées au stockage des données, à la lecture des informations de la base de données et à l'écriture dans celle-ci. Dans une architecture client-serveur, ce composant s'exécute toujours sur le serveur.

En termes de quantité Composants les systèmes client-serveur sont divisés en deux et trois niveaux

. À deux niveaux les systèmes se composent uniquement d’un client et d’un serveur. DANS à trois niveaux Entre le client utilisateur et le serveur qui stocke et traite la base de données, une troisième couche intermédiaire apparaît, qui est un serveur pour l'utilisateur et un client pour le système de gestion de base de données. Cette architecture permet une répartition plus flexible des fonctions système et de la charge entre les composants du complexe matériel et logiciel, et peut également réduire les besoins en ressources pour les postes de travail des utilisateurs. Frais requis derrière ça, il y a ça systèmes similaires beaucoup plus difficiles à développer, à mettre en œuvre et à exploiter et nécessitent des coûts importants et un personnel hautement qualifié.

La troisième partie examine un exemple de structure à trois niveaux Serveur Baïkonour.

Dans l'architecture client-serveur, il existe plusieurs modèles d'application, en fonction de la répartition des composants applicatifs entre les parties client et serveur. Historiquement, le tout premier a été développé modèle de serveur accès à distance aux données. Dans ce modèle, la partie serveur stocke uniquement les données, et toute la logique applicative est implémentée par la partie client. Dans ce cas, le client enverra des requêtes au serveur pour obtenir des données, et le serveur renverra certains échantillons au client. Le moyen de communication le plus courant entre le client et le serveur dans ce cas est SQL (langage de requête structuré) - un langage standard non procédural axé sur le traitement des données.

Dans le modèle de serveur d'accès aux données distant, aucune partie applicative du système n'est exécutée côté serveur, ce qui peut entraîner une sous-charge du serveur et une surcharge du client. C’est pourquoi il a ensuite été proposé puis mis en œuvre architecture du serveur de base de données. Dans celui-ci, une partie de la logique de l'application est implémentée sur le serveur, en utilisant langue spéciale programmation, et une partie - sur le client. Cela est devenu possible grâce à la productivité accrue des serveurs SGBD modernes. Par rapport à l'option serveur d'accès aux données à distance, dans ce cas la charge est légèrement réduite

côté client, l'intensité des échanges de données sur le réseau et, dans certains cas, la structure des applications sont simplifiées. Actuellement, cette option pour les systèmes de construction est la plus courante.

Une autre option pour l'architecture client-serveur est serveur d'applications. Dans ce cas, le client effectue uniquement les opérations de visualisation et de saisie de données, et le serveur implémente toute la logique applicative. L'échange entre le client et le serveur dans de tels systèmes s'effectue au niveau des commandes d'affichage des données à l'écran et des résultats de la saisie de l'utilisateur. La plupart un exemple brillant cette architecture est bien connue navigateur Internet. Le plus souvent, dans le modèle de serveur d'applications, les composants de logique d'application et de gestion des données sont implémentés séparément.

L'architecture du serveur d'applications est souvent appelée client "léger", Contrairement à un client "épais" traditionnel implémenté dans une architecture de serveur de base de données. Un client léger est une option qui peut être utilisée lorsque les ressources disponibles sur les postes de travail des utilisateurs sont insuffisantes pour exécuter la logique de l'application. De plus, cette technologie permet de réduire le coût d'exploitation des composants clients du système grâce à leur forte simplification.

Conditions préalables à l'émergence de l'architecture client-serveur dans l'entreprise

L'informatisation d'une entreprise industrielle peut s'effectuer assez longtemps dans le cadre des lieux de travail ou de l'architecture locale décrits précédemment serveur de fichiers. Cependant, tôt ou tard, il pourrait arriver un moment où la seule option pour la poursuite du développement les systèmes de gestion d'entreprise automatisés deviendront l'architecture serveur client. Essayons de lister raisons principales pourquoi cela devient nécessaire.

Premièrement, l’architecture client-serveur devient vitale lorsque le nombre d’utilisateurs utilisant simultanément et activement les mêmes données dépasse 10 à 15 personnes. En raison des limitations fondamentales inhérentes aux applications de serveur de fichiers, de tels systèmes sont difficiles à tolérer avec 15 utilisateurs simultanés et s'effondrent souvent avec 20 utilisateurs. Ainsi, si une entreprise est confrontée à la tâche de construire un système dans lequel le nombre d'endroits travaillant simultanément activement avec des données dépasse 20, pratiquement la seule option pour elle est un client-serveur.

Pour être honnête, il convient de noter que les gros ordinateurs sont également capables de gérer des dizaines, voire des centaines d’utilisateurs. Cependant, en raison de coût élevé matériel, le coût de développement élevé et, surtout, les coûts considérables d'exploitation de ces équipements et programmes, l'option d'utiliser une architecture centralisée lors de l'introduction de nouveaux systèmes dans notre pays n'est presque jamais envisagée.

Aux autres moment critique Passer à une architecture client-serveur est une transition vers la résolution de problèmes à l’échelle de l’entreprise et la gestion de l’entreprise dans son ensemble. L'automatisation de tâches individuelles peut être réalisée avec succès même sans utiliser technologies de réseau, un serveur de fichiers peut gérer des tâches à l'échelle d'un service, mais la création d'un système automatisé intégré couvrant l'ensemble de l'entreprise ou au moins un des sous-systèmes de gestion n'est possible qu'en utilisant les technologies client-serveur.

Une autre situation dans laquelle le client-serveur est le seul moyen de construire un système est lorsque le système automatisé a utilisateurs distants, avec qui il est nécessaire d'échanger des informations en temps réel. Par échelle de temps réel, nous entendons ici secondes-minutes. Dans ce cas, l'échange de données sur disquettes est fondamentalement inadapté et l'architecture du serveur de fichiers nécessitera des vitesses d'échange très élevées, ce qui peut être soit fondamentalement impossible, soit très coûteux. Des exemples individuels d'organisations riches qui ont construit des systèmes de serveurs de fichiers à l'échelle de la ville (par exemple, la banque russe Inkombank) sont des exceptions qui confirment la règle.

Et enfin, l'architecture client-serveur est nécessaire lorsque la tâche consistant à garantir l’intégrité des informations devient critique. Par critique, nous entendons une situation dans laquelle le coût d'une erreur de données peut être comparable au coût de création d'un système client-serveur. Tout d’abord, cela concerne les services financiers des entreprises.

Tenter de résoudre l'un des problèmes énumérés ci-dessus dans le cadre de l'informatisation d'une entreprise industrielle entraînera nécessairement l'émergence d'un système client-serveur. De plus, cette architecture peut apparaître comme une évolution naturelle des systèmes automatisés de contrôle de production, même si les limites des architectures précédentes dans une entreprise donnée ne sont pas encore devenues critiques. Cette option est la plus préférable car, d'une part, la mise en œuvre reçoit un soutien de l'intérieur et, d'autre part, il y a du temps pour préparer un changement en douceur dans l'architecture des applications d'information.

Architecture client-serveur : Oui, mais...

Nous avons déjà parlé des avantages de l'architecture client-serveur. Une question naturelle peut se poser : si c’est si bon, alors pourquoi ne l’ont-ils pas encore adopté ? Tous grands utilisateurs des systèmes d’information. Ce n'est en fait pas si simple.

Tout d'abord, pour les entreprises industrielles nationales, il est essentiel facteur de coût. Contrairement aux entreprises occidentales, où il s'agit généralement de remplacer des systèmes centralisés plutôt coûteux par des systèmes client-serveur, dont les coûts directs sont inférieurs, les entreprises nationales n'ont presque jamais eu suffisamment de fonds pour mettre en œuvre de grands systèmes centralisés. Très souvent, les systèmes d'information disponibles dans une entreprise reposent sur du matériel obsolète qui nécessite remplacement complet lors du passage à une architecture client-serveur.

Le prochain grand "mais" est le grand volume de changements technologiques eux-mêmes problèmes qui surviennent lors de la tentative de mise en œuvre d’une architecture client-serveur. Un système client-serveur nécessite un niveau différent de connaissances techniques de la part des employés services d'information, donc les utilisateurs finaux. Coûts de reconversion des utilisateurs et personnel d'exploitation, la restructuration de la structure d'automatisation de l'entreprise constitue une plus grande partie de l'iceberg que les coûts directs clairement visibles de mise à niveau des équipements, d'achat et/ou de développement des logiciels requis.

Et enfin, le plus grand écueil sur le chemin de la création d'un système CS dans une entreprise est la nécessité modifier la structure de gestion et les coûts organisationnels associés

Une tentative d'introduire de nouvelles solutions technologiques sans rien changer à l'essence des processus métiers automatisés peut s'avérer vaine. Dans ce cas, l'entreprise subira des pertes matérielles directes en raison du grand volume de matériel et de logiciels coûteux qui représentent un poids mort, ainsi qu'en raison de la distraction des employés de l'exercice de leurs principales tâches. DANS le meilleur cas de scenario sera mis en œuvre zones séparées système client-serveur, bien qu'en réalité nouveau logiciel sera utilisé à l’ancien niveau idéologique.

Si, après avoir pesé le pour et le contre, l'entreprise décide néanmoins de créer un système client-serveur, alors elle est confrontée à la tâche sélection des composants pour construire ce système. Dans tous les cas, le composant nécessaire est l'un ou l'autre serveur de base de données niveau de l’entreprise. Les composants restants dépendent de la voie choisie par l'entreprise pour son développement ultérieur. Système automatisé gestion.

Si l'entreprise a décidé développer le système vous-même, il est alors confronté avant tout à la tâche de choisir les outils de développement. Si l'entreprise place ordre de création d'un système une société de développement spécifique, elle est alors confrontée à une tâche similaire.

Dans le cas où la décision est prise de ne pas développer le système nous-mêmes, mais d'utiliser l'une des solutions disponibles sur le marché, alors l'élément principal du choix est système d'automatisation d'entreprise prêt à l'emploi (à un degré ou à un autre). En fait, le terme « sur étagère » doit être utilisé avec beaucoup de prudence, car il est difficile de tracer une frontière claire entre la personnalisation pour les besoins d'un usage spécifique et l'adaptation du système, qui implique souvent la modification des modules du système ou même le développement sécurité supplémentaire selon les besoins du client.

Client-serveur est une architecture informatique ou réseau dans laquelle les tâches ou la charge réseau sont réparties entre les fournisseurs de services, appelés serveurs, et les clients de services, appelés clients. Souvent, les clients et les serveurs communiquent sur un réseau informatique et peuvent être des appareils physiques ou des logiciels différents.

Avantages

Permet, dans la plupart des cas, de répartir les fonctions système informatique entre plusieurs ordinateurs indépendants du réseau. Cela facilite la maintenance du système informatique. En particulier, le remplacement, la réparation, la mise à niveau ou le déplacement d'un serveur n'affectent pas les clients.

Toutes les données sont stockées sur le serveur, qui, en règle générale, est bien mieux protégé que la plupart des clients. Il est plus facile d'appliquer des contrôles d'autorisation sur le serveur pour autoriser uniquement les clients disposant des droits d'accès appropriés à accéder aux données.

Vous permet de combiner différents clients. Les clients dotés de différentes plates-formes matérielles, systèmes d'exploitation, etc. peuvent souvent utiliser les ressources d'un seul serveur.

[modifier]

Défauts

Une panne de serveur peut rendre l’ensemble du réseau informatique inutilisable.

La prise en charge du fonctionnement de ce système nécessite un spécialiste distinct - un administrateur système.

Coût élevé de l'équipement.

[modifier]

Architecture client-serveur multiniveau

L'architecture client-serveur multiniveau est un type d'architecture client-serveur dans lequel la fonction de traitement des données est effectuée sur un ou plusieurs serveurs distincts. Cela vous permet de séparer les fonctions de stockage, de traitement et de présentation des données pour une utilisation plus efficace des capacités des serveurs et des clients.

Cas particuliers d'architecture multi-niveaux :

Architecture à trois niveaux

[modifier]

Réseau de serveurs dédiés

Un réseau avec un serveur dédié (réseau Client/Serveur en anglais) est un réseau local. réseau informatique(LAN), dans lequel Périphériques réseau centralisé et géré par un ou plusieurs serveurs. Les postes de travail ou clients individuels (tels que les PC) doivent accéder aux ressources réseau via un ou plusieurs serveurs.

Introduction

Beaucoup de choses ont déjà été écrites sur la technologie client-serveur. On peut constater que l'enthousiasme suscité par ce sujet il y a deux ans s'est définitivement apaisé. Les articles dans la presse et les conversations en marge ont acquis un ton calme et professionnel et discutent désormais généralement d'aspects spécifiques de l'application de cette technologie. La question « Être ou ne pas être une architecture client-serveur ? Maintenant, personne n'en parle - tout le monde sait que « Être !

Cependant, de nombreux lecteurs ne se sont peut-être intéressés à ce sujet que récemment, c'est pourquoi, à notre avis, il vaut la peine d'y revenir à nouveau et calmement, de manière professionnelle, en discutant de ce qu'est l'architecture client-serveur, pourquoi elle est nécessaire et comment approche-le.

Qu’est-ce que l’architecture client-serveur ?

D'une manière générale, un système client-serveur se caractérise par la présence de deux processus indépendants en interaction - un client et un serveur, qui, en général, peuvent être exécutés sur différents ordinateurs, échangeant des données sur le réseau. Selon ce schéma, des systèmes de traitement de données basés sur des SGBD, du courrier et d'autres systèmes peuvent être construits. Nous parlerons bien sûr des bases de données et des systèmes basés sur celles-ci. Et ici, il sera plus pratique non seulement de considérer l'architecture client-serveur, mais de la comparer avec une autre - serveur de fichiers.

Dans un système de serveur de fichiers, les données sont stockées sur un serveur de fichiers (par exemple, Novell NetWare ou Windows NT Server) et leur traitement est effectué sur des postes de travail qui, en règle générale, exploitent l'un des soi-disant « SGBD de bureau ». » - Access, FoxPro, Paradox, etc.

L'application sur le poste de travail est « responsable de tout » : de la création de l'interface utilisateur, du traitement logique des données et de la manipulation directe des données. Le serveur de fichiers ne fournit que le plus niveau faible- ouvrir, fermer et modifier des fichiers, j'insiste - des fichiers, pas des bases de données. La base de données existe uniquement dans le « cerveau » du poste de travail.

Ainsi, plusieurs processus indépendants et incohérents sont impliqués dans la manipulation directe des données. De plus, pour effectuer tout traitement (recherche, modification, sommation, etc.), toutes les données doivent être transférées sur le réseau du serveur vers le poste de travail (voir Fig. Comparaison des modèles de serveur de fichiers et de client-serveur)

Dans un système client-serveur, il existe (au moins) deux applications - un client et un serveur, partageant entre elles les fonctions qui, dans une architecture serveur de fichiers, sont entièrement exécutées par une application sur un poste de travail. Le stockage et la manipulation directe des données sont effectués par un serveur de base de données, qui peut être Microsoft serveur SQL, Oracle, Sybase, etc.

Formation interface utilisateur traite avec le client, pour construire lequel vous pouvez utiliser un certain nombre d'outils spéciaux, ainsi que la plupart des SGBD de bureau. La logique de traitement des données peut être exécutée à la fois sur le client et sur le serveur. Le client envoie des requêtes au serveur, généralement formulées en Langage SQL. Le serveur traite ces requêtes et envoie le résultat au client (bien entendu, il peut y avoir plusieurs clients).

Ainsi, un processus est chargé de manipuler directement les données. Dans le même temps, le traitement des données s'effectue au même endroit où les données sont stockées - sur le serveur, ce qui élimine le besoin de transférer de grandes quantités de données sur le réseau.

Quand avez-vous besoin d’une architecture client-serveur ?

Même une analyse très détaillée des fonctionnalités de l'architecture client-serveur peut ne pas répondre à la question « Qu'est-ce que cela va me donner ? Regardons cette architecture du point de vue des besoins de l'entreprise. Quelles qualités un client-serveur apporte-t-il à un système d'information :

Fiabilité

Quiconque a occupé au moins une fois le rôle d'administrateur de base de données au moment où cette base de données « est morte » à cause d'un « gel » d'un serveur ou d'un poste de travail, d'une panne de courant ou d'un autre malheur ne négligera plus jamais les problèmes de fiabilité (si, bien sûr). bien sûr, pourra conserver ce rôle). Si vous n'avez pas encore joué ce rôle, j'espère que vous avez l'imagination nécessaire pour rejouer ce thriller dans votre tête, et la prudence nécessaire pour garder votre base de données (et vous-même) aussi sûre que possible. Comment l’architecture client-serveur est-elle utile ici ?

Le serveur de base de données effectue une modification des données sur la base d'un mécanisme de transaction, qui confère à tout ensemble d'opérations déclarées comme transaction les propriétés suivantes :

atomicité - en aucun cas, soit toutes les opérations de la transaction seront effectuées, soit aucune ne sera effectuée ; l'intégrité des données une fois la transaction terminée ;

indépendance - les transactions initiées par différents utilisateurs n'interfèrent pas avec les affaires de chacun ;

résistance aux échecs - une fois la transaction terminée, ses résultats ne seront pas perdus.

Le mécanisme de transaction pris en charge par le serveur de base de données est beaucoup plus efficace que le mécanisme similaire des SGBD de bureau, car le serveur contrôle de manière centralisée le fonctionnement des transactions. De plus, dans un système serveur de fichiers, une panne sur l'un des postes de travail peut entraîner une perte de données et son inaccessibilité aux autres postes de travail, tandis que dans un système client-serveur, une panne sur le client n'affecte presque jamais l'intégrité des données. et leur disponibilité pour les autres clients.

Évolutivité

L'évolutivité est la capacité du système à s'adapter à la croissance du nombre d'utilisateurs et du volume de la base de données avec une augmentation adéquate des performances de la plate-forme matérielle, sans remplacer le logiciel.

Il est bien connu que les capacités des SGBD de bureau sont sérieusement limitées - respectivement cinq à sept utilisateurs et 30 à 50 Mo. Bien entendu, les chiffres représentent des valeurs moyennes ; dans des cas spécifiques, ils peuvent s'écarter dans les deux sens. Plus important encore, ces obstacles ne peuvent être surmontés en augmentant les capacités matérielles.

Les systèmes basés sur des serveurs de bases de données peuvent prendre en charge des milliers d'utilisateurs et des centaines de Go d'informations - il suffit de leur fournir la plate-forme matérielle appropriée.

Sécurité

Le serveur de base de données fournit des moyens puissants de protéger les données contre tout accès non autorisé, ce qui n'est pas possible dans les SGBD de bureau. Dans le même temps, les droits d'accès sont gérés de manière très flexible, jusqu'au niveau des champs de table. De plus, vous pouvez interdire complètement l'accès direct aux tables, permettant à l'utilisateur d'interagir avec les données via des objets intermédiaires - vues et procédures stockées. Ainsi, l'administrateur peut être sûr qu'aucun utilisateur trop intelligent ne lira ce qu'il n'est pas censé lire.

La flexibilité

Dans une application de données, il existe trois couches logiques :

interface utilisateur;

règles de traitement logique (règles métier) ;

gestion des données (il ne faut pas confondre les couches logiques avec niveaux physiques, qui sera discuté ci-dessous).

Comme déjà mentionné, dans une architecture de serveur de fichiers, les trois couches sont implémentées dans une application monolithique exécutée sur un poste de travail. Par conséquent, les changements dans l’une des couches entraînent clairement une modification de l’application et une mise à jour ultérieure de ses versions sur les postes de travail.

En deux niveaux application client-serveur, montré sur la fig. 1, en règle générale, toutes les fonctions de création d'une interface utilisateur sont implémentées sur le client, toutes les fonctions de gestion des données sont implémentées sur le serveur, mais les règles métier peuvent être implémentées à la fois sur le serveur à l'aide de mécanismes de programmation du serveur (procédures stockées, déclencheurs, vues, etc. ), et sur le client. Dans une application à trois niveaux, un troisième niveau intermédiaire apparaît, mettant en œuvre les règles métier, qui sont les composants d'application les plus fréquemment modifiés (voir Fig. Modèle d'application client-serveur à trois niveaux)

La présence non pas d'un, mais de plusieurs niveaux permet une flexibilité et coûts minimes adapter l'application aux besoins changeants de l'entreprise.

Essayons d'illustrer tout ce qui précède avec un petit exemple. Supposons que les règles de calcul aient changé dans une certaine organisation salaires(règles métier) et le logiciel correspondant doit être mis à jour.

1) Dans un système de serveur de fichiers, on apporte "simplement" des modifications à l'application et on met à jour ses versions sur les postes de travail. Mais cela implique « simplement » des coûts de main-d’œuvre maximaux.

2) Dans un système client-serveur dual-tier, si l'algorithme de paie est implémenté sur le serveur sous la forme d'une règle de paie, il est exécuté par un serveur de règles métier, implémenté par exemple en tant que serveur OLE, et on mettra à jour un de ses objets sans rien changer ni dans l'application cliente ni sur le serveur de base de données.

Étapes de construction d'un système client-serveur.

Supposons que vous utilisiez aujourd'hui une application, implémentée dans une architecture de serveur de fichiers, en utilisant des moyens Microsoft Access, et réfléchir à son développement. Les étapes suivantes peuvent être envisagées.

1. Transférez la base de données vers MicrosoftSQL Serveur, en gardant l'interface et la logique de fonctionnement inchangées. Dans le même temps, vous ne profiterez pas de tous les avantages de l’architecture client-serveur, mais vous pouvez être assuré que vos données sont stockées en toute sécurité.

2. Développez une application client-serveur à deux niveaux à part entière en utilisant la même combinaison Access - SQL Server, qui fonctionne très bien. Cela peut être fait, par exemple, en modifiant progressivement les composants individuels de l'application obtenue à l'étape 1. Une alternative serait de développer une toute nouvelle application en utilisant Visual Basic, Delphi ou tout autre des dizaines d'outils disponibles en tant que client.

3.Si vous envisagez une croissance sérieuse de votre organisation, l'utilisation d'une architecture à trois niveaux vous permettra de répartir de manière plus flexible la charge croissante entre les serveurs et de minimiser les coûts de maintenance et de développement du système.

Nous espérons que cet article vous a donné une compréhension générale de l’architecture client-serveur et de ses avantages. Dans les prochains numéros, nous prévoyons de parler plus en détail de Microsoft SQL Server et de la création de systèmes basés sur celui-ci.

Par application client-serveur, nous entendrons un système d'information basé sur l'utilisation de serveurs de bases de données (voir la longue note en fin de section 2.1). Aperçu général Système d'Information dans l'architecture client-serveur est illustré à la figure 2.3.

Côté client, le code de l'application est exécuté, qui inclut nécessairement des composants prenant en charge l'interface utilisateur final, produisant des rapports et exécutant d'autres fonctions spécifiques à l'application (pour l'instant, nous ne nous intéresserons pas à la façon dont le code de l'application est construit) .
La partie client de l'application interagit avec la partie client du logiciel de gestion de base de données, qui est en fait le représentant individuel du SGBD de l'application.

(Ici encore, des lacunes terminologiques apparaissent. Habituellement, lorsqu'une entreprise annonce la sortie d'un autre serveur de base de données, il est implicitement entendu qu'il existe également un composant client de ce produit. La combinaison « partie client du serveur de base de données » semble quelque peu étrange, mais nous devrons utiliser ce terme.)

Riz. 2.3. Représentation générale d'un système d'information dans une architecture client-serveur

A noter que l'interface entre la partie client de l'application et la partie client du serveur de base de données repose généralement sur l'utilisation du langage SQL. Ainsi, des fonctions telles que, par exemple, le prétraitement des formulaires destinés aux requêtes de bases de données ou la génération de rapports résultants sont exécutées dans le code de l'application.

Enfin, le côté client du serveur de base de données, à l'aide des outils l'accès au réseau, accède au serveur de base de données en lui transmettant le texte de l'instruction SQL.

Deux autres remarques doivent être faites ici.

En règle générale, les entreprises produisant des serveurs de bases de données avancés s'efforcent de garantir que leurs produits peuvent être utilisés non seulement dans les réseaux TCP/IP standard actuels, mais également dans les réseaux basés sur d'autres protocoles (par exemple, SNA ou IPX/SPX). Par conséquent, lors de l'organisation des interactions réseau entre les parties client et serveur du SGBD, non moyens standards haut niveau(par exemple, des mécanismes d'imbrications logicielles ou d'appels de procédures à distance), et leurs propres outils fonctionnellement similaires, moins dépendants des caractéristiques du réseau protocoles de transport.
Lorsque l’on parle d’une interface basée sur le langage SQL, il faut être conscient que malgré les efforts titanesques pour standardiser ce langage, il n’existe aucune implémentation dans laquelle les fonctionnalités du langage standard ne seraient pas étendues. Une utilisation imprudente des extensions de langage conduit à une dépendance totale de l'application vis-à-vis de fabricant spécifique serveurs de bases de données.

Nous reviendrons sur ces questions plus en détail dans la quatrième partie du cours.

Voyons maintenant ce qui se passe côté serveur de base de données. Dans les produits de presque toutes les entreprises, le serveur reçoit le texte de l'opérateur en SQL du client.

Le serveur compile l'instruction résultante. Nous ne nous attarderons pas ici sur le langage cible utilisé par un compilateur particulier ; Différentes implémentations adoptent différentes approches (voir la partie 4 pour des exemples). L'essentiel est que dans tous les cas, sur la base des informations contenues dans les tables du catalogue de la base de données, la représentation non procédurale de l'opérateur est convertie en une procédure pour son exécution.
Ensuite (si la compilation est terminée avec succès), l'instruction est exécutée. Encore une fois, nous ne discuterons pas des détails techniques car ils varient selon les implémentations. Considérons actions possibles Instructions SQL.

Un opérateur peut appartenir à la classe des opérateurs permettant de définir (ou de créer) des objets de base de données (il serait plus précis et correct de parler d'éléments de schéma de base de données ou d'objets de métabase de données). En particulier, des domaines, des tables, des contraintes d'intégrité, des déclencheurs, des privilèges utilisateur et des procédures stockées peuvent être définis. Dans tous les cas, lorsque l'instruction de création d'élément de schéma de base de données est exécutée, les informations correspondantes sont placées dans les tables du catalogue de base de données (dans les tables de métadonnées). Les contraintes d'intégrité sont généralement stockées dans la métadonnée directement dans une représentation textuelle. Pour les actions définies dans les déclencheurs et les procédures stockées, le code exécutable procédural est généré et stocké dans les tables du catalogue. Notez que les contraintes d'intégrité, les déclencheurs et les procédures stockées sont, en un sens, des représentants de l'application dans la base de données gérée par le serveur ; ils constituent la base du backend de l'application (voir ci-dessous).
Lorsque des instructions de récupération de données sont exécutées, sur la base du contenu des tables affectées par la requête, et éventuellement en utilisant des index conservés dans la base de données, un ensemble de données de résultats est formé (nous n'utilisons pas intentionnellement le terme « table de résultats » ici car, selon le type spécifique d'instruction, le résultat peut être ordonné et les tableaux, c'est-à-dire les relations, ne sont pas ordonnés par définition). La partie serveur du SGBD envoie le résultat à la partie client, et le traitement final est effectué dans la partie client de l'application.
Lors de l'exécution des instructions de modification du contenu de la base de données (INSERT, UPDATE, DELETE), on vérifie que les contraintes d'intégrité définies à ce stade (celles qui sont immédiatement vérifiées) ne seront pas violées, après quoi l'action correspondante est effectuée (accompagnée d'une modification de tous index pertinents et journalisation des modifications). Ensuite, le serveur vérifie si ce changement affecte la condition de déclenchement d'un déclencheur, et si un tel déclencheur est détecté, il exécute la procédure pour son action. Cette procédure peut inclure des instructions de modification de base de données supplémentaires qui peuvent provoquer le déclenchement d'autres déclencheurs, etc. Vous pouvez prendre en compte les actions effectuées sur le serveur de base de données lors de la vérification si les contraintes d'intégrité sont satisfaites et lorsque des déclencheurs sont déclenchés pour représenter les actions du côté serveur de l'application.

Lors de l'exécution d'instructions de modification du schéma de base de données (ajout ou suppression de colonnes de tables existantes, modification du type de données d'une colonne existante d'une table existante, etc.), des déclencheurs peuvent également se déclencher, c'est-à-dire que le côté serveur de l'application peut être exécuté.

En général, dans une architecture de serveur de fichiers, nous avons un client « épais » et un serveur très « léger » dans le sens où presque tout le travail est effectué côté client et seule une capacité suffisante est requise du serveur. mémoire disque(Figure 2.2).

Riz. 2.2. Client « gros » et serveur « léger » dans une architecture de serveur de fichiers

Brèves conclusions. Simple, à petite échelle et prête pour un seul utilisateur, une application de serveur de fichiers peut être conçue, développée et déboguée très rapidement. Très souvent, pour qu'une petite entreprise puisse conserver, par exemple, les dossiers du personnel, il suffit de disposer d'un système isolé fonctionnant sur un PC séparé. Bien entendu, dans ce cas également, les utilisateurs finaux (ou les administrateurs, dont la disponibilité dans ce cas est discutable) doivent faire preuve d'une grande prudence pour stocker en toute sécurité et maintenir l'intégrité des données. Cependant, dans des cas un peu plus complexes (par exemple lorsqu'il s'agit d'organiser un système d'information pour supporter un projet porté en groupe), les architectures de serveurs de fichiers deviennent insuffisantes.

Sont des composants inégaux réseau d'information. Certains possèdent une ressource et sont donc appelés serveurs ; d'autres accèdent à ces ressources et sont appelés clients. Voyons comment ils interagissent les uns avec les autres et quelle est l'architecture client-serveur.

Architecture client-serveur

L'architecture « Client-Serveur » représente l'interaction des composants structurels d'un réseau basés sur ceux définis par un réseau donné, où les composants structuraux sont le serveur et les nœuds qui fournissent certaines fonctions spécialisées (services), ainsi que les clients qui utilisent ce service. Les fonctions spécifiques sont généralement divisées en trois groupes en fonction de la résolution de problèmes spécifiques :

les fonctions de saisie et de présentation des données sont conçues pour l'interaction de l'utilisateur avec le système ;
fonctions appliquées - chacune a son propre ensemble ;
les fonctions de gestion des ressources sont conçues pour gérer le système de fichiers, diverses bases de données et d'autres composants.

Par exemple, un ordinateur sans connexion réseau, représente les composants de la vue, fins appliquées et la gestion sur différents niveaux. Ces types de niveaux sont considérés système opérateur, logiciels d'application et utilitaires, divers utilitaires. De la même manière, tous les composants ci-dessus sont présentés sur Internet. L'essentiel est d'assurer correctement l'interaction réseau entre ces composants.

Comment fonctionne l'architecture client-serveur

L'architecture client-serveur est le plus souvent utilisée pour créer des bases de données d'entreprise dans lesquelles les informations sont non seulement stockées, mais également traitées périodiquement. diverses méthodes. La base de données est l’élément principal de tout système d’information d’entreprise, et le serveur héberge le cœur de cette base de données. Ainsi, les opérations les plus complexes liées à la saisie, au stockage, au traitement et à la modification des données ont lieu sur le serveur. Lorsqu'un utilisateur (client) accède à la base de données (serveur), la requête est traitée : accédant directement à la base de données et renvoyant une réponse (résultat du traitement). Le résultat du traitement est un message réseau concernant le succès de l'opération ou une erreur. Les ordinateurs serveurs peuvent gérer les demandes simultanées de plusieurs clients pour le même fichier. Un tel travail sur le réseau vous permet d'accélérer le travail des applications que vous utilisez.

Architecture client-serveur : application de la technologie

Cette architecture permet d'accéder à diverses ressources grâce aux technologies réseaux : bases de données, serveurs de messagerie, pare-feu, serveurs proxy. Le développement d'applications client-serveur peut améliorer la sécurité, la fiabilité et les performances des applications utilisées et du réseau dans son ensemble. Les applications client-serveur sont le plus souvent utilisées pour l'automatisation des entreprises.

Département de l'enseignement général et professionnel de la région de Briansk

Établissement d'enseignement public

Collège textile Klintsovsky

LOGICIEL POUR SYSTÈMES D'INFORMATION AUTOMATISÉS

Technologie client-serveur

Étudiant gr. A-90______________________________(Petrochenko A.O.)

Enseignant _______________________ (Shirokova A.L.)

Klintsy – 2011

1. Les serveurs. Bases du serveur

2. Modèle client-serveur

3. Classification des serveurs standards

4. Conclusion

1. Serveurs. Bases du serveur

Serveur (du serveur anglais, servant). Selon l'objectif, il existe plusieurs définitions du concept serveur.

1. Serveur (réseau) - un nœud de réseau logique ou physique qui répond aux requêtes vers une adresse et/ou un nom de domaine (adjacent noms de domaine), constitué d'un ou d'un système de serveurs matériels sur lesquels un ou un système de programmes serveur est exécuté

2. Serveur (logiciel) - logiciel qui reçoit les requêtes des clients (dans l'architecture client-serveur).

3. Serveur ( Matériel) - un ordinateur (ou un équipement informatique spécial) dédié et/ou spécialisé pour exécuter certaines fonctions de service.

3. Serveur dans informatique- un composant logiciel d'un système informatique qui exécute fonctions de serviceà la demande du client, lui donnant accès à certaines ressources.

Interrelation des concepts. Une application serveur (serveur) s'exécute sur un ordinateur, également appelé « serveur », et si l'on considère la topologie du réseau, un tel nœud est appelé « serveur ». En général, il se peut que l'application serveur s'exécute sur un poste de travail classique ou que l'application serveur s'exécute sur ordinateur serveur dans le cadre de la topologie considérée, il agit en tant que client (c'est-à-dire qu'il n'est pas un serveur du point de vue de la topologie du réseau).

2. Modèle client-serveur

Un système client-serveur se caractérise par la présence de deux processus indépendants en interaction - un client et un serveur, qui, en général, peuvent être exécutés sur différents ordinateurs, échangeant des données sur le réseau.

Processus qui implémentent un service, tel qu'un service système de fichiers ou les bases de données sont appelées les serveurs(les serveurs). Les processus qui demandent des services aux serveurs en envoyant une requête puis en attendant une réponse du serveur sont appelés clients(clients) .

Selon ce schéma, des systèmes de traitement de données basés sur des SGBD, du courrier et d'autres systèmes peuvent être construits. Nous parlerons des bases de données et des systèmes basés sur celles-ci. Et ici, il sera plus pratique de ne pas simplement considérer architecture client-serveur, et comparez-le avec un autre - un serveur de fichiers.

L'application sur le poste de travail est « responsable de tout » : de la création de l'interface utilisateur, du traitement logique des données et de la manipulation directe des données. Le serveur de fichiers ne fournit que le niveau de services le plus bas : ouverture, fermeture et modification de fichiers. Veuillez noter : des fichiers, pas des bases de données. Le système de gestion de base de données est situé sur le poste de travail.

Ainsi, plusieurs processus indépendants et incohérents sont impliqués dans la manipulation directe des données. De plus, pour effectuer tout traitement (recherche, modification, sommation, etc.), toutes les données doivent être transférées sur le réseau du serveur vers le poste de travail ( voir fig. Comparaison des modèles de serveur de fichiers et de client-serveur)

Riz. Comparaison des modèles de serveur de fichiers et de client-serveur

Dans un système client-serveur, il existe (au moins) deux applications - un client et un serveur, partageant entre elles les fonctions qui, dans une architecture serveur de fichiers, sont entièrement exécutées par une application sur un poste de travail. Le stockage des données et la manipulation directe sont effectués par un serveur de base de données, qui peut être Microsoft SQL Server, Oracle, Sybase, etc.

L'interface utilisateur est créée par le client, pour la construction de laquelle vous pouvez utiliser un certain nombre d'outils spéciaux, ainsi que la plupart des SGBD de bureau. La logique de traitement des données peut être exécutée à la fois sur le client et sur le serveur. Le client envoie des requêtes au serveur, généralement formulées en SQL. Le serveur traite ces requêtes et envoie le résultat au client (bien entendu, il peut y avoir plusieurs clients).

Que propose l’architecture client-serveur ?

Regardons cette architecture du point de vue des besoins de l'entreprise. Quelles qualités un client-serveur apporte-t-il à un système d’information ?

Fiabilité

atomicité- en aucun cas, soit toutes les opérations de transaction seront réalisées, soit aucune ne sera réalisée ; l'intégrité des données une fois la transaction terminée ;
indépendance- les transactions initiées par différents utilisateurs n'interfèrent pas avec les affaires de chacun ;
tolérance aux pannes- une fois la transaction terminée, ses résultats ne seront plus perdus.

Évolutivité

Sécurité

La flexibilité

Dans une application de données, il existe trois couches logiques :

interface utilisateur ;
règles de traitement logique(règles commerciales);
gestion de données(ne confondez pas les couches logiques avec les niveaux physiques, qui seront discutés ci-dessous).

Dans une application client-serveur à deux niveaux illustrée dans la figure ci-dessus, en règle générale, toutes les fonctions de création d'interface utilisateur sont implémentées sur le client, toutes les fonctions de gestion des données sont implémentées sur le serveur, mais les règles métier peuvent être implémentées à la fois sur le serveur à l'aide de mécanismes de programmation serveur (procédures stockées, triggers, vues, etc.) et sur le client.

Dans une application à trois niveaux, il existe une troisième couche intermédiaire qui implémente les règles métier, qui sont les composants de l'application les plus fréquemment modifiés ( voir fig. Modèle d'application client-serveur à trois niveaux)

Riz. Modèle d'application client-serveur à trois niveaux

La présence non pas d'un, mais de plusieurs niveaux vous permet d'adapter l'application de manière flexible et rentable aux besoins changeants de l'entreprise.

Essayons d'illustrer tout ce qui précède avec un petit exemple. Supposons que les règles de paie (règles commerciales) d'une certaine organisation aient changé et que le logiciel correspondant doive être mis à jour.

Site sur l'informatique

ARTICLES LIÉS