Présentation
EnglishAuteur(s)
-
Michel RIVEILL : Professeur à l’université de Nice - Sophia-Antipolis
-
Roland BALTER : Professeur à l’université Joseph-Fournier, Grenoble, Laboratoire SIRAC
-
Fabienne BOYER : Maître de conférences à l’université Joseph-Fournier, Grenoble, Laboratoire SIRAC
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleINTRODUCTION
Il existe plusieurs modèles d’organisation d’une application répartie. Citons, entre autres, les modèles à base d’échange de messages ou d’événements/réactions qui s’adaptent bien à des communications asynchrones ; le modèle client-serveur qui s’appuie sur une abstraction linguistique bien connue, l’appel de procédure synchrone ; les modèles utilisant la mobilité du code, par exemple des systèmes d’agents mobiles ; ou encore des modèles à objets répartis qui donnent au concepteur d’applications l’illusion d’une mémoire partagée d’objets distribués. Dans cet article, nous nous intéressons principalement au modèle client-serveur car il est aujourd’hui le plus répandu dans les produits industriels. Nous verrons cependant que la frontière entre les divers modèles d’organisation des applications réparties n’est pas étanche et que les applications réparties construites selon le modèle client-serveur empruntent assez souvent des propriétés et des mécanismes propres à d’autres modèles.
L’article développe le modèle client-serveur selon deux axes : un axe « environnement de développement » qui présente les outils de construction d’applications, en particulier l’appel de procédure à distance ; un axe « système » qui présente les principes de mise en œuvre de l’appel de procédure à distance dans un environnement distribué hétérogène. Ces services systèmes sont généralement regroupés dans une couche de logiciel interposée entre l’application et le système d’exploitation, habituellement désignée par le terme générique de « middleware ».
Le modèle client-serveur de base met en jeu un processus client, qui demande l’exécution d’un service, et un processus serveur, qui réalise ce service. Client et serveur sont localisés sur deux machines reliées par un réseau de communication. Ce modèle a été introduit pour mettre en œuvre les premières applications réparties (transfert de fichiers, connexion à une machine distante, courrier électronique, etc.), réalisées chacune par un protocole applicatif spécifique. Dans une seconde étape, une construction commune, l’appel de procédure à distance, a été introduite pour fournir un outil général pour la programmation d’applications client-serveur.
Nous avons volontairement regroupé dans cet article les deux modèles de communications synchrones existants, liant un processus client et un processus serveur : le modèle issu de la programmation procédurale permettant de réaliser des appels de procédure (ou de service) à distance (RPC : Remote Procedure Call) et son adaptation aux langages à objets qui permet de réaliser des appels de méthode à distance (RMI : Remote Method Invocation). Ces deux modèles utilisent des fondements communs et le second est une évolution naturelle du premier, imposée par le développement des langages à objets.
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
2. Environnement de développement pour RPC
Ce paragraphe est consacré à la programmation d’une application répartie selon le modèle client-serveur. Cela inclut bien entendu la programmation du client, la programmation du serveur et la programmation des échanges entre le programme client et le programme serveur. L’idéal serait de programmer tous ces aspects à l’aide d’un seul langage de programmation intégrant la distribution. Il y a eu de multiples tentatives pour définir un tel langage, en particulier en s’appuyant sur des langages à objets existants (C++ et Eiffel entre autres), qui se sont traduites par des prototypes expérimentaux.
Cette approche présente de nombreux avantages car, du fait de l’intégration de la distribution dans les concepts du langage, le traitement de la distribution devient élémentaire (voire inexistant) pour le programmeur d’applications. Le compilateur du langage génère directement le code des talons sans qu’il soit besoin de faire appel à un IDL. Par ailleurs, les bibliothèques associées au langage fournissent les mécanismes systèmes nécessaires à la mise en œuvre des appels distants.
En réalité, cette approche n’a pas connu le succès escompté pour deux raisons : l’obligation d’utiliser un langage donné (dans une forme non normalisée en raison des extensions dues à la distribution) et la difficulté à prendre en compte des applications existantes, écrites dans un langage quelconque. L’émergence récente du langage Java, intégrant dès sa conception la distribution (fonction RMI, § 4.3) constitue une étape significative vers un mode de programmation plus uniforme. La cohabitation avec des éléments d’applications écrits dans d’autres langages reste néanmoins un problème d’actualité pour les utilisateurs du langage Java.
Aucune hypothèse n’est ici faite sur la nature du langage de programmation du programme client et du programme serveur. Le rôle du langage...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Environnement de développement pour RPC
BIBLIOGRAPHIE
-
(1) - BIRREL (A.D.), NELSON (B.J.) - Implementing Remote Procedure Call. - ACM Transactions on Computer Systems, 2 (1), 39-59, fév. 1984.
-
(2) - RPC : Remote Procedure Call specification. - RFC 1050, avr. 1988.
-
(3) - OSADZINSKI (A.) - The Network File System (NFS). - Vol. 8. Computer Standards & Interfaces, Pays-Bas (1988).
-
(4) - ROSENBERG (W.), KENNEY (D.), FISHER (G.) - Comprendre DCE. - Addison-Wesley (1993). http://www.osf.org/dce
-
(5) - OSF DCE : Introduction to OSF DCE. - Révision 1.1. Open Software Foundation (1995).
-
(6) - The Common Object request Broker Architecture. - Révision 2.0. Object Management Group (1995). http://www.omg.org
-
...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive