CAT 2000 LES MIDDLEWARES Présenté par : Tagmouti Siham Smires Ali Présentation des middlewares le 04-12-2000

PLAN Les problèmes à résoudre. Le middleware. Le model client serveur. Les technologies des middlewares. Le middleware par file d’attente. Le middleware par appel de procédure éloignée Le middleware orienté objet.

Les problèmes à résoudre L’intégration de logiciels d’origines divers. L’accès aux logiciels de l’intérieur ou de l’extérieur de l’entreprise. *Le développement rapide des applications.

Le middleware (1) Le middleware est un bus de communication auquel les applications se connectes par l’intermédiaire d’une interface clairement définie. Le but principal des middleware est de résoudre le problème d’intégration des logiciels.

Le middleware (2) Middleware Application1 Application2 Application3 Middleware ou bus de communication pour les applications distribués

Positionnement du middleware dans Le modèle OSI Application Application 1 Application 2 Application Application Middleware Présentation Présentation Session Session Transport Transport Services de transport des données Réseau Réseau Données Données Physique Physique Transfert des données

Le modèle client serveur Les caractéristiques La communication implique deux entités seulement. Une entité à l’initiative de dialoguer ( client/interviewer) et l’autre et en attente d’une requête (serveur/ interviewé). L’entité serveur est programmé pour répondre à un ensemble très précis de requêtes qui est définit dans son interface.

Le modèle client serveur Fonctionnement Émettre une requête Client Serveur Interface Exécute le service associé à cette requête. Retourne le résultat

Les technologies des middlewares On peut distinguer trois types de technologies différentes pour les middlewares : Le middleware par file d’attente. Le middleware par appel de procédure éloignée Le middleware orienté objet.

Le middleware par échange de messages Application A (émettrice) Application B (réceptrice) Le middleware récupère le message de A et le transmet à B. Début A s’attache aux deux files d’attente qui représentent l’accès au bus de communication. Début programme Début programme File de sortie File d’entrée File d’entrée File de sortie Middleware par file d’attente B s ’attaches aux files d ’attente Attacher_Files Attacher_Files B lit le message A dépose le message dans sa file de sortie. Déposer_message Lire_message B retourne une réponse vers A, en le déposant sur sa file de sortie. A partir de cet instant le message appartient au middleware et l ’application peut soit continuer un traitement interne soit se mettre en attente du message réponse Lire_message Déposer_message B émettrice Le middleware récupère le message de B et le transmet à A. A lit le message de B

Les produits disponibles Les chaînes d’assemblages de BMW utilisent le produit DECmessageQ de la société Digital Equipement. IBM propose le MQseries qui est un middleware par file d ’attente.

Le middleware par appel de procédure éloignée Interface Écrite en IDL Client Serveur Programme principal début Procédure A Fin ------------------------------------------------ Stub client Stub serv Middleware RPC Procédure B Fin Stub client La portion de code associée au client La portion de code associée au serveur Fin La préparation de la requête est extérieur au client, elle est générée à partir du langage IDL qui décrit l’interface du serveur utilisé par le client. Le client appel les procédures qui composent le serveur comme si elles étaient locales au client. , le code Le code de la communication est généré automatiquement à partir de l’interface décrite en langage IDL. Le middleware qui permet cette communication entre client et serveur est appelé middleware d’appel de procédure éloignée ( RPC : Remote Procedure Call ).

Le middleware par appel de procédure éloignée Caractéristiques (1) Le code du client et du serveur est indépendant du système de communication. Le client ne sait pas si la procédure est locale ou éloignée. Le code du client n’a pas à préparer le message, ni à localiser le serveur. Ce travail est à la charge du middleware RPC.

Le middleware par appel de procédure éloignée Caractéristiques (2) Le système de dialogue est totalement externe au client et au serveur. Il est décrit dans un langage spécifique appelé IDL à partir duquel est généré automatiquement le code nécessaire à la communication. La structure de communication est construite au moment de la phase de compilation. Elle est donc parfaitement définie avant la phase d’exécution.

Le middleware par appel de procédure éloignée Caractéristiques (3) La communication est synchrone. Après avoir fait son appel de procédure le programme client est en attente du résultat. Ce n’est que lorsque le résultat lui parvient qu ‘il reprend son traitement. La technologie RPC est entièrement standardisée. La standardisation inclut le langage IDL ainsi que tous les services nécessaires à la communication.

Le middleware par appel de procédure éloignée Problèmes La fiabilité du transfert. Si pour une raison quelconque le serveur ou le réseau ne fonctionne pas, le message ne sera pas livré et sera perdu. La gestion des erreurs ou des pannes est entièrement laissée à la charge du code client. La diffusion de messages. La structure de communication dans RPC est de un à un et non pas de un à plusieurs. Cela signifie qu’un client ne peut parler qu’à un seul serveur à la fois lors d’une requête.

Le standard DCE La couche DCE permet à une application distribuée de fonctionner comme si elle se trouvait sur une seule et même machine, alors que ses composants peuvent s’exécuter sur des machines différentes, avec des systèmes d’exploitation différents reliés par des réseaux distincts.

Le standard DCE Architecture Applications distribuées RPC Service pour Machine sans disque Services futurs Service de sécurité Service pour système de fichiers distribués(DCE DFS ) Service de gestion Service pour le temps distribué Service des nom Services futurs de base Appel de procédure éloignée ( DCE RPC ) DCE Threads Système d’exploitation et réseau Le but de ce service est d’offrir aux utilisateurs l’accès, partagé ou non, à des fichiers stockés dans un serveur de fichiers, localisé quelque part sur le réseau. Ce service permet à une telle machine de fonctionner en utilisant les disques d’une autre machine. On peut distinguer trois catégories de sécurité : l’authentification, l’autorisation et la sûreté de communication. Base de données centrale contenant toutes les ressources( machines, serveur… )disponible dans un système distribué. DCE Threads : ce service offre un mécanisme applicable au client comme au serveur et permettant une exécution parallèle de certaines parties du programme. DCE RPC : OSF DCE RPC est composé de deux types de logiciels : les outils de développement et les logiciels de run-time. Permet aux machines appartenant à une même cellule d’avoir la même notion du temps.

Le middleware orienté objet Les concepts de base (1) Cette technique se base sur des objets qui sont distribués à travers le réseau, la communication inter objet correspond à la demande d’exécution d’une opération sur un objet (le serveur) par un autre objet (le client). l’objet client ne connaît pas la localisation de l’objet serveur, et il n’a pas à construire le message de requête. La communication entre ces deux peut être définie de façon statique ou dynamique.

Le middleware orienté objet Les concepts de base (2) L‘infrastructure d’un système informatique orienté objet est constitué par l’ensemble des interfaces connectées au bus de communication. Le middleware objet met en évidence le concept d’interface qui représente les services offerts par l’objet client et autorise la génération de nouvelles interfaces par le mécanisme de l’héritage.

Le middleware orienté objet Communication statique Objet client  Objet  serveur OMG IDL Middleware Objet Communication dynamique La communication dynamique est établie par le client au moment de l’exécution, celui-ci peut interroger le middleware objet afin de connaître les interfaces des objets disponibles sur le réseau. La communication statique est décrite dans un langage standardisé orienté objet, appelé OMG IDL (Object Management Group Interface Definition Language), à partir du quel sont générés les stubs client et serveur qui permettent de connecter respectivement l’objet client et l’objet serveur au middleware objet.

Le standard CORBA Application Cliente Référence  de l’objet Interface Application Serveur Code d’implantation Bus CORBA État de l’objet Objet CORBA Requête Activation C’est le processus d’association d’un objet d’implantation à un objet CORBA. C’est la structure d’accueil des objets d’implantation et des exécutions des opérations. C’est le composant logiciel cible, c’est une entité virtuelle gérée par le bus CORBA. Regroupe les traitements associés à l’implantation des opérations de l’objet CORBA. C’est le type abstrait de l’objet CORBA définissant ses opérations et attributs, celle-ci est définit par l’intermédiaire du langage OMG-IDL. C’est un programme qui invoque les méthodes des objets à travers le bus CORBA. C’est une structure désignant l’objet CORBA et contenant l’information nécessaire pour le localiser sur le bus. C’est le mécanisme d’invocation d’une opération ou d’accès à un attribut de l’objet. Achemine les requêtes de l’application cliente vers l’objet en masquant tous les problèmes d’hétérogénéité.

Ahh, j’ai compris, C’est qu’il a faim le pauvre … Mais qu’est ce qu’il a à pleurer comme ça ?…qu’est ce qu’il veut ….. Waa, Waa, Waa …. Le bébé pleure incessamment Middleware: Waa, Waa, Waa = j’ai faim, j’ai faim …