Chapitre 1 : Middleware

Chapitre 1 : Middleware

1.1. Définition du Middleware

Le mot Middleware signifie la couche intermédiaire entre Software et System Software
(Système d’exploitation). C’est le bus logiciel de communication entre les différentes
applications s’exécutant sur différentes plateformes (machine physique + système
d’exploitation). Elle a pour vocation d’assurer l’interopérabilité entre les applications
provenant de différents vendeurs où chacun utilise sa propre technologie [SER1999]

Une solution banale est de construire à chaque fois un lien de communication entre
l’application existante et celle que l’on veut intégrer à notre système. Mais au fur et a mesure
que le nombre d’applications intégrées augmente, le système devient complexe « Système dit
spaghetti». La couche Middleware vient comme solution a ce type de problème.

Application 1 Application 1
Application 2 Application 2
Application 3 Application 3
Application N Application N

Machine 2 Application 1 Machine 1

Application 2
Application 3

Application N

Machine 3

Fig 1.1. Système spaghetti

1.2. Les offres du Middleware:

Le bus de communication middleware offres les services suivants :

3
 Chapitre 1 : Middleware

 L’indépendance entre les applications et le système : Chaque système d’exploitation

offre des interfaces de programmation spécifiques pour contrôler les couches de
communication réseau et les périphériques matériels. La plate-forme d’intégration
fournie aux applications des interfaces standardisées masquant les spécificités de
chaque système.

 La portabilité des applications : Ces interfaces standardisées permettent de concevoir

des applications portables et indépendantes des environnements d’exécution. Les
sources des applications peuvent alors être recompilées sur différents environnements
sans nécessité de modifier celles-ci.
 Des services partagés distribués : Les applications distribuées ont besoin de
fonctionnalités système tels que la communication, la sécurité, les transactions, la
localisation, la désignation, l’administration, etc. Les plates-formes fournissent ces
fonctionnalités sous la forme de services partagés et distribués sur l’ensemble des sites
des applications.
 Disponibilité de middleware sur différentes machines : c’est la possibilité d’échange
entre les applications fonctionnant sur des machines différentes
 Fiabilité de transport : c’est-à-dire que l’émetteur doit s'assurer que l'information est
reçue une et une seule fois, même en cas de panne du réseau.
 Diversité de structure de communication : c’est le middleware qui se charge de la
nature de communication (un à un, ou diffusion)
 Utilisation de nom : elle est utilisée au niveau d’application, après c’est au middleware
de trouver l’adresse physique correspondante (ce qui donne une transparence et une
indépendance d’emplacement)
 Concept de transaction (tout ou rien) : par exemple pour qu’une agence organise un
voyage, elle utilise deux applications ; réserver un vol, et réserver un hôtel. On suppose
que si l’on ne peut réserver un vol pour une destination donnée, il est inutile de réserver
un hôtel.

1.3. Positionnement du Middleware:

Middleware est une structure de communication indépendante du système d’exploitation, et
de la machine. Elle est située dans les couches hautes (couches application, présentation,
session du modèle OSI) en définissant le protocole de communication entre applications.

1.4. Modèle Client / Serveur :

 CLIENT : entité communicante émettrice des requêtes (demande de service), elle prend
toujours l'initiative de la communication.

 SERVEUR: entité communicante réceptrice des requêtes elle est en mode attente des
requêtes, caractérisé par l'interface qui constitue l'ensemble des services qu'elle offre.

4
 Chapitre 1 : Middleware

1.5. Modèle Client/ Serveur à 3 étages :

Les trois constituants de ce modèle sont :
A. Interface utilisateur: elle est souvent graphique et peut fonctionner sur différentes machines.
B. Partie traitement (Logique de l'application ou Serveur d'Application ou service business)
C. Partie accès aux données (Serveur de donnée)

Fig 1.2.Architecture Client /Serveur à trois étages

Avantages :
 Chaque partie est physiquement indépendante des autres, ainsi les trois étages peuvent
fonctionner sur trois machines différentes, la communication entre étages se faisant
grâce au middleware.
 La programmation et la maintenance de chacun des étages peuvent être faites
indépendamment des autres étages aussi longtemps que l'interface n'est pas changée.
 La séparation fonctionnelle conduit à rendre le code central de l'application (le serveur
de traitement) indépendant de la structure de la localisation des données. Il est aussi
indépendant de la façon dont les données sont fournies pour l'utilisateur.

1.6. Les différentes sortes de middleware

Le premier but des technologies du middleware est de résoudre le problème d’intégration des
logiciels. Sachons que l’ajout d‘une application à un environnement informatique comportant n
applications, conduit à construire n liens de communication et 2n interfaces. [SER1999]

Une façon de résoudre ce problème est d’introduire le concept de bus unique de

communication ou middleware auquel les unités de traitement se connectent par l’intermédiaire
d’une interface clairement définie. Ces unités distribuées de traitement sont celles qui font
l’objet de la classification des middlewares
A/ Middleware par file d'attente ou échange de messages
5
 Chapitre 1 : Middleware

B/ Middleware par appel de procédures éloignées

C/ Middleware orienté objet, comme : CORBA et COM

1.6.1. Middleware par file d'attente ou échange de messages

L’unité de distribution ici est l’application
L’intérêt de ce bus de communication et de simplifier la programmation en évitant de
programmer au niveau des protocoles réseaux ou des appels systèmes. Les technologies de ce
concept sont très fiables et matures. [SER1999]

Exemple d'utilisation
- La chaîne d'assemblage de BMW utilise BEAMessageQ de la société BEA [SER1999].
- MQSeries d'IBM. [SER1999].
Caractéristiques
- Transmission synchrone ou asynchrone de message.
- Garantie de livraison des messages par la sauvegarde sur le disque.
- Disponibilité sur Beaucoup de Plateformes (machine + son système) par exemple le produit
BEAMessageQ est disponible sur Windows-NT, UNIX (HP-UX, …), OVMS, IBM MVS, etc.
Avantages :
- Fiabilité
- Cette technologie utilise une programmation traditionnelle (elle ne fait pas appel aux
dernières technologies de programmation orientée objet) alors l’intervention du programmeur
au niveau du code pour les fonctions de communication (structure du message, méthode de
transmission, etc.) est facile.

Inconvénients :
- L’application émettrice, ainsi que l’application réceptrice doivent prendre en charge la
construction du message.
- Pas de standard, cela signifie qu’un utilisateur ne peut pas combiner 2 produits middleware en
provenance de 2 vendeurs différents.

1.6.2. Middleware par appel de procédures éloignées :

L’unité de distribution ici est la procédure
Le modèle Client/Serveur se projette comme suit : Client=programme principale, Serveur =
ensemble de procédures, qui peuvent être n'importe où dans le réseau, et le middleware qui
permet la communication entre Client/Serveur s'appel Middleware d'Appel de Procédures
Eloignées (RPC). [SER1999]
Caractéristiques:
- Le code du client et du serveur est indépendant du système de communication qui est décrit
dans un langage bien défini appelé langage de description d’interface (IDL).
- Transparence d'emplacement et de traitement.
- Communication synchrone et un à un.
- Elle est standardisée y compris IDL (OSF/DCE).
- N'offre pas la fiabilité de transport et le concept de transaction.

6
 Chapitre 1 : Middleware

Fig 1.3.Le middleware RPC

1.6.3. Middleware Orienté Objet (Objets Distribués) : CORBA et COM

L’unité de distribution ici est l’objet

Caractéristiques
Mêmes avantages de l'approche O.O (séparation Interface/Implémentation, héritage qui a pour
but la réutilisation et la communication entre un objet demandant l'exécution d'une opération
sur un autre objet (serveur) est réalisée à travers un bus de communication spécifique appelé
Middleware Objet).
Cette communication peut être statique ou dynamique :
1. Communication Statique : comme RPC (décrite avec IDL objet standardisé)
L’explication détaillée est retardée à la partie de CORBA
2. Communication Dynamique : le client au moment de l'exécution interroge le
Middleware objet afin de connaître les interfaces disponibles sur le réseau, L’explication
détaillée est retardée à la partie de CORBA.
- L'infrastructure d'un système informatique O.O est constitué par l'ensemble des interfaces
connectées au Middleware O.O est alors leur mise à jour est facilitée par le mécanisme
d'héritage qui permet d'en introduire de nouvelles toute en grandissant les anciennes.
- La description de l'interface permet de convertir une application pour jouer le rôle d’un
serveur, il suffit pour cela de la connecter à une interface objet.
Les standards :
Il y a trois modèles :
- CORBA (1990) par l'OMG sur toutes les plates-formes.
- DCOM (1996) par Microsoft sur Windows et UNIX, domine le monde PC Windows.
- Java RMI par Sun Microsystems ; une abstraction pour toute sorte de protocole basé objets
distribués.
La norme CORBA 2.0 : elle résous le problème d’interopérabilité entre les agents CORBA
par le protocole de communication IIOP (Internet Inter-Orb Protocol).
7
 Chapitre 1 : Middleware

La norme CORBA 3.0 : insiste sur l'aspect composant logiciel mis en évidence dans java par
le concept de JavaBean.
Les nouvelles fonctions requises :
Ces Middlewares orientés objets sont caractérisés par la non prise en charge de la persistance,
les transactions, la sécurité, …etc. donc c’est le programmeur qui doit les gérer explicitement.
Par exemple la gestion de transactions nécessite :
- Le protocole 2-Phase-Commit = Atomicité.
- Routage des requêtes en cas de pannes (réseau serveur).
- L’action est exécutée une et une seule fois.
- Mise en route ou arrêt des serveurs.
- Flots d'exécution de la transaction.

Avant, les systèmes transactionnels traditionnels sont des systèmes centralisés comportant
une grosse machine localisée dans un site central à laquelle sont connectés des terminaux situés
dans des agences.
L’acronyme ACID résume les propriétés que doit vérifier chaque transaction :
 Atomicité : une transaction doit effectuer toutes les mises à jour ou aucune.
 Cohérence : une transaction doit faire passer d’un état cohérent vers un autre état
cohérent.
 Isolation : les résultats de la transaction ne doivent être visibles aux autres transactions
qu’une fois la transaction validée.
 Durabilité : une fois la transaction validée, le système garantit que les modifications
sont durables, y compris en cas de panne du système.

1.7 CORBA :
CORBA décrit une architecture à objets distribués sur le réseau. Elle met en œuvre le modèle
client/serveur en introduisant une entité intermédiaire appelée « agent Broker», la requête
émise par le client est reçue par l’agent qui la transmet au serveur. La présence de cet agent
permet d’isoler les clients des serveurs. Ainsi toute application cliente peut s’intégrer avec une
autre application serveur sans avoir à connaître ni son adresse ni la façon dont cette dernière
accomplira sa tâche [GEI1997]

1.7.1 Le modèle conceptuel de CORBA

La séparation entre le client et le serveur est assurée par le fait que ces deux entités
communiquent sous forme de requêtes. Une requête est un message émis par le client à
destination du serveur. Ce message contient le nom d’une opération et le nom de l’objet sur
lequel doit s’appliquer l’opération ; Ainsi dans CORBA toute interaction est basée sur l’envoi
de requêtes [GEI1997].

8
 Chapitre 1 : Middleware

Requête
Message
Opération
Client Serveur
Objet

Fig 1.4.Communication entre client et serveur.

Notion d’interface : Une interface représente un contrat existant entre un client et un serveur.
Il définit l’ensemble des opérations que l’objet client peut demander de l’objet serveur. Cette
interface est écrite dans un langage particulier appelé Interface Definition Language (IDL.).

Le but d’interface est de définir des actions possibles sur un objet, à chaque attribut sont
automatiquement associées deux opérations d’accès : une opération de lecture et une opération
d’écriture de sa valeur. La figure suivante fournit un exemple d’interface rédigé en langage
IDL. Cette interface définit deux opérations associées à l’objet Employe à savoir promouvoir et
renvoyer.

Interface Employe
{
Void promouvoir (in char nouvelle_position)
Void renvoyer (in CodeRenvoi raison, in String description) ;
}

Client Serveur
//opération //méthode
Promouvoir Employé ;
Pierre.promouvoir Agent (ORB) Renvoyer Employé ;

Fig 1.5. Exemple d’une requête émise par le client et transmise au serveur par l’agent.

1.7.2. Mécanisme d’invocation :

Le client ayant connaissance de l’interface « Employer » sait qu’il peut émettre une requête
sur une instance (ex. Pierre) dont il possède la référence, demandant l’exécution d’une
opération (ex. promouvoir). Cette requête peut être générée de deux façons : statique et
dynamique.

 Invocation statique :
Permet une communication synchrone et elle suppose l’existence de stub au niveau de client et
du serveur. Le stub client fait la liaison entre le client et l’agent, le stub serveur (appeler
Skelton) fait la liaison entre l’agent et le serveur. Ainsi la requête du client transite au serveur à
travers son Skelton.

9
 Chapitre 1 : Middleware

 Invocation dynamique :
Dans ce type d’invocation le client ne possède pas de stub le liant au serveur et doit construire
dynamiquement sa requête. Pour cela, le client utilise l’interface d’invocation dynamique liée à
l’agent. Cette interface donne accès à une base de données contenant la description des
interfaces de tous les serveurs disponibles et la description des opérations possibles sur les
objets.

1.8. Java RMI:

Aujourd’hui, les trois principaux services d’objets distribués sont CORBA, Java RMI et
DCOM. Chacun de ces services utilise un protocole réseau différent, mais ils accomplissent
tous la même chose : la transparence de la localisation. DCOM est principalement utilisé dans
l’environnement Microsoft Windows et il n’est pas bien supporté par les autres systèmes
d’exploitation. Sa forte intégration aux produits Microsoft en fait un bon choix pour les
systèmes uniquement Microsoft [MON2000].
CORBA n’est spécifique ni à un système d’exploitation ni à un langage. C’est donc le service
d’objets distribués le plus ouvert des trois. C’est un choix idéal quant on intègre des systèmes
développés dans plusieurs langages de programmation. Java RMI est une abstraction du
langage Java ou un modèle de programmation pour toute sorte de protocole à objets distribués.
De la même façon que l’API JDBC peut être utilisée pour accéder à toute base de données
relationnelle SQL, Java RMI est destiné à être utilisé avec presque tout protocole d’objets
distribués.
 En pratique, Java RMI se limite à Java Remote Method Protocol (JRMP) –connu sous
le terme Java RMI au-dessus de JRMP- qui ne peut être utilisé qu’entre des applications
Java.
 Récemment, une implémentation de Java RMI au-dessus de IIOP (Java RMI-IIOP),
c’est une version compatible CORBA de Java RMI, qui permet aux développeurs
d’exploiter la simplicité du modèle de programmation de Java RMI tout en tirant parti
du protocole IIOP de CORBA indépendant de la plate-forme et du langage.
Utiliser Java RMI au-dessus de DCOM semble un peu tiré par les cheveux, mais c’est
possible. La figure suivante illustre l’API EJB du langage Java supportée par différents
protocoles d’objets distribués [MON2000].

10
 Chapitre 1 : Middleware

Fig 1.6. Vue du client Java supportée par les différents Middleware.

1.9. Les types du middleware à objets distribués

Lorsqu’une application à base d'objets distribués devient plus grande, vous aurez besoin de
l'aide via les services middleware, tel que les transactions et la sécurité. Il y a deux façons
d’obtenir ces services : explicitement et implicitement.

1.9.1. Middleware explicite

Dans la programmation à base d’objets distribués traditionnelle (tel que CORBA traditionnel),
vous pouvez obtenir le middleware en achetant ce middleware fermé puis en écrivant le code
qui appels l'API de middleware [ROM2005].
Par exemple, vous pourriez faire une transaction en écrivant l’API de la transaction. Nous
appelons ce middleware explicite parce que vous avez besoin d'écrire l’API pour utiliser ce
middleware (voyez le Figure 8). L'exemple suivant montre que le transfert des fonds d’un
compte à un autre doit être transactionnel en appelant nous même les API du middleware.
transfer(Account account1, Account account2, long amount) {
// 1: Call middleware API to perform a security check
// 2: Call middleware API to start a transaction
// 3: Call middleware API to load rows from the database
// 4: Subtract the balance from one account, add to the other
// 5: Call middleware API to store rows in the database
// 6: Call middleware API to end the transaction
}
Cette approche est caractérisée par : une - Ecriture difficile, et une - Maintenance difficile.
(Elle nécessite la récriture du code)

11
 Chapitre 1 : Middleware

Fig 1.7. Middleware Explicite.

1.9.2. Middleware implicite

La différence cruciale entre les systèmes du passé (Moniteurs transactionnels tels que
TUXEDO ou CICS, ou technologies objets distribués traditionnelles telles que CORBA,
DCOM, ou RMI) et les plus nouveaux ; les technologies basée composant (EJB, CORBA
Component Model, et Microsoft .NET) est que vous pouvez utiliser le middleware dans vos
applications d’entreprise sans écrire de code appelant les APIs du middleware. [ROM2005]
Dans ce cas le programmeur doit seulement :
1. écrire votre objet distribué pour contenir seulement la logique métier.

transfer(Account, account2 du Compte, long montant) {

/ / 1: Soustrayez la balance d'un compte, ajoutez à l'autre
}
2. déclarer les services du middleware dans votre objet distribué a besoin un descripteur
séparé. Par exemple, vous pouvez déclarez que vous avez besoin de transaction.
3. Utiliser un outil fourni par le vendeur du middleware qui prend votre descripteur comme
entrée et produit un objet qui est appelé l’intercepteur de demandes. Ce dernier intercepte des
demandes du client, exécute le service du middleware que votre objet distribué a besoin (tel
que transactions, la sécurité, et persistance), et cela en déléguant l'appel aux objets distribués.
Les valeurs du middleware implicite (aussi appelé le middleware explicatif) sont :
 Ecriture facile. Vous n’avez pas à écrire réellement les APIs du middleware; plutôt,
vous déclarez cela dans un fichier de texte simple. L’intercepteur de demande fournit la
logique du middleware pour vous d’une façon transparente. Vous ne concentrez pas au
middleware plutôt sur la logique métier de votre application
 Maintenance facile. La séparation de la logique métier et celle du middleware est propre
et maintenable. C'est moins de code qui rend des choses plus simples. En outre,
changer le middleware n'exige pas changer le code de l’application.
12
 Chapitre 1 : Middleware

 Facile à supporter. Les clients peuvent changer la politique de sécurité, par exemple, en
modifiant seulement le fichier descripteur sans que le code ne soit modifié.

Fig 1.8. Middleware Implicite.

1.10 Conclusion:

Avant de conclure ce chapitre on peut, tout d’abord, évoquer les problèmes que l’entreprise
rencontre à chaque évolution du marché d’une part, et à cause de la répartition géographique de
cette dernière en un ensemble d’agences dont la synchronisation et la communication doivent
être assurés d’autre part. Cette distribution peut être vue à différents niveaux : au niveau de
l’application, de la procédure, ou de l’objet tout en factorisant les aspects de communication
en un seul niveau qui est le bus de communication logiciel ou Middleware, dont CORBA
devient le fameux standard middleware objet. L'étude du middleware serait bien incomplète si
elle n’était limitée qu’aux technologies elles-mêmes. Les technologies, dans ce cas, ne valent
que dans la mesure où elles peuvent être reliées aux problèmes qu'elles permettent de résoudre.

La liaison entre les besoins de l’entreprise et le middleware qui est tout à fait possible et
importante, ce qui décuple l'intérêt de cet ensemble de technologies. Ces possibilités
architecturales, directement assujetties aux besoins de l'entreprise, offrent la flexibilité
indispensable à l'évolution des besoins. Cette liaison est réalisable grâce aux deux éléments
suivants :
1. Le concept d'interface qui caractérise chaque composant connecté au bus middleware. Ce
concept permet de décrire l'ensemble des services offerts par l'infrastructure.
2. La méthodologie orientée objet qui permet de construire un modèle d'interfaces répondant
aux besoins des utilisateurs. Ce faisant, cette méthodologie contribue à réduire le niveau de
complexité lié à la conception et à la gestion de systèmes distribués.

Dans le prochain chapitre on introduit l’évolution des architectures logicielles où le

13
 Chapitre 1 : Middleware

middleware caractérise l’une d’elles.

14