Middleware

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

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.

Traduction[modifier | modifier le code]

Le terme middleware vient de l'anglais middle (du milieu) et software (logiciel). Diverses francisations ont été proposées :

Techniques[modifier | modifier le code]

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.

Échange de messages[modifier | modifier le code]

Article détaillé : Message-Oriented Middleware.

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[modifier | modifier le code]

Appel de procédure à distance[modifier | modifier le code]

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 (stub) 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 (marshalling)[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.

Manipulation d'objets[modifier | modifier le code]

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 (stub) 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 (skeleton). 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.

Transactions[modifier | modifier le code]

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 [7] (IBM) et DTC de Microsoft sont des middleware qui permettent la réalisation de transactions.

Interopérabilité entre les intergiciels majeurs : CORBA, RMI, DCOM[modifier | modifier le code]

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, suns 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.

CORBA[modifier | modifier le code]

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, ect.). À travers ce regroupement, il y a un object : 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 Brocker 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[modifier | modifier le code]

Le bus CORBA propose un modèle orienté objet client/serveur d'abstraction et de de-coopération entre les applications réparties :

  • La composante d’abstraction : Chaque application peut exporter certaines 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.
Modèle client serveur.png

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 a 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

Java RMI[modifier | modifier le code]

Microsoft COM/DCOM[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Sur les autres projets Wikimedia :

Articles connexes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • J.Aldrich, C.Chambers, and D.Notkin (2002) « ArchJava : Connecting SoftwareArchitecture to Implementation ». InProc. International Conference on SoftwareEngineering, pages 187–197. ACM Press
  • J.Aldrich, V.Sazawal, C.Chambers, and David Notkin (2003) « LanguageSupport for Connector Abstractions ». InProceedings 17th European Conferenceon Object-Oriented Programming (ECOOP)
  • R.Cerqueira, C.Cassino, and R.Ierusalimschy (1999) « Dynamic componentgluing across different componentware systems » ; Distributed Objects and Applications. Proceedings of the International Symposium on, pages 362–371,1999
  • A.Erbad, M.Blackstock, A.Friday, R.Lea, and J.Al-Muhtadi (2008), « MA-GIC Broker : A Middleware Toolkit for Interactive Public Displays ». InPER-COM’08 : Proceedings of the 2008 Sixth Annual IEEE International Conferenceon Pervasive Computing and Communications, pages 509–514, Washington, DC,USA, IEEE Computer Society.

Notes et références[modifier | modifier le code]

  1. (en) John Footen et Joey Faust, The Service-Oriented Media Enterprise: SOA, BPM, and Web Services in Professional Media Systems, Focal Press, 2008, (ISBN 9780240809779), chapitre 4 definition of a middleware
  2. (en) Daniel Serain et Iain Craig, Middleware and enterprise application integration: the architecture of e-business solutions, Springer - 2002, (ISBN 9781852335700), page 154
  3. (en) Gunjan Samtani et Marcus Healey,B2B integration: a practical guide to collaborative e-commerce, Imperial College Press - 2002, (ISBN 9781860943263)
  4. (en) Bill Blunden, Message passing server internals, McGraw-Hill Professional - 2003, (ISBN 9780071416382)
  5. (en) Gustavo Alonso, Web services: concepts, architectures and applications, Springer - 2004, (ISBN 9783540440086), page 55
  6. (en) Qusay H. Mahmoud, Middleware for communications, John Wiley and Sons - 2004, (ISBN 9780470862063), page 54
  7. http://publib.boulder.ibm.com/infocenter..