Prof : KONAN HYACINTHE MIDDLEWARE MASTER1 2019-2020 Page :.1 Chapitre 0 : Introduction 0.1 Problématique de la programmation répartie Permettre à un programme de s’exécuter sur plusieurs machines reliées par un réseau à large échelle (Internet) local (intranet) de plusieurs domaines de l’informatique : système d’exploitation (système d’exploitation répartis) réseau (librairies de programmation réseau) langage de programmation (langages de programmation étendus) Ceci implique : Un Environnement de programmation répartie qui emprunte des caractéristiques à ces 3 domaines Un nouveau paradigme de programmation : interaction client/serveur L’interaction client/serveur s’assimile à un appel procédural étendu au cas où appelant et appelé ne sont pas situés sur la même machine Page :.2 0.2. Client/Serveur Les environnements de programmation répartie permettent de mettre en œuvre les solutions client/serveur. le modèle client/serveur est la description conceptuelle de la communication entre un client qui émet une requête et un serveur qui traite la requête émise ; un système client/serveur est l’implantation physique et logicielle du modèle c/s ; une application client/serveur est une application développée au sein d’un système client/serveur. Client/Serveur 2 tiers Avantages • 1ère infrastructure informatique pour un travail coopératif • centralisation des traitements au niveau du serveur • pas de duplication de données • gestion simple de la cohérence et de l’intégrité des données • maîtrise globale des processus de travail (workflow) relativement simple Inconvénients • relation directe entre le client et le serveur • pas de transparence de localisation • modèle trop rigide qui n’assure pas l’évolutivité • souvent solutions propriétaires qui ne facilitent ni la portabilité, ni l’hétérogénéité, ni l’intéropérabilité Page :.3 Client/Serveur 3 tiers • Intermédiaire entre le client et le serveur de données • Localisation de la logique du traitement sur cet intermédiaire • L’intermédiaire gère l’accès à la (aux) bases de données Avantage : • meilleure répartition des charges Inconvénients : • mise en œuvre initiale + complexe • maîtrise des flux de traitements plus complexe 0.3. Environnement de programmation répartie (middleware). Le middleware désigne dans le cadre de l’informatique répartie, toutes les couches logicielles qui permettent à deux applications d’interagir à distance. • fournit aux applications une abstraction du système d’exploitation et du réseau • unifie l’accès à des machines hétérogènes • est indépendant du langage de programmation des applications On distingue aujourd’hui quatre grandes classes de Middleware : • l’exécution de transaction (Transactions Processing) qui est une classe de logiciel plutôt orienté “base de données” dont nous ne parlerons pas ici, • les RPC (Remote Procedure Calls) qui distribue l’exécution de routines sur un réseau (voir plus loin) ; Page :.4 • les MOM (Message Oriented Middleware) qui permettent l’échange de données entre applications (voir également plus loin) ; • et les ORB (Object Request Broker) qui permettent la distribution d’objets sur un réseau de machines (voir la description de CORBA). 0.4. Caractéristiques des environnements de programmation répartie • gèrent l’hétérogénéité des systèmes d’exploitation et des langages • fournissent un moyen standardisé de décrire les services fournis par les applications réparties • fournissent des protocoles d’intéropérabilité entre machines distantes • acheminent une requête entre un client et un serveur • fournissent des services qui permettent d’accélérer le développement des applications réparties • fournissent des outils de développement qui facilitent l’intégration des composants d’une application • toutes les plate-formes middleware existantes sont orientées objet - elles sont conçues selon une architecture objet - les entités qui composent les applications sont des objets Page :.5 Chapitre 1 : Généralités 1.1. Middleware En architecture informatique, un middleware (anglicisme) ou intergiciel est un logiciel tiers qui crée un réseau d'échange d'informations entre différentes applications informatiques. Le réseau est mis en œuvre par l'utilisation d'une même technique d'échange d'informations dans toutes les applications impliquées [1] à l'aide de composants logiciels. Les composants logiciels du middleware assurent la communication entre les applications quels que soient les ordinateurs impliqués et quelles que soient les caractéristiques matérielles et logicielles des réseaux informatiques, des protocoles réseau, des systèmes d'exploitation impliqués. Les techniques les plus courantes d'échange d'informations sont l'échange de messages, l'appel de procédures à distance et la manipulation d'objets à distance. Les middlewares sont typiquement utilisés comme ciment pour relier des applications informatiques disparates des systèmes d'information des entreprises et des institutions. 1.2 Traduction Le terme middleware vient de l'anglais middle (du milieu) et software (logiciel). Diverses francisations ont été proposées : La Délégation générale à la langue française et aux langues de France préconise l'emploi de logiciel médiateur depuis 1999. L'Office québécois de la langue française, quant à lui, propose le terme intergiciel. Les termes de logiciel d’inter-médiation et, par abus de langage, de bus logiciel (voir aussi bus de données) peuvent se rencontrer dans la littérature. Page :.6 Chapitre 2 : Techniques L'échange de messages, l'appel de procédures et la manipulation d'objets tiers sont trois techniques prises en charge par le middleware, qui permettent à des applications informatiques d'interagir, de coopérer et de se transmettre des informations. 2.1. Échange de messages Dans un middleware orienté message (Message Oriented Middleware ou MOM), les applications informatiques communiquent par échange de messages d'une manière similaire au courrier électronique : une application informatique émet un message qui est alors transmis à l'application destinataire par les composants logiciels du middleware pendant que l'application émettrice effectue d'autres traitements (asynchronisme). Le contenu du message est formaté par l'émetteur selon une convention préétablie puis analysé automatiquement par l'application destinataire conformément à cette convention. Le format de données XML est souvent utilisé pour les messages [2]. Le message peut être transmis à une application choisie par l'expéditeur, une liste d'applications abonnées ou toutes les applications qui exploitent le middleware. Les messages sont triés par priorité et placés dans des files d'attente (queue) par les composants logiciels du middleware [3]. Exemples de MOM AMQP (Advanced Message Queuing Protocol) est un protocole standard ouvert pour les MOM, dont dérive notamment récemment ØMQ (ou ZeroMQ). WebSphere MQ, de IBM, est un composant logiciel pour middleware orienté message. JMS est une interface de programmation pour middleware orienté message, OW2 JORAM étant un des logiciels qui mettent en œuvre cette interface. Page :.7 2.2. Appel de procédure à distance Avec un middleware basé sur les appels de procédure à distance (remote procedure call), des fonctions (procédures) existantes dans une application informatique donnée peuvent être exécutées sur demande par d'autres applications. L'appel de procédure à l'intérieur d'une application est un mécanisme logiciel ordinaire qui peut être réalisé avec n'importe quel langage de programmation procédural. Il en va autrement quand cet appel est réalisé entre deux applications. Dans le mécanisme d'appel de procédure à distance, les composants logiciels du middleware créent dans l'application appelante un composant logiciel souche dont les fonctions sont identiques à celles de l'application informatique appelée. Puis les appels de procédure effectués par l'application appelante sur la souche sont déviés par les composants logiciels du middleware vers l'application appelée dans laquelle les composants du middleware ont créé une autre souche semblable à l'appelant. Le résultat de l'exécution de la fonction est ensuite transmis de l'appelé vers l'appelant par les mêmes mécanismes. Les composants du middleware utilisent le procédé de sérialisation [4]. Le protocole réseau RPC de Sun Microsystems sert à effectuer des appels à distance. SOAP est une technique d'appels à distance sur des serveurs web basée sur XML et le protocole HTTP - protocole des serveurs web. Technique intermédiaire entre les appels de procédure à distance et la manipulation d'objets, RMI est un composant logiciel pour effectuer des appels de procédure à distance sur des objets en langage de programmation Java. Page :.8 2.3. Manipulation d'objets Avec un middleware à objets, une application informatique donnée peut manipuler les objets — de programmation orientée objet — d'une autre application. Ces manipulations induisent des traitements et des modifications d'informations dans l'application qui est propriétaire de l'objet en question. La manipulation d'objets par l'application à laquelle ils appartiennent est une opération ordinaire de programmation orientée objet. Les mécanismes nécessaires existent dans la totalité des langages de programmation orientés objet. Il en va autrement de la manipulation d'un objet appartenant à une autre application. Le mécanisme de manipulation d'objet tiers est similaire au mécanisme d'appel de procédure à distance : les composants du middleware créent dans l'application informatique qui exploite l'objet (client) une souche de celui-ci. Puis les manipulations effectuées sur la souche sont déviées par les composants du middleware vers l'application à laquelle appartient l'objet (fournisseur). Les composants du middleware créent dans l'application fournisseur un objet qui contient l'objet manipulé ainsi que les instructions nécessaires pour recevoir les manipulations (le squelette). Le squelette est réalisé en utilisant les mécanismes d'héritage de la programmation orientée objet [5]. DCOM de Microsoft est une technique de manipulation d'objets distants basée sur le protocole réseau RPC. DCE est un middleware à manipulation d'objet du Object Management Group basé sur CORBA, une technique standardisée du même auteur. 2.4. Transactions En informatique, une transaction est une suite d'opérations indissociables qui doivent être réalisées entièrement ou pas du tout. Divers composants de middleware permettent la réalisation de ces transactions. Ils permettent en particulier l'annulation totale de la transaction en cas d'échec [6]. CICS, IMS et MQ Series (IBM) et DTC de Microsoft sont des middlewares qui permettent la réalisation de transactions. Page :.9 Chapitre 3 : Interopérabilité entre les intergiciels majeurs : CORBA, RMI, DCOM L'interopérabilité entre logiciels est un concept informatique qui décrit la communication entre plusieurs applications indépendantes éditées sur des plateformes différentes et utilisées sur des ordinateurs différents. Cette interopérabilité se fait à travers des intergiciels (ou middlewares) qui permettent l'échange d'informations entre ces applications. Il y a de plus en plus de systèmes qui utilisent leur propre langage et qui sont différents sur de nombreux aspects. Par conséquent les intergiciels interviennent pour résoudre ce problème. CORBA, Oracle Java RMI et Microsoft COM/DCOM sont les applications les plus utilisées. Passer de la production de logiciel vers le milieu industriel (via les composants réutilisables) a été l'objectif premier du génie logiciel. 3.1. CORBA L'OMG (Object Management Group) est un regroupement de spécialiste informatique depuis 1989. Actuellement il y a environ 850 acteurs de ce groupe (IBM, NASA, LIFL, Alcatel, etc.). À travers ce regroupement, il y a un objet : faire émerger les standards pour l'intégration d'applications distribuées hétérogènes. L'élément clé de la vision de l'OMG est CORBA : un middleware orienté objet. CORBA (Common Object Request Broker Architecture) est basé sur une architecture d'appel-réponse. Ce bus d'objets répartis offre un support d’exécution masquant les couches techniques d'un système réparti. De plus il prend en charge les communications entre les composants logiciels formant les applications réparties hétérogènes. Modèle objet Client/Serveur Le bus CORBA propose un modèle orienté objet client/serveur d'abstraction et de coopération entre les applications réparties : La composante d’abstraction : chaque application peut exporter certains de ses services sous la forme d’objets CORBA ; La partie coopération : les interactions entre les applications sont alors matérialisées par des invocations à distance des méthodes des objets. Page :.10 Ce modèle d'objet intervient uniquement lors de l'utilisation d'un objet. On caractérise alors l'application implantant l'objet comme le serveur et l'application utilisant l'objet comme le client. Cependant il faut noter qu'une application peut être à la fois cliente et serveur. Sur le schéma précédent on voit différentes notions : L'application cliente : Programme qui utilise les méthodes objets via le bus CORBA La référence de l'objet : Structure qui désigne l'objet CORBA et permet de le localiser sur le bus. L'interface de l'objet : Ce qui définit les opérations et attributs de l'objet CORBA (utilisation du langage OMG-IDL) Le bus CORBA : Transfert les requêtes de l'application cliente vers l'objet L'objet CORBA : Entité virtuelle gérée par le bus CORBA. L'activation : Technique d'association d'un objet d'implantation à un objet CORBA Le code d'implantation : Regroupement des traitements liés à l'implantation de l'objet CORBA L'application serveur : Structure d'accueil des objets d'implantation et des exécutions des opérations Page :.11 3.2. Java RMI Remote Method Invocation, plus connu sous l'acronyme RMI est une interface de programmation (API) pour le langage Java qui permet d'appeler des méthodes distantes, sur le principe des ORB. L'utilisation de cette API nécessite l'emploi d'un registre RMI sur la machine distante hébergeant ces objets que l'on désire appeler au niveau duquel ils ont été enregistrés. Cette interface de programmation est très souvent utilisée en parallèle avec l'API d'annuaire JNDI ou encore avec la spécification de composants distribués transactionnels EJB du langage Java. Cette bibliothèque qui se trouve en standard dans Java J2SE, est une technologie qui permet la communication via le protocole HTTP (ou IIOP, depuis la version 1.3 du JDK) entre des objets Java éloignés physiquement les uns des autres, autrement dit s'exécutant sur des machines virtuelles java distinctes. RMI facilite le développement des applications distribuées en masquant au développeur la communication client / serveur. Cette bibliothèque entre en concurrence avec la norme CORBA maintenue par l'Object Management Group, et les produits qui la respectent, ou avec la technologie RPC dont l'un des acteurs est Microsoft. 3.3. Microsoft COM/DCOM DCOM (Distributed Component Object Model) est un ensemble de concepts Microsoft et d'interfaces de programmes dans lequel les objets de programme client peuvent demander des services à partir d'objets de programme serveur sur d'autres ordinateurs dans un réseau. DCOM est basé sur le "Component Object Model"(COM), qui fournit un ensemble d'interfaces permettant aux clients et aux serveurs de communiquer dans le même ordinateur (qui exécute Windows 95 ou une version ultérieure). Page :.12 Chapitre 4 : Les langages vus comme middleware Pour l’utilisateur qui ne souhaite pas “mélanger” différents langages lors du développement de ses applications la solution middleware-langages peut être une option intéressante. Certains langages fournissent en effet de façon native des services de type middleware. Là encore, les solutions vont du plus simple au plus complique. Nous allons rapidement examiner quelques exemples. 4.1 Ocaml Object CAML est un langage de la famille ML (Meta Language). Il s’agit donc d’un langage de type fonctionnel, mais disposant d’extensions impératives et d’extensions objet. C’est actuellement le standard pour l’enseignement de l’informatique en France dans les classes préparatoires, les DEUG et aussi beaucoup d’écoles d’ingénieurs. CAML possède la propriété intéressante de reposer sur un modèle théorique “propre” (le lambda calcul type) qui permet d’employer un typage fort et automatique, invisible pour l’utilisateur qui n’a jamais besoin de déclarer les variables. Le système de typage de CAML permet un codage des structures de données (quel que soit leur type, leur complexité et leur niveau d’imbrication) en chaîne d’octets, de façon totalement transparente. Ces chaînes peuvent être transférées sur le réseau et immédiatement décodées par une autre application CAML de façon tout aussi transparente. Le typage de données est cependant implicite ; comme en XDR, l’application recevant les données doit connaître à l’avance le type de la donnée qu’elle reçoit. 4.2 JAVA JAVA est un autre exemple de langage pouvant s’utiliser comme middleware. Il s’agit d’un langage possédant des caractéristiques procédurales et objets, relativement proches de C++ (en nettement plus “propre”, heureusement). En JAVA, le code (et pas seulement des données) est portable d’une machine et d’un système d’exploitation à un autre grâce au principe du bytecode et de la machine virtuelle JAVA. Le bytecode est une technique ancienne, puisqu’elle remonte au moins au Pascal développé à l’UCSD (University of California San Diego) et qui fut utilisé par exemple sur l’Apple II au début des années 80. Il n’est peut-être pas inutile de rappeler quelques notions de base sur les langages de programmation ; un langage peut en effet être : Page :.13 interprété : il s’agit de langages comme les langages de script (sh, awk, perl, php). Un interpréteur de commandes lit le fichier source et l’exécute au fur et à mesure. Le code est donc complètement portable puisqu’il reste en permanence en format source, mais l’exécution est lente, et les erreurs ne peuvent être détectées qu’à l’exécution. compile : un programme spécial, le compilateur, transforme le fichier source en code machine directement exécutable par le processeur. Ce code est beaucoup plus rapide, et beaucoup d’erreurs vont être éliminées par le compilateur, mais le code obtenu n’est pas portable d’une machine à l’autre. Le bytecode est une technique intermédiaire entre interprétation et compilation. Comme pour un langage compile, le code source est transformé par un compilateur, qui le vérifie et élimine les erreurs. Mais le résultat n’est pas du code machine directement exécutable par le processeur, mais un code intermédiaire, le bytecode, qui sera lui interprété par une machine virtuelle. Cette machine va dépendre du processeur, du système d’exploitation, etc. En revanche, le bytecode va lui rester indépendant des architectures physiques. Il existe ainsi une machine virtuelle JAVA par type de machine et de système d’exploitation, mais le code JAVA peut se “déplacer” sur le réseau de façon totalement transparente. C’est ce qui en a fait le langage de choix pour la programmation des applications du WEB. Le développeur du code place sur son site un code (l’applet JAVA) qui va être téléchargé dans le navigateur et exécuté localement par la machine virtuelle JAVA. JAVA peut donc être utilisée aussi comme middleware. Page :.14 Conclusion L’idée force que nous souhaitons voir se dégager de ce document est à la fois la grande variété des middlewares disponibles et surtout la grande diversité des fonctionnalités qu’ils peuvent fournir. Il faut donc bien comprendre que le choix d’un middleware, ou d’un type de middleware, doit se faire à partir des besoins exprimés. Employer un protocole UDP avec un codage ASCII pour déclencher des procédures différentes avec des types de données variables conduira certainement à des problèmes de développement et d’évolution des applications. Mais, de la même façon, utiliser un système de distributions d’objets pour échanger quelques messages en format fixe entre applications sera tout aussi inutile et surtout coûteux en terme de développement et de maintenabilité. Il n’y a pas de solution unique, mais des solutions adaptées aux besoins. Il faut aussi se méfier d’idées toutes faites et techniquement fausses comme “il suffit d’employer le même middleware pour être interopérable”, ou “l’emploi de middlewares différents interdit l’interopérabilité”, etc. La mise en relation de logiciels conçus par des équipes différentes ne sera simple que si les APIs et/ou les IDLs des procédures ou objets à mettre en commun ont été identifiés dès l’origine et de façon commune. Dans le cas contraire, il faudra de toute façon repenser la connexion en termes de middleware, et en fonction du couplage, choisir une mode de connexion adapté qui ne sera pas nécessairement celui employé pour le développement interne, surtout si le niveau de couplage est faible. Les arguments développés par les vendeurs de middleware dans ce domaine sont tendancieux, et largement démentis par l’expérience. Il faut là aussi se garder des effets de mode et savoir baser ses choix sur une solide connaissance technique et un ordinaire bon sens. Page :.15 Lexique MOM : XML : IBM : SOAP : HTTP : DCOM : RPC : CORBA : ORB : Message Oriented Middleware, middleware s’occupant essentiellement de passages de messages entre applications. Exemples : MPI, PVM eXtended Markup Language (1998) ; la finalite de XML est comparable ´ a celle ` de SGML : c’est un meta-langage pour fabriquer des langages de donnees a ` balises ; XML a simplifie la logique SGML et fig é la syntaxe de base pour écrire ´ les donnees. XML devrait devenir le langage d’echange des donn ées sur le Web, ´ en remplaçant progressivement HTML. International Business Machine, dit aussi Big Blue, firme fondee par Herman ´ Hollerith, qui fabriqua d’abord des machines pour cartes perforees, avant de ´ commencer a fabriquer des ordinateurs ` a la fin des ann ées 40 (les mod éles 701,702, ` 704). Contrairement a une id ée reçue, c’est UNIVAC qui r éalisa les premiers or- ´ dinateurs commerciaux, et non IBM Simple Object Access Protocol, protocole leger bas é sur XML pour la des- ´ cription des donnees, et s’articulant autour de HTTP. Hyper Text Transfer Protocol, protocole de transfert pour les fichiers HTML, base de fonctionnement des clients/serveurs sur le Web middleware Microsoft. Voir COM Remote Procedure Call, modele consistant ` a distribuer les proc édures sur un ´ reseau, et ´ a permettre leur appel depuis n’importe quelle machine. Il en existe ` deux grandes implantations, celle faite par Sun et celle de DCE Common Object Request Broker Architecture, voir definition d étaill ée dans ´ le texte Object Request Broker, el ément central de l’architecture CORBA, assurant les ´ communications et les synchronisations entre objets. Depuis la norme Corba 2, les ORB peuvent eux-meme communiquer entre eux (en principe) ˆ Page :.16 Notes et références [1 John F. et Joey F.] [2 Daniel S. et Iain C.] The Service-Oriented Media Enterprise: SOA, BPM, and Web Services in Professional Media Systems, Focal Press, 2008, (ISBN 9780240809779), chapitre 4 The Definition of Middleware. Middleware and enterprise application integration: the architecture of e-business solutions, Springer - 2002, (ISBN 9781852335700), page 154 [3 Gunjan S. et B2B integration: a practical guide to collaborative eMarcus H.] commerce, Imperial College Press - 2002, (ISBN 9781860943263) [4 Bill B.] Message passing server internals, McGraw-Hill Professional - 2003, (ISBN 9780071416382) [5 Gustavo A.] Web services: concepts, architectures and applications, Springer - 2004, (ISBN 9783540440086), page 55 [6 Qusay Middleware for communications, John Wiley and Sons H. Mahmoud] - 2004, (ISBN 9780470862063), page 54 Page :.17
