Utilisateur:EilcoInfoEB13/Brouillon
Un middleware[1] (intergiciel) est une couche logicielle qui s'appuie sur les systèmes d'exploitation et qui fournit des abstractions pour simplifier le développement d'applications réparties sur des réseaux d'ordinateurs. De nombreux intergiciels existent aujourd'hui. Parmi les plus présents aujourd'hui, il y a la norme CORBA, Java RMI et les plates-formes agents DCOM.
Historique[modifier | modifier le code]
L’idée d’interagir avec un ordinateur distant remonte à l’année 1976 avec l’un des premiers mécanismes des systèmes distribués, le protocole RPC [2](Remote Procedure Call). Un protocole réseau permettant d’interagir avec une machine distante basé sur les protocoles TCP/IP[3] ou UDP/IP[4].
Les intergiciels orientés message (MOM[5]) est un autre type de technologie middleware utilisé pour les systèmes distribués. Apparu dans le marché informatique après les RPC, les middlewares orienté message ont l’avantage d’une meilleure gestion des files d’attente des messages (Message queue).
Avec les différentes acquisitions, fusions ou absorptions, la communication entre les différentes technologies devient un réel besoin. Le marché des technologies middleware grandi et avec lui les middlewares des objets distribués. Ces middlewares aussi appelés middlewares orientés objets sont représentés essentiellement par trois technologies : CORBA, Java RMI et Microsoft COM/DCOM.
Caractéristiques[modifier | modifier le code]
Un intergiciel fonctionne suivant 3 caractéristiques principales :
- L'échange de messages : C'est ce qui permet la communication entre différents logiciels. Une application envoie un message à une autre application via le middleware choisi. Le plus souvant, le langage XML est utilisés pour les messages.
- L'appel de procédures : Lorsqu'un middleware fait des appels de procédure à distance, il crée sur l'application appelante un composant logiciel souche qui aura les même caractéristiques techniques que l'application informatique appelée. Le middleware permet donc l'appel à distance de procédures en "recréant" sur l'application appelante la procédure voulue. Exemple : SOAP[6], RMI[7]
- La manipulation d'objets : Le middleware peut aussi manipuler les objets, c'est-à-dire que le middleware permet à une application d'effectuer des modifications ou des opérations de traitement sur un objet particulier. Pour permettre cela, la plupart des langages de programmations orientés objet permettent ces manipulations. Exemples : DCOM[8](basé sur le protocole RPC[9]), DCE[10](basé sur CORBA[11])
Interopérabilité entre les intergiciels majeurs : CORBA, RMI, DCOM[modifier | modifier le code]
L'interopérabilité entre logiciels est un concept informatique qui décrit la communication entre plusieurs applications indépendantes éditées sur des plateformes différentes et utilisées sur des ordinateurs différents. En effet, passer de la production de logiciels vers le milieu industriel (via les composants réutilisables) a été l'objectif premier du génie logiciel.
Cette interopérabilité se fait à travers des intergiciels (ou middlewares) qui permettent l'échange d'informations entre ces applications.
Il y a de plus en plus de systèmes qui utilisent leur propre langage et qui sont différents sur de nombreux aspects. Par conséquent les intergiciels interviennent pour résoudre ce problème. CORBA[12], suns Java RMI[13] et Microsoft COM/DCOM[14] sont les applications les plus utilisées.
CORBA[modifier | modifier le code]
L'OMG[15] (Object Management Group) est un regroupement de spécialiste informatique depuis 1989. Environ 850 acteurs composent ce groupe à l'heure actuelle (IBM, NASA, LIFL, Alcatel, ect.). À travers ce regroupement, il y a un object : faire émerger les standards pour l'intégration d'applications distribuées hétérogènes. L'élément clé de la vision de l'OMG est CORBA[16] : un middleware[17] orienté objet. CORBA (Common Object Request Brocker Architecture) est basé sur une architecture d'appel-réponse. Ce bus d'objets répartis offre un support d’exécution masquant les couches techniques d'un système réparti. De plus il prend en charge les communications entre les composants logiciels formant les applications réparties hétérogènes.
CORBA permet une interopérabilité riche et stable. a force repose notamment sur sa distribution, le nombre de langages supportés et son orientation objet.
Modèle objet Client/Serveur[modifier | modifier le code]
Le bus CORBA[18] propose un modèle orienté objet client/serveur d'abstraction et de de-coopération entre les applications réparties :
- La composante d’abstraction : chaque application peut exporter certains de ses services sous la forme d’objets CORBA[19].
- La composante de coopération : les interactions entre les applications sont alors matérialisées par des invocations à distance des méthodes des objets.
Ce modèle d'objet intervient uniquement lors de l'utilisation d'un des objets. On caractérise alors l'application implantant l'objet comme le serveur et l'application utilisant l'objet comme le client. Cependant il faut noter qu'une application peut être a la fois cliente et serveur.
Sur le schéma ci-contre illustre différentes notions :
- L'application cliente : programme qui utilise les méthodes objets via le bus CORBA.
- La référence de l'objet : structure qui désigne l'objet CORBA et permet de le localiser sur le bus.
- L'interface de l'objet : ce qui définit les opérations et attributs de l'objet CORBA (utilisation du langage OMG-IDL).
- Le bus CORBA : transfert les requêtes de l'application cliente vers l'objet.
- L'objet CORBA : entité virtuelle gérée par le bus CORBA.
- L'activation : technique d'association d'un objet d'implantation à un objet CORBA.
- Le code d'implantation : regroupement des traitements liés à l'implantation de l'objet CORBA.
- L'application serveur : structure d'accueil des objets d'implantation et des exécutions des opérations.
Utilisation[modifier | modifier le code]
CORBA est de plus en plus utilisé dans les implémentations commerciales. Il existe quelques exemple de son implémentation avec MICO (gratuit avec utilisation de CORBA2), VisiBroker4 (commercial avec CORBA2.3), Robine (gratuit avec CORBA2), CORBAScript (gratuit).
CORBA peut supporter de nombreux langages et permet même de supporter un mélange de plusieurs langages au sein d'une même application.
Java RMI[modifier | modifier le code]
Java RMI[20] est une API Java qui permet de faire appel et d’utiliser les résultats d’une méthode exécutée dans une machine virtuelle différente de la machine virtuelle de l’objet l’appelant. La machine distante est nommée Java RMI[21] server.
En concurrence avec CORBA et contrairement à ce dernier, Java RMI n’interagit pas avec plusieurs langages. L’API Java RMI est aussi bien plus simple à mettre en œuvre. C’est la raison pour laquelle de nombreux utilisateurs s'orientent vers cette technologie.
Java RMI se base essentiellement sur la sérialisation des objets ce qui permet à ces derniers d’être persistants. Puisque cette sérialisation est spécifique au langage Java, les objets serveur et client de Java/RMI doivent être écrits en Java.
Architecture[modifier | modifier le code]
Une application basée dur RMI met en œuvre trois éléments :
- Une application cliente implémentant la souche.
- Une application cliente implémentant le squelette.
- Une application médiatrice.
L’application médiatrice (Registre RMI) permet d’écouter les appels entrants ainsi que d’établir une connexion avec les différents protocoles.
L’interopérabilité utilisant cette API fonctionne grâce à l’architecture présentée par le schéma ci-contre.
Lorsqu’un objet instancié dans une machine virtuelle cliente souhaite accéder aux différents éléments d’un autre objet présent sur une machine virtuelle distante, il localise dans un premier temps l’objet cible à travers le registre RMI qui est composé de l’ensemble des interactions, la partie souche et la partie squelette :
Le client obtient dynamiquement l’image virtuelle de l’objet cible, cette image est nommée souche (stub en anglais). Suite à cette étape, le stub procède à la sérialisation de l’appel à l‘objet afin de le transformer en une suite d’octets.
Cette même suite d’octets va être transformée par le squelette instancié sur le serveur, pour récupérer les données concernant l’objet ou la méthode cible.
Le protocole propriétaire JRMP (Java Remote Method Protocol) est le protocole qui est chargé de lier le registre RMI au protocole TCP/IP sur le port 1099, il assure donc l’aspect remote de la connexion dans cette API.
Utilisation[modifier | modifier le code]
En programmation Java[22], un objet distant est une instance d’une classe qui implémente une interface distante. Cette interface content l’ensemble des méthodes qu’on souhaite utiliser d’une manière distante. Cette interface doit respecter quelques critères afin d’éviter des erreurs lors du chargement de l’objet distant (déclaration d’interface avec une portée publique, l’interface doit hériter de la classe java.rmi.remote, etc.).
La facilité d’utilisation de l’API Java RMI, la non nécessité de connaître un IDL spécifique ainsi que l’aspect WORA des applications Java sont des critères qui obligeaient les programmeurs à choisir entre RMI et COBRA pour les solutions de programmation distribués. Mais de nos jours, en respectant quelques restrictions, il est possible pour des objets RMI serveur de communiquer avec un objet CORBA client écrit dans n’importe quel langage, grâce à la solution RMI-IIOP. Une solution qui combine entre la facilité d’utilisation de RMI et l’aspect multi-langage de CORBA.
Microsoft COM/DCOM[modifier | modifier le code]
La technologie COM[23] a comme origine OLE[24] (Object Linking and Embedding), un protocole et un système d’objets distribués qui est apparu avec la version 3.1 de Windows. OLE présentait un mécanisme amélioré qui permettait la liaison entre différents documents (Word et Excel par exemple).
OLE a disparut progressivement pour laisser la place à COM (Component Object Model) qui est un composant de logiciel en forme binaire qui peut être imbriquée avec d’autres composants logiciels indépendants. Cette technologie qui a l’avantage de permettre en machine locale l’interaction entre les différentes adresses (machines virtuelles).
DCOM[25] est la version distribuée de COM qui offre les mêmes possibilités mais entre des machines sur un réseau LAN, WAN ou même internet.
Langages de développement[modifier | modifier le code]
Des langages comme C++ ou Smalltalk[26] présentent des mécanismes de programmation qui facilitent l’implémentation de COM car ce dernier nécessite essentiellement un langage utilisant la structure des pointeurs. Mais des langages comme C, Java et VB script peuvent être utilisés pour la création des objets utilisé par COM.
Architecture[modifier | modifier le code]
Le modèle client/serveur est valable aussi pour COM, à quelques nuances près : un serveur COM est d’abord tout objet présentant des services à des clients, ces services sont sous forme d’une implémentation d’une interface COM.
Il existe deux principaux types de serveur COM :
- Serveur in-process : implémenté dans un fichier DLL[27] (Dynamic Linked Library)
- Serveur out-process : implémenté dans un fichier exécutable[28] (de type .exe)
La différence entre les deux types de serveurs c’est que le in-process DLL est dynamiquement chargé dans l’application sans distinction entre le client et le serveur, c’est la solution classique d’implémentation. Au contraire, un serveur out-process externalise la gestion des appels au fichier .exe. Cette gestion est effectuée par Windows SCM (Smart Control Manager).
Dans COM, créer ce que l’on appelle DLL Surrogates, ou clone DLL, est courant et offre plusieurs avantages. Il devient possible de charger un serveur DLL dans un out-process, ce qui permet de profiter de la facilité d’implémentation des DLLs et rend ces derniers exécutables, ainsi que plusieurs autres avantages notamment en matière de protection des clients.
COM+[modifier | modifier le code]
Puisque Microsoft COM/DCOM utilise un large marché de composants, MTS[29] (Microsoft Transaction Server) est un composant qui a pour rôle la gestion des différentes transactions. COM+ qui est La combinaison de COM/DCOM et MTS prend en charge :
- La gestion des ressources
- La gestion de la création, suppression et exécution des objets.
- L’initiation automatique et le contrôle des transactions
- La gestion de la sécurité
- La mise en place d’outils permettant la configuration, la gestion et le déploiement
Comparaison entre intergiciels[modifier | modifier le code]
Nous pouvons comparer les solutions CORBA[30], Java RMI[31] et COM/DCOM grâce aux critères suivants :
| CORBA | Java RMI | COM | DCOM | |
|---|---|---|---|---|
| Plate-forme | Supérieure | Supportant JAVA | Limitée à Windows | Limitée |
| Langage | Supérieure | JAVA vers JAVA | Large | Large |
| Performance | Bonne | Supérieure | Bonne | Bonne |
| Développement | Difficile | Facile | Facile | Difficulté modérée |
| Sécurité | Bonne | Supérieure | Aucune | Intégrée à Win NT |
Le choix de la technologie est donc crucial et dépend du contexte de l'implémentation. Il faut donc se poser un certain nombre de questions avant de choisir :
- L'écriture des objets est-elle en Java ? Si la réponse est oui, le choix s'orientera plutôt vers CORBA et RMI.
- L'utilisation des objets dépend-elle d'une plate-forme Microsoft ? Si oui, le choix s'orientera alors vers RMI, COM/DCOM. Sinon on préférera utiliser CORBA.
- Les objets seront-ils stockés sur un même ordinateur ? Si oui, le choix s'orientera vers COM/DCOM et CORBA. Sinon ce sera DCOM et CORBA.
Parmi ces trois solutions, le choix de celle qui convient le plus à la problématique dépend de plusieurs critères :
- Le langage de programmation : les objets de COM/DCOM et CORBA peuvent être écrits par un large choix de langages, cela donne certes un grand choix en matière de programmation, or l’aspect uni-langage de Java RMI rend ce dernier plus simple à implémenter.
- Les objets : La communication entre les objets serveur et les objets clients diffère dans chaque solution. Pendant que Java RMI et Microsoft DCOM nécessite un protocole réseau afin de pouvoir lier la partie stub à la partie squelette, CORBA à l’avantage d’une communication objet direct entre les deux types d’objets et est donc qualifié d’une transparence au niveau des échanges réseau.
- Le coût : CORBA middleware créé par OMG et DCOM une solution de Microsoft sont toutes les deux propriétaires. En revanche Java RMI est une solution gratuite
Parmi les raisons pour lesquelles Microsoft COM/DCOM a une large base d’utilisateurs sont :
- Le marché de composants qui contient plusieurs solutions déjà présentes.
- Mise à jour logiciel en ligne sans recompilation ou redémarrage.
- La plupart des applications Windows sont des objets COM
La question de choix de middleware dépend de plusieurs paramètres internes ou externes à l’entité, mais l’utilisation de plusieurs intergiciels est une solution qui reste toujours envisageable et qui permet de bénéficier des avantages de chaque solution.
Voir aussi[modifier | modifier le code]
Autres solutions d'interopérabilité logicielle[modifier | modifier le code]
Bibliographie[modifier | modifier le code]
CORBA :
http://www.omg.org/gettingstarted/corbafaq.htm
Common Object Request Broker Architecture
RMI :
DCOM :
Livre :
Thèse de l'université de Montréal "Les intergiciels"
Comparison of Middleware Technologies - CORBA,RMI & COM/DCOM Abhishek Patil, Rajesh Korde, Kapil Sabharwal Michigan State University
- « Middleware », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Remote procedure call », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Suite des protocoles Internet », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « User Datagram Protocol », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Message-oriented middleware », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « SOAP », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Mauvais titre », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Distributed Component Object Model », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Remote procedure call », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Distributed Computing Environment », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Common Object Request Broker Architecture », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Common Object Request Broker Architecture », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « RMI », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Distributed Component Object Model », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Object Management Group », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Common Object Request Broker Architecture », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Middleware », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Common Object Request Broker Architecture », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Common Object Request Broker Architecture », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « RMI », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « RMI », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Java », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Component Object Model », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Object Linking and Embedding », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Distributed Component Object Model », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Smalltalk », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Dynamic Link Library », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Mauvais titre », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Microsoft Transaction Server », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « Common Object Request Broker Architecture », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le ) - « RMI », Wikipédia, {{Article}} : paramètre «
date» manquant (lire en ligne, consulté le )