Les files de messages, « producteur/consommateur » 

Télécharger le fichier pdf d’un mémoire de fin d’études

Description d’un intergiciel [de communication]

Un intergiciel se présente généralement sous la forme de deux composants principaux : un modèle de programmation (également appelé personnalité applicative, cf Préface) et un modèle de communication (ou personnalité protocolaire). Jusqu’à aujourd’hui, ces deux modèles sont fortement couplés, i.e. le type de communications utilisées par l’intergiciel est reflété par son modèle de programmation. Un intergiciel présente par le biais de son modèle de programmation un certain nombre de services, certains obligatoires, d’autres facultatifs.
Modèle de programmation
Le modèle de programmation d’un intergiciel définit comment le développeur peut utiliser l’intergiciel pour assurer les communications entre composants logiciels. Il peut offrir une API1 et/ou des mécanismes découplés de la programmation traditionnelle, e.g. une description externe d’interfaces comme IDL (Interface Definition Language), ou annotations comme SCA (Service Component Architecture, cf section I.5.3).
Ce modèle de programmation peut être profondément intégré dans le langage, permettant d’assurer implicitement des communications sans manipuler de concepts étrangers : un simple héritage de classe permet dans certains cas de rendre l’objet accessible aux autres. Le modèle peut également rester basique, permettant d’assurer les communications via des méthodes dédiées, mais nécessitant la gestion explicite de ces communications par les objets.
L’intérêt de chaque type de modèle est justifié : certains préfèreront s’abstraire complètement des mécanismes de communication, alors que d’autres préfèreront garder le contrôle sur ceux-ci.

Web Services

L’intergiciel de communication le plus « en vogue » de nos jours est sans nul doute leWeb-Service [CKM+03]. Il s’agit plus exactement d’une spécification, mais de nombreux intergiciels l’implémentent afin de permettre simplement et efficacement de fournir et d’utiliser un Web-Service. Parmi ceux-ci, JAXWS1, Weblogic, Websphere, ou bien encore le framework .Net (et donc tous les langages de programmation .Net comme C#, J#).
Le Web-Service est basé sur un modèle de programmation de type RPC (Remote Procedure Call, appel de procédure à distance). Dans un premier temps, le client cherche lesWeb-Services disponibles (grâce à des méthodes de découverte), puis il consulte la description du service voulu, et enfin il envoie une requête à ce service, qui lui envoie en retour la réponse à sa requête.
La particularité de ce modèle de programmation est que les Web-Services sont sans état (« stateless »), i.e. la requête est indépendante de toute session (tout du moins du point de vue du Web-Service), et le cycle de vie du service équivaut à la durée de la requête.
Le modèle de communication utilisé se base sur UDDI2 pour la découverte de services, le langage WSDL3 pour leur description, et un protocole de requête qui peut être SOAP ou XML-RPC4. Comme le Web-Service utilise SOAP (et XML-RPC, un « SOAP-like »), le modèle de communication sousjacent peut varier : (e.g. HTTP, JMS), mais il s’agit presque toujours du protocole HTTP.

RMI

De nombreux intergiciels proposent, comme CORBA, un modèle de programmation efficace pour gérer les communications dans une application répartie.
C’est le cas de RMI [Mic03] (pour Remote Method Invocation), un intergiciel de communication pour le langage Java. La marche à suivre pour développer des objets répartis est un peu différente de CORBA. Comme RMI n’est proposé que pour un seul langage, les descriptions d’interfaces sont directement codées dans celui-ci, ce qui évite de devoir manipuler un second langage de description en plus de la programmation. Pour qu’un objet puisse être accessible à distance, un simple héritage de classes RMI spécifiques suffit.
Le grand avantage de RMI est qu’il est inclus dans les bibliothèques standards Java, ce qui permet à toute application Java de pouvoir utiliser RMI sans aucun composant additionnel.
Jusqu’à la version 5.0 de Java, l’utilisation d’un outil nommé rmic1 était obligatoire afin de générer les souches et squelettes nécessaires à l’utilisation répartie de l’application. Depuis cette version, un mécanisme d’invocation dynamique permet de passer cette étape.
Le modèle de communication utilisé par RMI est le JRMP2, un protocole utilisé sur TCP/IP et présentant l’avantage d’être très léger. Cependant, pour rendre RMI compatible avec d’autres intergiciels (notamment CORBA), le développeur peut spécifier à RMI d’utiliser le protocole IIOP pour établir ses communications. Certaines implémentations de RMI utilisent même des protocoles propriétaires (e.g. le protocole ORMI pour Orion, T3 pour WebLogic).

Synthèse des intergiciels mono-modèles

Des intergiciels présentant un unique modèle de programmation et de communication existent en nombre important, et assurent des communications fiables et efficaces entre composants répartis dans leur contexte de prédilection.
Ils permettent d’utiliser des mécanismes synchrones et asynchrones pour donner la possibilité aux applications de communiquer entre elles, en abstrayant la couche réelle de communication du système.
Si leur utilisation est suffisante pour le développement et le déploiement de la plupart des applications réparties, leur aspect « figé » ne permet pas de modifier leur comportement pour s’adapter au contexte d’exécution.

Intergiciels réflexifs / multi-modèles

Depuis plusieurs années maintenant des équipes de recherche (ainsi quedes industriels) s’intéressent aux limitations des intergiciels conventionnels, et donc également à dépasser ces limites en explorant de nouveaux principes.
Parmi ces nouvelles idées, deux tendances se font sentir :
– Les intergiciels réflexifs, ou comment un intergiciel peut s’observer luimême pour modifier son comportement,
– Les intergiciels multi-modèles, ou comment tirer le meilleur parti des intergiciels existants en les combinant.
Dans ces deux cas, la raison des modifications (ou combinaisons) apportées est le changement de contexte. Avant de recenser ces principaux intergiciels « nouvelle génération », réflexifs et multi-modèles, nous allons citer les principales solutions existantes pour permettre à une application de s’adapter au contexte.

DynamicTAO

TAO1 est une implémentation d’une grande partie de la spécification CORBA, incluant Real-time CORBA, qui fournit une qualité de service efficace et prédictible, adaptée au déploiement sur des systèmes temps-réel. DynamicTAO [KRL+00] est une évolution de TAO permettant à l’ORB de se reconfigurer dynamiquement par un comportement réflexif. Si ses possibilités sont grandes, les fonctions essentiellement exploitées dans cet intergiciel sont celles d’inspection et de configuration à distance via l’interface ad hoc implémentant le protocole DCP2. Le type d’adaptation et de reconfiguration permises par DynamicTAO sont ainsi distantes et centralisées, permettant de superviser interactivement le déploiement. Mais les mécanismes autorisant une réelle adaptation autonome au contexte sont à l’heure actuelle non implémentés.
Le développement de DynamicTAO est arrêté depuis quelques années, une évolution du principe a pris sa suite sous la forme de LegORB, un ORB basé sur des bibliothèques dynamiques, offrant un intergiciel compatible avec le modèle de communication de CORBA (IIOP) dont les composants sont connectables et déconnectables à l’exécution pour assurer sa configuration dynamique (i.e. l’activation / désactivation de ses services).

Commutation synchrone/asynchrone

Victor Budau et Guy Bernard [BB02] exposent un modèle de communication hybride pour composants EJB1, basé d’une part sur le modèle synchrone JavaRMI, et d’autre part sur le modèle asynchrone JMS. Ce modèle hybride consiste en un commutateur Synchrone/Asynchrone, interceptant les émissions et réceptions d’invocations, et choisissant le modèle de communication le plus approprié pour transmettre ces invocations. Lorsque l’application veut transmettre une invocation, le commutateur tente l’utilisation du modèle synchrone, et si celui-ci ne réussit pas, le commutateur utilise donc le modèle asynchrone. Inversement, lorsqu’un message doit être transmis par le modèle asynchrone, le commutateur tente d’abord de l’envoyer via le modèle synchrone, pour éviter le surcoût du modèle asynchrone. Si le principe de commutateur est intéressant, les mécanismes encore basiques de commutation basés sur les exceptions méritent un approfondissement. Ce modèle hybride prometteur reste pertinent et justifie l’utilisation de plusieurs modèles de communication selon les circonstances.

Les événements

Les événements sont une évolution du système de files de messages. En fait, ils se basent sur le même principe de producteur et de consommateur.
La principale évolution entre les deux systèmes est que les événements s’intègrent à la programmation par implémentation d’une interface. Il est possible de produire et consommer les événements selon deux comportements distincts : le push et le pull. Dans le premier cas, le producteur déclenche ses événements directement sur le canal de communication (i.e. explicitement), et la méthode dédiée est appelée chez le consommateur pour lui soumettre l’événement. Dans le second cas, le fonctionnement est inverse : lorsque le consommateur veut obtenir un événement, il soumet la requête explicitement sur le canal de communication, et la méthode dédiée est appelée chez le producteur pour qu’il soumette un événement.

Web Services par les annotations Java

Java propose une interface de programmation d’application (API) dédiée auxWeb Services nommée JAX-WS [Mic06b] (pour Java API for XML based Web Services, anciennement JAX-RPC), et utilisant les annotations comme descripteur pour établir la distribution des applications. Les annotations utilisées par JAX-WS sont en fait issues de plusieurs spécifications distinctes (JSR 181 : Web Services Metadata ; JSR 224 : JAX-WS ; JSR 222 : JAXB; JSR 250 : Annotations communes).

Entreprise Java Beans (EJB) par les annotations

Les annotations sont liées depuis quelques années déjà à JEE (anciennement J2EE), notamment au travers du projet BeeHive d’Apache [SOS+06], visant à définir des annotations pour simplifier la programmation de Java Entreprise Edition.
Aujourd’hui une partie de JEE présente un modèle de programmation par annotations : les Entreprise Java Beans dans leur version 3 [Mic06a]. Les possibilités offertes par ces annotations sont assez nombreuses, elles peuvent spécifier les interfaces de description de service, les classes et objet offrant des services, ainsi que les connections (bindings) avec des services distants (grâce à l’annotation @Reference qui spécifie le nom du service).

SCA par annotations

L’architecture de composants de services [Cha07] propose un modèle de programmation à base d’annotations Java, utilisable seul ou en complément du modèle plus classique. Les annotations fournies présentent une utilisation similaire au modèle des EJB3.
Une application peut donc être entièrement distribuée grâce à ces annotations spécifiques. L’intérêt supplémentaire de ces annotations, et qu’elles sont vouées à être compatibles avec le modèle de programmation par annotations des EJB et des Web Services (certaines sont d’ailleurs identiques aux annotations définies par les EJB 3).

Synthèse

Plusieurs modèles de programmation d’intergiciels proposent l’utilisation d’annotations pour spécifier la répartition de l’application. Il apparait cependant que ces annotations ont, jusqu’à maintenant, toujours besoin d’un autre modèle de programmation complémentaire.

Synthèse de l’état de l’art

De très nombreuses possibilités sont offertes aux développeurs souhaitant concevoir une application répartie. Mais le dénominateur commun reste toujours l’intergiciel. Il permet de s’abstraire de la couche réelle de communication, et introduit des concepts de plus haut niveau comme les services, les objets et composants répartis, les files de messages, les espaces partagés.
Les intergiciels les plus utilisés aujourd’hui présentent un modèle de programmation fortement couplé à un modèle de communication. Ils ne proposent pas ou peu de possibilités d’adaptation aux changements de contexte.
Ils sont donc très efficaces dans un contexte donné, mais leur conception statique pose vite problème dans des situations de mobilité par exemple.
Il existe également des intergiciels réflexifs ou multi-modèles, capables d’une part de modifier leur propre comportement pour s’adapter aux changements extérieurs, et d’autre part de communiquer avec des composants développés avec plusieurs intergiciels différents.

Table des matières

Introduction
1 Contexte des travaux
1.1 Applications distribuées
1.2 Domaine d’application : les transports
1.3 Programmation objet – vocabulaire utilisé
2 Problématique initiale
2.1 Développement d’applications réparties
2.2 Déploiement des applications
2.3 Notion de mobilité
3 Proposition
3.1 Infrastructure logicielle
3.2 Modèle de programmation
3.3 Modèles de communication
3.4 Approche multi-modèles
4 Organisation du document
I.1 Intergiciel de communication : définition
I.1.1 Description d’un intergiciel [de communication]
I.2 Intergiciels « mono-modèle »
I.2.1 Web Services
I.2.2 CORBA
I.2.3 RMI
I.2.4 .Net Remoting
I.2.5 JMS
I.2.6 JavaSpaces
I.2.7 Synthèse des intergiciels mono-modèles
I.3 Intergiciels réflexifs / multi-modèles
I.3.1 Adaptation au contexte
I.3.2 SCA : l’OpenSOA
I.3.3 FlexiNet
I.3.4 PolyORB
I.3.5 DynamicTAO
I.3.6 Jonathan
I.3.7 OpenORB et ReMMoC
I.3.8 Commutation synchrone/asynchrone
I.3.9 Synthèse
I.4 Principaux modèles de programmation existants
I.4.1 Les signaux
I.4.2 Modèle RPC
I.4.3 Les files de messages, « producteur/consommateur »
I.4.4 Les événements
I.4.5 Les sujets d’intérêt, « publish/subscribe »
I.4.6 Les espaces partagés
I.4.7 Synthèse
I.5 Modèles de programmation basés sur les annotations
I.5.1 Web Services par les annotations Java
I.5.2 Entreprise Java Beans (EJB) par les annotations
I.5.3 SCA par annotations
I.5.4 Synthèse
I.6 Synthèse de l’état de l’art
I.7 Positionnement de nos travaux
I.7.1 Utilisation des annotations
I.7.2 Couplage au sein de l’intergiciel
I.7.3 Comportement réflexif / multi-modèles
II. Approche multi-modèles
II.1 Constats
II.1.1 Modèles de programmations complémentaires
II.1.2 Hétérogénéité des modèles de communication
II.1.3 Modèles de communication complémentaires
II.1.4 Noyau commun aux différents types d’intergiciel
II.2 Principes de l’approche multi-modèles
II.2.1 Modèle de programmation complet
II.2.2 Modèles de communication multiples
II.2.3 Combinaison des modèles de communication
II.2.4 Verrous et challenge
II.3 Inspiration des concepts présents dans l’état de l’art et innovations
II.3.1 Modèle de programmation générique
II.3.2 interopérabilité
II.3.3 Combinaison de modèles pour l’adaptation
II.3.4 Découplage des modèles de programmation et de communication
II.4 Synthèse de notre approche multi-modèles
III.Infrastructure logicielle multi-modèles
III.1 Architecture générale
III.1.1 Organisation centralisée des composants
III.1.2 Méta-modèle de l’infrastructure
III.2 Modèle de programmation générique : la personnalité applicative
III.2.1 Conservation de la programmation traditionnelle
III.2.2 Annotations : séparation des préoccupations
III.2.3 Appel des méthodes du Manager : méthode « directe » de la programmation répartie
III.2.4 Paradigmes de programmation et patrons de conception
III.3 Observateurs de contexte
III.3.1 Notion de contexte
III.3.2 Observations liées aux modèles de communication
III.3.3 Observations liées au matériel et aux couches basses
III.3.4 Observations définies par le développeur
III.4 Politiques d’adaptation
III.4.1 Format des politiques
III.4.2 Application déterministe des politiques
III.5 Combinaison de modèles de communication : les personnalités protocolaires
III.5.1 Interception et redirection des communications
III.5.2 Enrichissement des références des objets : référencement combiné
III.6 Le Manager
III.6.1 Un rôle central dans l’infrastructure : Courtier
III.6.2 Choix de(s) modèle(s) de communication : Gestionnaire d’adaptation
III.6.3 Communication multi-modèles : le changement de modèle en cours d’invocation
III.6.4 Communication inter-manager
III.7 Les communications internes à l’infrastructure : l’objet Multi- ModelInvocation
III.7.1 Nécessité d’un protocole de communication interne
III.7.2 L’objet MultiModelInvocation, une mine d’informations enrichie tout au long de la communication
III.7.3 L’attribut ReturnValue
III.8 A propos des cycles de vie : l’instanciation
III.8.1 Instanciation et libération du proxy
III.8.2 Cycle de vie de l’objet réparti
III.9 Exemples et illustrations du principe : les intergiciels existants
III.9.1 RMI : le « tout synchrone »
III.9.2 JMS : le « tout asynchrone »
III.9.3 La commutation Synchrone / Asynchrone
III.10Synthèse de notre proposition d’infrastructure logicielle multimodèles
IV.Travaux d’application et implémentations
IV.1 Greffon multi-modèles
IV.1.1 Contexte d’étude : projet Train-IPSat
IV.1.2 Problématique et verrous
IV.1.3 Développement du greffon
IV.1.4 Analyse et comparatif des performances
IV.2 L’infrastructure logicielle multi-modèles : implémentation concrète des éléments de l’approche
IV.2.1 Étude de faisabilité : les mécanismes d’adaptation
IV.2.2 Implémentation du modèle de programmation
IV.2.3 Prise en charge des annotations au chargement
IV.2.4 Observateurs de contexte
IV.2.5 Prise en charge des politiques en temps réel
IV.3 Intégration des modèles de communication
IV.3.1 Premier intergiciel pris en charge : RMI
IV.3.2 Intergiciel de type asynchrone : JMS
IV.3.3 Perspective de prise en charge future : CORBA
IV.4 Version statique de l’infrastructure multi-modèles
IV.4.1 Le Manager devient un compilateur offline
IV.4.2 Optimisations et simplifications des mécanismes d’adaptation
IV.5 Infrastructure logicielle multi-modèles : version fonctionnelle
IV.5.1 Prise en compte plus dynamique du modèle de programmation
IV.5.2 Réévaluation des politiques en cours d’exécution
IV.6 Synthèse et conclusion sur les implémentations
V. Impact des travaux
V.1 Implication dans un projet : REVE
V.1.1 Similitudes avec les travaux de thèse
V.1.2 Livrables
V.2 Publications et communications
V.2.1 UbiMob 2006
V.2.2 Journées des doctorants SPI INRETS 2006 et 2007
V.2.3 ITS 2007
V.2.4 ITS-T 2007
V.2.5 EuroDoc Info 2008
V.2.6 SpaceAppli 2008
V.2.7 WCRR 2008
V.3 Synthèse de l’impact de nos travaux
VI.Conclusion
VI.1 Intergiciels actuels et mobilité
VI.2 Approche multi-modèles
VI.3 Implémentations et résultats
VI.4 Perspectives
Références

Télécharger le rapport complet