là - POM

Qu’est-ce que le “Middleware”
JM Alliot
13 mars 2003
1 But et origine
La d´ efinition du Middleware g´ en´ eralement admise est la suivante :
Un Middleware est un logiciel de communication qui permet ` a plusieurs
processus s’ex´ ecutant sur une ou plusieurs machines d’interagir ` a travers
un r´ eseau.
La d´ efinition est donc assez vague. La notion d’utilisation de machines en r´ eseau
remonte au projet Whirlwind, ` a la fin des ann´ ees 40. Whirlwind fut un calculateur
d´ evelopp´ e par l’´ equipe de Jay Forrester (MIT) qui fut utilis´ e pour le dispositif de
d´ efense SAGE (Semi Automatic Ground Environment). SAGE avait pour but de sur-
veiller de fac¸on automatique l’espace a´ erien am´ ericain contre les intrusions des bom-
bardiers sovi´ etiques. SAGE fut une mine d’innovation technologique : stylos lumineux,
temps r´ eel et surtout modems furent d´ evelopp´ es dans le cadre de ce projet. En effet, les
56 calculateurs r´ epartis sur le territoire am´ ericain devaient interagir en temps r´ eel. La
premi` ere application civile de cette technologie fut le syst` eme SABRE de r´ eservation
d´ evelopp´ e pour les compagnies a´ eriennes par IBM en 1964.
La deuxi` eme grande ´ etape fut l’arriv´ ee des r´ eseaux rapides locaux (LAN). Le
d´ eveloppement d’Ethernet sous l’impulsion de Xerox dans les ann´ ees 70 permit de dif-
fuser plus largement les syst` emes de machines en r´ eseaux locaux. De la mˆ eme fac¸on, le
d´ eveloppement d’ARPANET (qui allait devenir INTERNET) dans les mˆ emes ann´ ees
posa de mani` ere plus aig¨ u le probl` eme des communications inter-machines et de l’in-
terop´ erabilit´ e.
Une autre grande ´ etape fut l’apparition formelle, au d´ ebut des ann´ ees 80, du mod` ele
client-serveur. Ce mod` ele, qui consiste ` a avoir une application (le serveur) qui fournit
des services ` a des clients, a ´ et´ e largement popularis´ e, par exemple, dans le syst` eme
graphique X-Windows d´ evelopp´ e au MIT. Bien d’autres applications r´ epondent au-
jourd’hui ` a ce mod` ele client serveur; en particulier, les syst` emes de montage de fichiers
NFS, les serveurs de fichiers FTP, les serveurs WEB (serveurs http), etc.
On distingue aujourd’hui quatre grandes classes de Middleware : l’ex´ ecution de
transaction (Transactions Processing) qui est une classe de logiciel plutˆ ot orient´ e “base
de donn´ ees” dont nous ne parlerons pas ici, les RPC (Remote Procedure Calls) qui
distribue l’ex´ ecution de routines sur un r´ eseau (voir plus loin), les MOM (Message
oriented Middleware) qui permettent l’´ echange de donn´ ees entre applications (voir
´
egalement plus loin), et les ORB (Object Request Broker) qui permettent la distribution
d’objets sur un r´ eseau de machines (voir la description de CORBA).
1

2 Le mod` ele OSI
Le mod` ele OSI (Open System Interconnection) est une norme ISO (Internatio-
nal Organization for Standardization) qui a pour but de s´ eparer les diff´ erents niveaux
(du niveau physique brut au niveau applicatif) li´ es ` a l’interconnexion des syst` eme. La
norme OSI r´ ealise ainsi un d´ ecoupage en 7 couches :
couche 1 (physique) : appareillage ´ electrique, cartes
couche 2 (liaison) : contrˆ ole de la couche physique, gestion des erreurs
couche 3 (r´ eseau) : routage des donn´ ees, recherche du meilleur chemin
couche 4 (transport) : gestion de l’envoi de donn´ ees
couche 5 (session) : maintien de synchronisation, coordination des communications
couche 6 (pr´ esentation) : conversion des donn´ ees ´ emises/rec¸ues
couche 7 (application) : applications utilisant les propri´ et´ es d’interconnexion
Notons cependant que le plus grand r´ eseau du monde (l’Internet) ignore royalement
le mod` ele OSI; le protocole TCP/IP, par exemple, est ` a cheval sur les couches 3
(r´ eseau/routage assur´ ee par IP (Internet Protocol)) et la couche 4 (transport, assur´ ee
par TCP (Transfer Control Protocol)). Notons ´ egalement que nous aurons bien du mal
`
a trouver la couche 5 (session) dont les fonctionnalit´ es sont souvent assur´ es par les
applicatifs eux-mˆ emes (couche 7) : par exemple, le protocole de transfert de fichier
FTP s’appuie sur TCP/IP, mais est ` a cheval sur les couches 5, 6 et 7. Il existe tr´ es peu
d’exemple de protocoles normalis´ es de la couche 5 sur Internet1.
La norme OSI est donc un mod` ele commode auquel nous nous r´ efererons, mais
n’est pas un standard de fait. Ainsi, lorsque nous citons une couche OSI pour les
diff´ erents protocoles pr´ esent´ es ci-dessous, il ne s’agit en aucun cas d’un protocole
standardis´ e pour cette couche, mais plutˆ ot d’un moyen de fixer les id´ ees par rapport
`
a l’´ echelle OSI.
3 Le transport des donn´ ees (couche 4 OSI)
Lorsque des machines discutent entre elles, il leur faut choisir un mode de commu-
nication (qui serait situ´ e “environ” au niveau de la couche transport de la norme OSI).
Nous allons presenter rapidement les deux modes employ´ es sur le r´ eseau Internet : le
mode TCP/IP (Transfer Control Protocol over Internet Protocol) et le mode UDP (User
Datagram Protocol).
Pour faire simple, le mode TCP est un mode point ` a point. Une machine parle ` a une
seule autre machine, en priv´ e. La communication est bidirectionnelle.
Le mode UDP ressemble plutˆ ot ` a un ensemble de personnes r´ eunis dans une pi` ece
qui hurlent au lieu de parler. Tout le monde peut entendre tout le monde. En revanche,
il faut savoir trier et organiser l’information, et s’assurer que le message est bien arriv´ e.
Le format des informations qui transitent que ce soit en mode TCP ou en mode
UDP d´ epend totalement des couches qui se trouvent au dessus dans le mod` ele OSI.
En particulier, c’est la couche pr´ esentation, qui d´ efinira l’encodage des donn´ ees en
utilisant une des m´ ethodes d´ ecrites dans la section suivante.
1Les raisons de ce ph´
enom` ene sont historiques. La norme OSI a ´ et´ e d´ efinie ` a la fin des ann´ ees 70, et
s’est voulu une remise au net des concepts d’interconnexion, alors que l’Internet et ses protocoles existaient
depuis le d´ ebut des ann´ ees 70.
2

4 La pr´ esentation des donn´ ees (couche 6 OSI)
Tant qu’un processus s’ex´ ecute sur une seule et mˆ eme machine, la fac¸on dont les
donn´ ees sont repr´ esent´ ees int´ eresse fort peu l’utilisateur. Les choses viennent ` a changer
d` es que l’on essaie d’´ echanger des donn´ ees entre deux machines.
L’exemple le plus classique et sans doute le plus simple ` a comprendre est celui de
la repr´ esentation des entiers. Il existe encore aujourd’hui deux grandes familles de pro-
cesseurs : ceux qui repr´ esentent les entiers en format dit “little endian” et ceux qui les
repr´ esentent en format “big endian”. Pour comprendre la diff´ erence, il faut s’int´ eresser
(un peu) ` a l’architecture physique des machines : l’unit´ e de base en informatique est
le bit (0 ou 1). Aujourd’hui, l’unit´ e de base de la m´ emoire d’un ordinateur est l’octet,
qui est un bloc de 8 bits. On ne peut repr´ esenter avec 8 bits que les valeurs de 0 ` a 255
(28). Pour repr´ esenter des valeurs plus importantes, il faut combiner plusieurs octets
entre eux. Avec deux octets, on arrive ainsi ` a 65536 (2562), etc. Ces deux octets sont
plac´ es physiquement dans la m´ emoire de la machine l’un derri` ere l’autre, mais suivant
le type du processeur, ils ne seront pas plac´ es dans le mˆ eme ordre. Ainsi, par exemple,
sur les processeurs Intel (PC), le nombre 1026 (4×256 + 2) sera repr´ esent´ e par l’octet
00000100 (4) ` a l’adresse 1 de la m´ emoire et l’octet 00000010 (2) ` a l’adresse 0 (tech-
nique de codage “little endian” : l’octet dit de poids faible, c’est ` a dire celui qui a le
moins d’importance, est plac´ e` a l’adresse la plus faible). L’ordre sera invers´ e sur un
processeur SPARC (Sun) o` u l’on aura 00000010 suivi de 000001002.
Supposons maintenant que notre PC envoie le nombre 1026 “brut de fonderie” ` a
notre machine Sun ` a travers un r´ eseau quelconque sans se pr´ eoccuper de la repr´ esentation
des donn´ ees. 1026 qui valait bien 4×256 + 2 sur notre machine PC va maintenant ˆ etre
interpr´ et´ e comme 2×256 + 4 = 514 sur notre Sun, puisqu’il est “dans le mauvais
sens”.
Il existe plusieurs fac¸ons de r´ esoudre ce probl` eme, allant du simplissime (mais
limit´ e) ` a la (petite) usine ` a gaz plus puissante.
4.1 L’encodage ASCII et XML
Les caract` eres imprimables sont tous repr´ esent´ es sur un octet par un code d´ efini par
la norme ASCII (ainsi le A majuscule est repr´ esent´ e par le nombre 65). La norme AS-
CII ´ etant aujourd’hui extrˆ emement r´ epandue (il existe cependant encore quelques ma-
chines utilisant la vieille norme EBCDIC), l’id´ ee consistant ` a prendre tout simplement
la repr´ esentation ASCII d’un nombre, ` a la transmettre, puis ` a la r´ ecup´ erer et la recoder
`
a l’autre bout, est venue tout naturellement ` a l’esprit, d’autant que les proc´ edures de
codage/d´ ecodage sont disponibles sur toutes les machines, puisqu’elles sont aussi uti-
lis´ ees pour saisir les chiffres rentr´ es par les utilisateurs, ou pour imprimer les r´ esultats
d’un programme. Cette proc´ edure simple peut ˆ etre suffisante dans nombre de cas, mais
pr´ esente aussi certains inconv´ enients :
– Le typage est totalement perdu; l’application qui d´ ecode ` a l’autre bout doit sa-
voir exactement quelles donn´ ees vont lui ˆ etre envoy´ ees (entiers, entiers longs,
entiers courts, flottant simple, chaˆ ıne de caract` ere, etc), sous peine de se tromper
compl` etement dans le d´ ecodage. On peut certes rajouter un protocole indiquant
le type de donn´ ees transmises (on envoie d’abord un 1, par exemple, lorsque l’on
va envoyer un entier cod´ e par un caract` ere, un 2 pour en entier cod´ es par deux
2Nous ´
evitons dans cette exemple tous les probl` emes annexes, comme celui de la taille des entiers : sont-
ils cod´ es avec 2, 3 ou 4 ou plus d’octets, etc. Nous y revendrons, mais nous avons suppos´ e ici qu’un entier
´
etait cod´ e sur 2 octets.
3

caract` eres, un 3 pour trois caract` eres, etc), mais le protocole devient alors plus
complexe. On peut aussi rajouter des s´ eparateurs, mais la proc´ edure de d´ ecodage
est plus difficile, et l’on commence ` a perdre les avantages de la simplicit´ e du
protocole (c’est la solution adopt´ ee avec le balisage XML).
– Pour certains types de donn´ ees (en particulier les flottants), le codage/d´ ecodage
ASCII introduit une perte de pr´ ecision, minime certes, mais suffisante pour en-
traˆ ıner des erreurs de calculs, surtout dans les probl` emes mal conditionn´ es.
Il faut cependant noter que l’encodage ASCII est aujourd’hui tr` es utilis´ e` a travers
le protocole XML. XML est un avatar direct de SGML (Standard Generalized Markup
Language). SGML est un standard d´ evelopp´ e au d´ ebut des ann´ ees 80 (norme ISO-
8879). Il d´ erive d’un produit IBM (GML) et du c´ el´ ebrissime et encore bien vivant TEX
de Donald Knuth. SGML d´ efinit ce que l’on appelle les langages ` a balises (Markup
Language). L’id´ ee qui se trouve derri` ere les langages ` a balisage (c’est ainsi que l’on tra-
duit g´ en´ eralement Markup Language) est une forme de r´ eaction contre le WYSIWYG
(What You See Is What You Get). Plutˆ ot que de repr´ esenter la forme d’un document
directement sur l’´ ecran, on le d´ ecrit par des balises, qui vont indiquer les d´ ebuts de cha-
pitre, de paragraphe, les ´ enum´ erations, etc, mais on ne se pr´ eoccupe jamais de la fac¸on
dont le document lui-mˆ eme sera repr´ esent´ e. L’application la plus c´ el` ebre de SGML
est HTML (Hyper Text Markup Language) qui est le langage standard d’´ ecriture des
documents pour le Web.
Le principe d’utilisation de XML (ou SGML) est simple. On commence par ´ ecrire
un DTD (Definition Type Document) qui d´ ecrit la syntaxe admissible pour les futurs
documents que l’on ´ ecrira. Il s’agit d’une sorte de grammaire que devra respecter le
futur document. Une fois cette grammaire ´ ecrite, on peut faire transiter les informa-
tions dans un format qui la respecte. De fac¸on assez int´ eressante, le DTD est lui-mˆ eme
un document de type XML. C’est ensuite l’application qui ` a la charge de relire le
document et de l’interpr´ eter. C’est ce qui explique par exemple les diff´ erences de vi-
sualisation entre les diff´ erents navigateurs Internet. La norme HTML (qui est en fait un
DTD) d´ ecrit simplement la grammaire ` a respecter, mais pas la fac¸on dont on doit in-
terpr´ eter cette grammaire. On peut ` a l’aide de XML d´ ecrire ` a peu pr` es tous les types de
donn´ ees possibles (avec les restrictions li´ ees aux donn´ ees cod´ ees en ASCII concernant
la perte de pr´ ecision, comme indiqu´ ee dans le XML Schema Part 2), mais on est loin
de l’efficacit´ e d’un ASN.1.
4.2 Le m´ ecanisme XDR
XDR (eXternal Data Representation) est un standard de codage d´ evelopp´ e par Sun
au d´ ebut des ann´ ees 80. Il est formellement d´ efini par la RFC31832. Il correspond ` a
peu pr` es exactement ` a la couche 6 du mod` ele OSI.
XDR se situe ` a un niveau d’abstraction plus ´ elev´ ee que le simple codage ASCII.
Il s’agit en fait d’un langage de description de donn´ ees. XDR s’implante sur chaque
machine sous la forme d’une librairie (un ensemble de routines) qui assure le codage
et le d´ ecodage des donn´ ees. XDR n’entend pas permettre la repr´ esentation de tous les
types de donn´ ees; certains choix ont ´ et´ e faits : on suppose entre autre que les octets ont
des repr´ esentations uniques, on ne sait pas encoder les champs de bits ou les nombres
BCD (Binary Coded Decimals), on code toutes les donn´ ees en multiples de 4 octets,
etc. Cependant, XDR permet d’encoder la plupart des structures de donn´ ees de lan-
gages proc´ eduraux traditionnels (C, ADA, Pascal, etc). Pour utiliser la librairie XDR,
3Request For Comments
4

il suffit que le programmeur d´ ecrive dans un fichier ASCII ses structures de donn´ ees
en utilisant des d´ eclarations proches de celles du C ou du Pascal.
XDR a connu un tr` es important d´ eveloppement. Il est utilis´ e dans de nombreuses
applications, par exemple pour le codage des donn´ ees des RPC (Remote Procedure
Calls dont nous reparlerons), et donc dans le protocole NFS (Network File System).
Notons que le typage des donn´ ees dans XDR est implicite : le passage sur le r´ eseau
fait disparaˆ ıtre le type de la donn´ ee et l’application situ´ ee ` a l’autre bout doit donc savoir
quel type de donn´ ees elle r´ ecup` ere.
4.3 ASN.1
La norme ASN.1 est apparue en 1984 sous forme d’une norme CCITT (norme
X.409) avant de devenir une norme ISO quelque temps plus tard. ASN.1 implante la
couche 6 du mod` ele OSI mais le langage de description de donn´ ees serait plutˆ ot de la
couche 7.
ASN.1 est plus “lourd” mais aussi plus g´ en´ eral que XDR, mˆ eme si le principe de
base est le mˆ eme : il s’agit la aussi d’un langage de description de donn´ ees qui permet
de repr´ esenter les structures de donn´ ees des langages de programmation. L’utilisateur
d´ ecrit en ASN.1 ses structures de donn´ ees. Son fichier de description est ensuite com-
pil´ e par un compilateur ASN.1 qui g´ en` ere les structures de donn´ ees adapt´ ees pour le
langage de programmation de notre utilisateur, et permet la liaison du programme avec
la librairie d’encodage ASN.1. Contrairement ` a XDR, le typage ASN.1 est explicite :
les donn´ ees sont encod´ ees avec leurs types respectifs : en codage BER par exemple (il
y a plusieurs types d’encodages de donn´ ees en ASN.1), chaque donn´ ee est repr´ esent´ ee
par un triplet (Tag,Longueur,Valeur), o` u le Tag identifie le type de donn´ ees.
ASN.1 est tr` es largement utilis´ e, depuis les transferts de mail (norme X.400), les
stockages d’information (protocole DAP, X.500), le multim´ edia, la cryptographie, l’´ echange
de donn´ ees, ou mˆ eme le futur Aeronautical Telecommunication Network (ATN).
ASN.1 reste lourd ` a mettre en oeuvre.
5 Proc´ edures etapplicationsdistribu´ ees(couche 5 OSI?)
Nous ne nous sommes int´ eress´ es jusqu’ici qu’au simple encodage et transport des
donn´ ees. Ce mod` ele simple suppose que la machine qui va r´ ecup´ erer les donn´ ees
sait exactement ce qu’elle va devoir en faire. Il est impossible de sp´ ecifier ` a distance
l’ex´ ecution d’une proc´ edure particuli` ere, ` a moins que l’on ne d´ ecide d’encoder dans le
protocole de donn´ ees des informations sur les op´ erations ` a effectuer4.
Les d´ eveloppeurs ont tr` es tˆ ot souhait´ es r´ ealiser une distribution du calcul et des
proc´ edures de fac¸on plus transparente, ainsi qu’une synchronisation des processus. L` a
encore, il existe plusieurs mod` eles allant du plus simple au plus compliqu´ e.
5.1 “Sun” RPC
Sun RPC (Sun Remote Procedure Calls) est un protocole d’abord d´ evelopp´ e par
Xerox, puis employ´ e par Sun, qui s’est aujourd’hui g´ en´ eralis´ e dans le monde UNIX. Il
est d´ efini par la RFC 1831.
4La premi`
ere donn´ ee envoy´ ee peut par exemple indiquer un num´ ero de proc´ edure ` a ex´ ecuter, etc. Cet
exemple est l` a pour bien montrer une fois de plus qu’il est possible de faire ` a peu pr` es tout ce que l’on
souhaite avec des m´ ethodes simples, mais au prix d’une complexit´ e accrue au niveau des protocoles.
5