Architecture Client-serveur et l’architecture orientée services

Télécharger le fichier pdf d’un mémoire de fin d’études

Les traitements

Les traitements ou la logique de l’application ou encore la partie applicative correspondent à l’ensemble des traitements applicatifs et aux procédures d’accès aux données. En d’autre terme, ils intègrent le logique métier par exemple si un document est composé de sections, et elles-mêmes composées de sous-sections… ils referment les opérations qui réalise les services offerts aux utilisateurs comme créer un document, le modifier, ajouter des sections, l’enregistrer …. La logique
des traitements contient l’arborescence algorithmique de l’application (comme le lancement des procédures de la couche gestion des traitements) et la gestion des traitements sont des genres de procédures de traitements contenant comme exemple des requêtes SQL de manipulation de données [3].

Les données

Ce sont les données gérées par l’application, ou encore enregistrement sur un support physique des données de l’application. Elles se présentent comme des fichiers (binaires, XML eXtensible Mark-up Language, …) ou en base de données ou en d’autres forme. En forme de base de données, elles sont généralement accessibles en utilisant, par exemple, des Systèmes de Gestion de Base de Données Relationnelles ou Objet (SGBDR ou SGBDO) souvent au travers des interfaces comme JDBC (Java) ou ODBC (Microsoft). Et ce, la plupart du temps, par le biais de SQL (Structured Query Language) qui est, par définition, un langage structuré de requête. Pourtant, il y a d’autre mode d’accès pour le cas des fichiers bruts ou formatés (XML…). La logique des données garantit le respect de la règle CRUDE pour les objets de la BD mis à jour par les procédures et pour la gestion des données, il effectue les sélections ou les mises à jour des enregistrements (généralement pris en charge par le SGBD) [3].

Architectures centralisé

Nous avons vu dans l’historique, paragraphe 1.1, que l’architecture centralisé est la première architecture système apparu dans l’histoire de l’informatique, en d’autre mot, elle fut la première solution qui a proposé un accès multi-utilisateurs. Cette technologie est presque obsolète mais la comprendre ferait toujours de la bonne base.

L’informatique centralisée

Les premiers réseaux étaient propriétaires et centralisés, ils étaient conçus, fabriqués et mis en œuvre par une seule société (c’était le temps du monopole d’IBM). De tels réseaux étaient constitués de matériels et de logiciels issus d’une seule société qui cumulait les rôles de constructeur, d’architecte et d’éditeur. Ces réseaux étaient vendus clefs en main mais ils ne fonctionnaient pas avec d’autres réseaux, ils étaient compatibles avec eux même et c’était déjà beaucoup. L’architecture d’un réseau propriétaire était centralisée autour d’un gros ordinateur très puissant, pour l’époque, et des terminaux « passif » qui interrogeaient le super calculateur central (il y a une dissymétrie entre les clients et le serveur). Désormais, la conception d’une machine et l’organisation d’un réseau se sont largement ouvertes aux autres. On parle de réseaux décentralisés, répartis ou distribués.

Présentation

Dans une application un tiers, les trois couches applicatives sont intimement liées et s’exécutent sur le même ordinateur. On ne parle pas ici d’architecture client-serveur, mais d’informatique centralisée. Dans un contexte multi-utilisateurs, on peut rencontrer deux types d’architecture mettant en œuvre des applications un tiers :
• Des applications sur un site central,
• Des applications réparties sur des machines indépendantes communiquant par partage de fichiers.

Le principe de fonctionnement

Les utilisateurs se connectent aux applications exécutées par le serveur central (le mainframe) à l’aide des terminaux passifs se comportant en esclaves. C’est le serveur central qui prend en charge l’intégralité des traitements, y compris l’affichage qui est simplement déporté sur les terminaux passifs.

Avantages et limites

Cette architecture a comme avantages :
• Elle brille par sa grande facilité d’administration et sa haute disponibilité ;
• Elle bénéficie aujourd’hui d’une large palette d’outils de conception de programmation et d’administration ayant atteint un niveau de maturité et de fiabilité leur permettant encore de soutenir la comparaison avec des solutions beaucoup plus modernes ;
• La centralisation permet une utilisation optimale des ressources et se prête très bien à des traitements par lots.
Malgré les avantages qu’elle procure, elle a aussi des limites qui ont menés les chercheurs à des autres architectures plus évolués. Ces limites sont :
• Les applications sur site central souffrent d’une interface utilisateur (la partie présentation) en mode caractères car à cette époque les utilisateurs accédaient aux serveurs par des terminaux passifs généralement alphanumériques (le minitel en est un exemple) et par la suite avec quelques capacités graphiques.
• La cohabitation d’applications micro exploitant des données communes n’est pas fiable au-delà d’un certain nombre d’utilisateurs.
Il a donc fallu trouver une solution conciliant les avantages des deux premières :
• La fiabilité des solutions sur un site central, qui gèrent les données de façon centralisée,
• L’interface utilisateur moderne des applications sur micro-ordinateurs.
Ainsi est né le concept du client-serveur.

Architectures client/serveur

Cette évolution de l’architecture système a pour dessein de franchir les limites citées ci-dessus, c’est-à-dire une gestion centralisée des données à une grande performance de fiabilité et une gestion de l’interface utilisateur plus riche et conviviale. A cette époque, l’apparition du PC (Personal Computer) et le réseau local étaient le socle de cette évolution.

Généralités sur l’architecture Client-serveur

Selon Wikipedia : « L’environnement client-serveur désigne un mode de communication à travers un réseau entre plusieurs programmes ou logiciels : l’un, qualifié de client, envoie des requêtes ; l’autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et y répondent. Par extension, le client désigne également l’ordinateur sur lequel est exécuté le logiciel client, et le serveur, l’ordinateur sur lequel est exécuté le logiciel serveur. »
D’où, une modèle client-serveur s’exprime comme suit : tout processus utilisant des services offerts par un autre processus, et communiquant avec lui à l’aide de messages qui se présentent comme requête (ou resquest en anglais, envoyé par le client) ou réponse (ou reply en anglais, envoyé par le serveur).
Et si le découpage d’une application se fait sur une application de l’architecture Client-serveur, on peut avoir une model général que la figure :
Figure 1.02 Découpage générale d’une application client-serveur [5]

Les acteurs de l’architecture Client-serveur

Le réseau ou le réseau client-serveur

La présence d’un réseau n’est pas obligatoire dans la définition. On peut néanmoins considérer qu’une architecture C/S ne se construit qu’autour d’un réseau. Le modèle client-serveur est apparu grâce aux progrès technologiques qui ont permis de transformer les terminaux dépourvus d’intelligence, en de véritables ordinateurs avec une véritable capacité de traitement, de stockage, de présentation et de communication… Pour autant, quand un client fait appel à un serveur de base de données, par exemple, le serveur ne transmet pas toute la base de données au client (même si cela est envisageable, cette solution encombrerait beaucoup le réseau). En réalité, la situation la plus courante est que le client et le serveur se partagent le travail. Ce réseau est constitué de plusieurs stations dont la plupart sont des stations clients qui servent d’utilisateurs et d’autres, plus puissants, appelé serveurs qui sont dédiées à une ou plusieurs tâches spécialisées. Ces derniers doivent être véritablement multitâches afin de pouvoir servir un grand nombre de requêtes en même temps et de façon équitable.
L’avantage des réseaux Client-Serveur est de réunir deux avantages complémentaires : l’indépendance et la centralisation.
• L’indépendance : cela est exprimé par la facilité de changer une machine tombée en panne ou l’interchangeabilité.
• La centralisation : dans une organisation de type client-serveur, les fichiers sont généralement centralisés sur un serveur ; les utilisateurs « voient » le serveur mais ne « voient » pas les autres machines utilisateur, tout passe par l’intermédiaire du serveur. Dans un réseau de type client-serveur, les ordinateurs ne devront jamais avoir besoin des ressources d’une autre station, parce qu’ils ne pourront simplement pas y accéder. La totalité de l’architecture du réseau repose sur un ou plusieurs serveurs dédiés.

Le Client

En réalité, c’est le processus qui demande l’exécution d’une opération par l’envoi d’une demande, il est constitué d’un poste de travail disposant d’une interface utilisateur (graphique ou non). Il assure la gestion de l’interface graphique et l’envoi des requêtes au serveur. Le logiciel client n’est pas lié
à la machine qui le fait tourner, il doit être portable et mobile. De ce fait, l’espace client est souvent unique pour un utilisateur donné et sa localisation physique est en principe indéterminée.

Le serveur

C’est le processus qui exécute la demande du client et qui transmet la réponse, ou encore le terme SERVEUR fait référence à tout processus qui reçoit une demande de service (requête) venant d’un client via un réseau, traite cette demande et renvoie le résultat (réponse) au demandeur (le CLIENT). Voici quelques exemples de serveurs [5] :
• Serveur objet
Le serveur objet exécute la logique applicative auquel le client se connecte par l’intermédiaire d’un protocole d’objets distribués. Les objets qu’héberge ce serveur peuvent éventuellement être conditionnés sous la forme de composant.
• Moniteur transactionnel
Son but est de coordonner l’exécution de transactions distribuées sur plusieurs machines. Par exemple : si l’utilisateur veut à la fois réserver un avion et un hôtel, à l’aide d’une même application, alors l’application devra s’assurer que la transaction a lieu intégralement ou pas du tout. Le moniteur transactionnel sera alors très utile pour coordonner ces deux réservations simultanées et s’assurer de l’atomicité (ACID) de l’opération composée.
• Serveur web
Le serveur web selon le cas a un rôle de serveur de fichiers ou celui de middleware
• Serveur de sécurité
Le serveur de sécurité gère l’authentification des utilisateurs et le chiffrement des flux de communication. La norme LDAP (Lightweight Directory Access Protocol) mise en œuvre par Netscape à la fin des années 90, s’impose aujourd’hui comme le standard de serveur d’annuaire distribué. LDAP est ainsi au centre de tous les systèmes de sécurité à base de cryptage à clé public (PKI : Public Key Interface).

Le Middleware

Pour lier efficacement les différentes composantes d’une application client/serveur, il est parfois nécessaire d’avoir recours à des logiciels spécifiques : « les middlewares », Comme leur nom l’indique : ce sont des intermédiaires. Ils servent à simplifier le travail du développeur en se chargeant d’un point particulier. Ils sont de plusieurs types, les principaux étant :
• Les middlewares d’accès aux données :
Ils mettent en communication les applications avec les différentes sources de données d’une entreprise.
• Les ORB (Object Request Broker) :
Leur but premier est de rendre plus transparente la communication avec les applications situées sur des machines distantes grâce à ce qu’on appelle objets distribués (interopérabilités). Citer comme exemple : CORBA, DCOM, RMI.
• Les moniteurs transactionnels :
Leur fonction est de coordonner les transactions distribuées sur plusieurs machines ;
• Les Messages Oriented Middleware (MOM):
Il s’agit de serveurs intermédiaires dans la communication entre application.

Typologie technique

Pour comparer les architectures entre elles, le paragraphe qui suit s’attache à déterminer quelles sont les caractéristiques significatives d’une architecture client/serveur.

Type de données véhiculées (TDV)

Les éléments cités au découpage d’une application se communiquent entre eux via des protocoles ou des messages spécifiques qui vont donc engendrer des données véhiculées dans l’application, voici une figure qui montre quelques-unes de ces types [5] : Figure 1.03 Données véhiculées
De quelle nature est l’information qui circule entre le client et le serveur ?
• S’agit-il d’une information de présentation (interface HTML) auquel cas le client s’apparente à un terminal passif (il doit juste afficher ce qu’on lui envoie) ?
• Ou bien s’agit-il uniquement des données extraites d’une base SQL, auquel cas le client a pour responsabilités de déterminer comment afficher ces données ?
• Ces données représentent-elles des appels de fonction à distance (avec le protocole CORBA-IIOP par exemple) ?
• Ou enfin, ces données sont-elles des objets sérialisés, c’est à dire transformées en une série d’octets propre à être transmise au travers d’un réseau ?

Type de dialogue client/serveur

La figure 1.04 représente le type de dialogue client/serveur [5]
Figure 1.04 Dialogue client-serveur
Le HTTP est un protocole déconnecté : on demande une page HTML, le serveur web la renvoie (avec les éventuels fichiers qui s’y rattachent comme les images, ou des applets Java), et la communication est coupée. Comment obtenir un contexte transactionnel avec un tel protocole ? Par exemple : comment faire en sorte qu’un utilisateur puisse acheter des produits en ligne au travers de page HTML, et que chaque nouvelle page qu’il visite se souvienne de ce qu’il avait acheté lors des pages précédentes. A l’inverse, les protocoles tel que CORBA – IIOP – RMI – DCOM, ou plus simplement le protocole TCP sont dits connectés. A la manière d’une communication téléphonique, la ligne reliant les interlocuteurs est dédiée : le dialogue est interrompu explicitement soit par le client, soit par le serveur.

Structure et localisation des applicatifs

La figure 1.05 représente la structure et localisation des applicatifs [5]
Figure 1.05 Localisation des applicatifs
La centralisation des applicatifs est d’un attrait certain, car elle facilite la maintenance, le déploiement, la gestion des accès concurrent aux données, des transactions, etc. L’intégrisme centralisateur doit céder le pas à une réflexion plus rationnelle sur l’organisation du système d’information. Par exemple : certains métiers imposent la mobilité et l’autonomie, on doit travailler sans être connecté au serveur. Comment y parvenir s’il n’y a pas de code sur le poste client ?

L’architecture un tiers

Le terme client/serveur appliqué à ce type d’architecture présente des clients passifs qui n’exécutent rien. Le client ici se présente sous forme de terminal ou l’émulation de terminal. C’est le serveur qui héberge les applications. Dans ce type d’architecture, la logique applicative (métier) et les données sont concentrées en un seul point : « le site central ». Le client (c’est à dire le terminal) ne sert qu’à la visualisation et à l’insertion des données. Certains ouvrages ne classent pas ce type d’architecture comme architecture client-serveur mais de l’architecture centralisé [1] mais beaucoup d’ouvrage l’en parle comme une architecture client-serveur [3] [4] [5].
Figure 1.06 Architecture un tiers
Ce type de système d’information a fait ses preuves. Sûr, sécurisé, robuste, il satisfait parfaitement
à la première loi de l’informatique d’entreprise : « il faut que ça fonctionne ». La programmation est simple puisque l’accès aux données est généralement très bien intégré. En effet, l’avantage est de pouvoir travailler dans la mémoire d’un ordinateur puissant, particulièrement stable et qui est spécialement conçu pour le traitement de gestion : « le mainframe ». Le flux réseau entre le client et le serveur ne véhicule que des informations de présentation : de tableau de caractères ou maps 3270 par exemple.
Figure 1.07 Eléments constituants de l’architecture un tiers

L’architecture deux tiers

Ce type d’architecture est apparu avec la vague de PC du milieu des années 80. La loi de Grosh stipule qu’à puissances égales, plusieurs petites machines coûtent moins cher qu’une grosse. Pragmatique, les entreprises ont donc adhéré au PC. Cependant le mainframe n’est pas mort pour autant car il contenait déjà toute la logique applicative et toutes les données de l’entreprise. Opérer une migration intégrale vers les PC n’était pas envisageable. Ainsi un nouveau type d’architecture s’est développé autour du PC : « le client/serveur de données ». Le PC étant capable d’exécuter des traitements, pourquoi ne pas en profiter ?
Par conséquent, le serveur perd ces prérogatives, et n’est désormais utilisé qu’à la gestion des données. C’est l’avènement des SGBDR et des outils L4G (SQLWindows, PowerBuilder) qui permettent rapidement de développer des applications pour un PC avec accès aux données du serveur. Le client concentre ainsi l’ensemble de la logique applicative et communique au serveur à l’aide d’un langage de requête standardisé : « SQL ». Grâce au PC, les interfaces peuvent alors devenir beaucoup plus graphiques qui accroisse la qualité d’information disponible dans un même écran et améliore les possibilités de manipulation de données. Les GUI peuvent augmenter notablement la productivité des utilisateurs.
Figure 1.08 Architecture deux tiers
A peine dix ans plus tard le bilan est sans appel : le coût de maintenance de ce type d’architecture, démontré par la figure ci-dessus, est prohibitif. Par ailleurs, les déploiements à grande échelle sont complexes (en cas de mise à jour, il faut réinstaller l’application sur les postes clients). Ainsi le mainframe est resté indispensable et il a survécu à la vague des PC.
Bref, la nature des éléments constituant cette architecture est résumée par la figure 1.09 suivant :
Figure 1.09 Eléments constituants de l’architecture deux tiers

L’architecture trois tiers

Les débuts industriels de ce type d’architecture marquent le début des années 90. On commence à comprendre que la décentralisation intégrale des traitements vers les PC n’est pas forcément une bonne chose. Quelques portions de programme sous la forme de « procédures stockées » seront transférées progressivement sur le serveur. Mais le problème de déploiement et de la maintenance des applications reste presque inchangé. Certains éditeurs d’outils L4G prennent la mesure du problème et proposent la solution basée sur des serveurs d’applications : N AT STAR, PowerBuilder, Forte, … Ces serveurs hébergent des traitements appelés par des protocoles RPC propriétaires.
Figure 1.10 Architecture trois tiers
Le principe de cette architecture est simple, il ne s’agit plus de disposer le code à exécuter sur le client, mais plutôt sur un serveur tiers (appelé « serveur d’application », car il offre la possibilité d’exécuter des portions d’application). Ainsi, il est à la faveur du client de demander aux serveurs d’exécuter telle ou telle procédure. Le serveur effectue l’opération demandée puis retourne le résultat au client. Par ce le client est déchargé d’une bonne part des traitements. Par ailleurs, les données ne circulent presque plus qu’entre le serveur d’application et la base de données ce qui économise la bande passante réseau.

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 GENERALITES ET EVOLUTION DES ARCHITECTURES SYSTEMES
1.1 L’historique de l’évolution de l’architecture système
1.2 Généralités sur l’architecture système
1.2.1 Le découpage d’une application
1.3 Architectures centralisé
1.3.1 L’informatique centralisée
1.3.2 Présentation
1.3.3 Le principe de fonctionnement
1.3.4 Avantages et limites
1.4 Architectures client/serveur
1.4.1 Généralités sur l’architecture Client-serveur
1.4.2 L’architecture un tiers
1.4.3 L’architecture deux tiers
1.4.4 L’architecture trois tiers
1.4.5 L’architecture n-tiers
1.4.6 La classification du GARTNER-GROUP
1.5 Architecture Orientée Services (SOA)
1.5.1 Architecture Client-serveur et l’architecture orientée services
1.5.2 Quelques définitions
1.5.3 Les trois éléments majeurs de SOA
1.5.4 Le principe général de l’architecture orientée service
1.5.5 Avantages d’une architecture orientée service
1.5.6 Le SOA et le Web Services
1.6 Conclusion
CHAPITRE 2 LA TECHNOLOGIE WEB SERVICE
2.1 L’historique de la technologie web service
2.1.1 Du côté de la technologie web
2.1.2 Du côté de la technologie du système distribué
2.2 Définitions et principe du web service
2.2.1 Quelques définitions
2.2.2 Les avantages des web service
2.2.3 Fonctionnement d’un web service
2.3 Fondations des services Web
2.3.1 Les protocoles internet
2.3.2 La technologie XML
2.4 Type des web services
2.4.1 WS-SOAP
2.4.2 WS-REST
2.5 Sécurité des web service
2.5.1 Sécurité des WS de type SOAP [17][32][33]
2.5.2 Sécurité des WS de type REST
2.6 Comparaison entre WS-REST et WS-SOAP [48]
2.6.3 Avantages et inconvénients
2.6.4 La différence entre WS-SOAP et WS-REST
2.7 Conclusion
CHAPITRE 3 NOTION DE SOLFA
3.1 Généralités
3.1.1 Notion de son
3.1.2 La Voix
3.1.3 La musique
3.1.4 Le chant
3.2 Historiques de la notation musicale
3.3 Le solfa
3.3.1 Définition :
3.3.2 Les éléments constitutifs du solfa
3.3.3 Autres symboles utilisés en solfa et leurs significations
3.4 Conclusion
CHAPITRE 4 MISE EN OEUVRE DE L’APPLICATION
4.1 Introduction
4.2 Présentation du projet
4.2.1 Contexte
4.2.2 Solution proposée
4.3 Analyse des besoins
4.3.1 Expression des besoins
4.3.2 Identification des acteurs
4.4 Modélisation UML
4.4.1 Diagramme des cas d’utilisation
4.4.2 Diagramme d’activité
4.4.3 Diagramme de classe
4.5 Les fichiers outputs
4.5.1 Le fichier sf (.sf)
4.5.2 Le fichier de format MIDI (.midi)
4.5.3 Le fichier Excel
4.5.4 Le fichier Pdf
4.6 Modèle conceptuel de données
4.7 Phase de développements
4.7.1 Choix des outils de développements
4.7.2 Pourquoi Angularjs ?
4.7.3 Les technologies mise en oeuvre
4.7.4 Quelques modes de structuration prises
4.8 Présentation de l’application
4.8.5 L’inscription dans le web standard
4.8.6 L’interface d’authentification
4.8.7 L’éditeur
4.8.8 Le Client mobile
4.9 Conclusion
CONCLUSION GENERALE
ANNEXE
Le logiciel Lilypond
BIBLIOGRAPHIE

Télécharger le rapport complet