Chapitre 1 : Middleware

3

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.

Fig 1.1. Système spaghetti

1.2. Les offres du Middleware: Le bus de communication middleware offres les services suivants :

Machine 3

Machine 2

Machine 1

Application 1

Application 2

Application 3

Application N

Application 1

Application 2

Application 3

Application N

Application 1

Application 2

Application 3

Application N

Chapitre 1 : Middleware

4

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.

Chapitre 1 : Middleware

5

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)

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

Fig 1.2.Architecture Client /Serveur à trois étages

Chapitre 1 : Middleware

6

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.

Chapitre 1 : Middleware

7

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).

Fig 1.3.Le middleware RPC

Chapitre 1 : Middleware

8

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].

Chapitre 1 : Middleware

9

Requête

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.

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.

Message

Client

Serveur Opération

Objet

Interface Employe

{

Void promouvoir (in char nouvelle_position)

Void renvoyer (in CodeRenvoi raison, in String description) ;

}

Client //opération

Pierre.promouvoir

Serveur //méthode

Promouvoir Employé ;

Renvoyer Employé ;

Agent (ORB)

Chapitre 1 : Middleware

10

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].

Chapitre 1 : Middleware

11

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)

Chapitre 1 : Middleware

12

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.

Chapitre 1 : Middleware

13

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

Chapitre 1 : Middleware

14

middleware caractérise l’une d’elles.