Intergiciel
Un article de Wikipédia, l'encyclopédie libre.
|
|
Cet article ou cette section doit être recyclé.
Une réorganisation et une clarification du contenu est nécessaire. Discutez des points à améliorer en page de discussion.
|
|
|
La forme ou le fond de cet article est à vérifier.
Améliorez-le, ou discutez des points à vérifier. Si vous venez d’apposer le bandeau, merci d’indiquer ici les points à vérifier.
|
|
|
Cet article ou cette section est sujet à caution car il ne cite pas suffisamment ses sources. (juin 2008)
Pour rendre l'article vérifiable, signalez les passages sans source avec {{Référence nécessaire}} et liez les informations aux sources avec les notes de bas de page. (modifier l'article)
|
En informatique, un intergiciel (en anglais middleware) est un logiciel servant d'intermédiaire de communication entre plusieurs applications, généralement complexes et distribuées sur un réseau informatique.
Sommaire |
[modifier] Vocabulaire
Le terme middleware vient de l'anglais middle (du milieu) et software (logiciel). Diverses francisations ont été proposées et intergiciel semble le terme le plus répandu :
- La Délégation générale à la langue française et aux langues de France (DGLF) préconise l'emploi de logiciel médiateur depuis 1999.
- L'Office québécois de la langue française (OQLF), quant à lui, propose le terme intergiciel.
- Les termes de logiciel d'intermédiation et, par abus de langage, de bus logiciel (voir aussi bus de données) peuvent être rencontrés dans la littérature.
[modifier] Description
L'intergiciel offre des services de haut niveau liés aux besoins de communication des applications (temps réel, sécurisation, sérialisation, transaction informatique, etc.)...
C’est ce que l’on appelle une communication interprocessus (anglais InterProcess Communication, IPC). Elle vient se situer dans le modèle OSI au dessus de la couche de transport (couches 5, 6 et 7). La double mission d’interfaçage de l'intergiciel est :
- Le processus client ou serveur : la gestion des appels de fonctions de l’application ou la gestion du renvoi des résultats.
- La mise en forme des données en vue de leur prise en charge par la couche transport.
Les deux missions sont assurées par deux composants distincts :
- Le Protocole d'accès formaté (Format And Protocol, FAP) met en forme les différentes données au niveau du réseau.
- L'interface de programmation (Application Programming Interface, API) se charge :
- des connexions et déconnexions avec le serveur;
- de la définition de l’environnement de la connexion (variables de contexte, zones tampon); et
- du transfert des requêtes et de la réception des résultats (n-uplet par n-uplet ou de façon globale).
L’interface de programmation transmet au FAP les requêtes destinées au serveur qui va se charger de conditionner les données au transport par le réseau. Le FAP est propre à chaque protocole réseau. Le FAP du client reçoit la requête et la plie dans une trame destinée au transport sur le réseau. La FAP du serveur reçoit la trame, la déplie et transmet la requête à l’interface. Après traitement, le serveur renvoie le résultat de la requête à l’interface qui transmettra au client via les FAP du serveur, puis du client, soit par n-uplet de résultat, soit en entier.
Exemples d'intergiciels : EAI, ETL, CORBA, HLA, file d'attente de message, pare-feu, ODBC, NEXUS.
L'intergiciel se situe "au-dessous" de l'applicatif, "au-dessus" du système d'exploitation et "entre" deux logiciels ayant besoin de communiquer entre eux !
Par exemple, le couple [SQL*Net + ODBC] forme un intergiciel.
Les intergiciels les plus en vogue dans les architectures dites trois tiers sont :
- les intergiciels "orientés objets ou composants distribués" : ce sont les ORB ou Object Request Broker
- les intergiciels "transactionnels" : ce sont les moniteurs transactionnels (comme CICS d'IBM, Tuxedo de BEA Systems, MTS de Microsoft, JTS de Sun, TopEnd de NCR ou encore Jaguar de Sybase, ...)
- les intergiciels "orientés messages" : ce sont les MOM (comme MQ Series d'IBM, JMS de Sun, MSMQ de Microsoft).
Une tendance se dégage également vers l'intégration des intergiciels "objets distribués" avec les "moniteurs transactionnels" (cas de Tuxedo qui fusionne avec l'ORB ObjectBroker pour constituer le produit M3 de BEA, cas également de l'offre COM+ de Microsoft) et former ainsi un ensemble rebaptisé pour l'occasion : serveur d'application. Voir également EAI.
L'accès aux données et aux services étant critique pour les entreprises, les serveurs d'application sont complétés par une couche d'accès aux données basées sur des standards Java (JDO, SDO) ou plus générale (ORM).
[modifier] Références
Voir : Intergiciel et Construction d'Applications Réparties, 12 juin 2008, Distribuée sous licence Creative Commons, à l'adresse : http://sardes.inrialpes.fr/ecole/livre/pub/Preface/preface.html
Ce livre est issu d'une série d'écoles d'été organisées sur le thème de l'intergiciel et de la construction d'applications réparties (Saint-Malo 1996, Autrans 1998, 1999, 2003 et 2006). La forme et le contenu de ces écoles se sont naturellement adaptés pour suivre l'évolution du domaine. Depuis 2003, l'école a pris le nom d'ICAR (Intergiciel et Construction d'Applications Réparties). Ce livre reprend largement le contenu de l'école ICAR 2006. Les annexes sont notamment inspirées d'ateliers organisés au cours de cette école. Nous tenons à remercier les organismes qui nous ont soutenus pour l'organisation d'ICAR 2006 : l'IMAG (Informatique et Mathématiques Appliquées de Grenoble), l'INRIA (Institut National de Recherche en Informatique et Automatique, unité de recherche de Rhône-Alpes), et ObjectWeb [ObjectWeb 1999], consortium développant des systèmes intergiciels en logiciel libre. Nous remercions également les organismes d'appartenance des organisateurs et intervenants d'ICAR 2006 : France Telecom R&D, INRIA, Institut National Polytechnique de Grenoble, Queensland University of Technology (Australie), Scalagent Distributed Technologies. Université Joseph Fourier, Université de Nice-Sophia Antipolis. Sans avoir directement participé à la rédaction, Alan Schmitt et Christophe Taton sont intervenus dans ICAR 2006. Danièle Herzog a assuré avec efficacité le soutien logistique de cette école. L'ouvrage a bénéficié d'interactions avec de nombreux collègues dont la liste serait trop longue pour n'oublier personne. Mentionnons néanmoins, parmi les intervenants et les organisateurs d'écoles précédentes, Daniel Hagimont (IRIT, Toulouse) et Philippe Merle (INRIA et LIFL, Lille).
Les organisateurs d'ICAR 2006 Noël De Palma (Institut National Polytechnique de Grenoble) Sacha Krakowiak (Université Joseph Fourier) Jacques Mossière (Institut National Polytechnique de Grenoble)
[modifier] Sources
[modifier] Anglophones
- Mise à jour sur l'origine du terme "middleware". par Ironick
- Ce qu'est un Middleware. Selon l'ObjectWeb.
- Middleware, selon université Carnegie Mellon.
- Qu'est qu'un Middleware? Selon le Middleware Resource Center (MRC).

