Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Qu'est-ce qu’un Middleware ?

Qu'est-ce qu’un Middleware ?

Un middleware est un logiciel qui permet à différentes applications d’échanger et d'interopérer.

Un middleware permet aux applications d'interopérer y compris lorsqu'elles tournent sur des serveurs différents, interconnectés par un réseau. Le middleware est un outil de haut niveau, puisqu’il offre ses services aux applications, mais les échanges induits s’appuient sur toute une pile de protocoles réseau.

Par exemple, les outils qui permettent à des applications d'invoquer les services d'un SGBD sont une catégorie particulière de middlewares.

Parmi les middlewares qui permettent l'interopérabilité entre applications homologues (de même nature), on peut distinguer deux grandes familles:

  • Les middlewares qui permettent l'invocation synchrone de fonctions et méthodes, parmi lesquels on trouve la famille des request brokers, avec CORBA ou encore DCOM.
  • Les middlewares d'échange asynchrones, qui sont principalement à base de messages, ce sont les MOMs, les Message Oriented Middleware.

Un middleware est davantage qu'un simple protocole d'appel des services offerts par une application, et typiquement RPC, RMI ou bien SOAP, tous également synchrones, ne sont pas vraiment considérés comme des middlewares.

middleware_shema

Outre la gestion de l’échange proprement dit, les services offerts par un middleware peuvent être de différentes natures, en particulier:

  • L'identification et la localisation des applications à un niveau supérieur, au dessus des adresses réseau et des noms de serveurs, et l'acheminement des échanges à ce niveau.
  • Dans certains cas, la conversion de formats de représentation des données entre les applications, permettant à des applications d'environnements et langages différents d'échanger de manière transparente.
  • Dans certains cas également, des fonctions de sécurité, de répartition de charge ou de gestion du secours.

Pourquoi des échanges asynchrones ?

Lorsqu'une application invoque les services d'une autre application au moyen d'un middleware synchrone, il faut impérativement :

  • que la seconde application soit en état de marche, à l’instant où elle est invoquée ;
  • qu'elle soit joignable par le réseau.

Si l'une ou l'autre de ces conditions n'est pas réunie, la première application doit renoncer à invoquer le service distant. Dans certains cas, cette impossibilité peut avoir des conséquences graves pour l'application initiatrice de l’échange, qui doit être prévue pour traiter l’échec de l’appel. L'invocation synchrone d'un service distant crée une dépendance très forte entre les deux applications.

Et quand bien même ces deux conditions sont réunies, la question se pose encore du temps de réponse de cet appel de service. L'application appelante peut-elle rester en attente de la réponse ? Peut-elle faire attendre un utilisateur ? Après combien de temps doit-elle renoncer ?

Dans certains contextes, les échanges synchrones sont possibles. En particulier lorsque les deux applications sont sur le même serveur, ou à la rigueur sur la même plateforme, et que leurs temps de réponse peuvent être garantis.

Dans tous les autres cas, la dépendance qu'implique un mode d’échange synchrone, tant au niveau des applications elles-mêmes que des serveurs, est néfaste.

Au contraire, avec un middleware asynchrone, l’application initiatrice de l’échange ne reste pas en attente d’une réponse : elle confie son message au middleware et poursuit sont traitement.

On dit qu'un middleware asynchrone met en œuvre une faible dépendance, un couplage lâche (« loose coupling »), entre les applications, ce qui permet une bien plus grande flexibilité dans les architectures.

Les Middleware Orientés Messages, ou MOM, sont de loin les implémentations les plus courantes du principe d'échanges asynchrones et, comme nous le verrons, il existe un standard en la matière, la spécification JMS, qui a un bon nombre d'implémentations de qualité.