Changement dynamique de modle de communication

1
Changement dynamique de modèle de communication

• Victor Budau, Guy Bernard
• Institut National des Télécommunications
• victor.budau_at_int-evry.fr

2
Modèles de programmation
Avant de présenter les travaux en cours une
analyse comparative des modèles de programmation
et communication va être faite pour justifier
notre démarche. La programmation des SR devenant
assez complexe, parallèlement avec le
développement des couches logicielles rendant des
services aux applications, les modèles de
programmation ont évolué aussi pour faciliter la
compréhension, la conception et l implantation
des SR. Parmi ces modèle, les appels de
procédures distantes et les modèles basé sur la
génération et la notification des événements se
sont imposés comme des solutions viables pour la
programmation distribuée.

• Programmation complexe gt nouveaux modèles de
  programmation
• les appels de procédures distantes
• une entité demande à une autre d exécuter une
  opération à sa place
• modèles basés sur des événements
• notification d un changement d état

3
Modèles de programmation
Dans un paradigme de communication  client-
serveur  bien desservie par le modèle de
programmation par invocations distantes la
communication apparaît lorsque une entité
demande à une autre d exécuter une opération à
sa place. Le client doit connaître l existence
d un serveur capable de satisfaire sa requête et
doit obtenir sa référence. Dans le deuxième cas,
celui d une architecture basée sur des
événements ses composants coopèrent par lenvoi
et la réception d événements. La source
transmet un message à un aiguilleur de message
qui se charge de le distribuer à tous les
composants ayant déclaré leur intérêt dans la
réception du message.

• Invocation distante
• Modèle basé sur des événements

connaître existence
obtenir référence
4
Modèles de programmation / communication
Associer un modèle de communication aux modèles
de programmation présentés, n est pas toujours
une chose faite en fonctions des besoins réels
des applications mais plutôt en fonctions des
convenances sémantiques ou des limitations de
choix. Des aspects objectifs tels que le choix de
la plate-forme ou le langage, voir le compilateur
, font en sort qu'on utilise linvocation
synchrone dans un paradigme de programmation RPC
tandis que le modèle de programmation basé sur
des événements dispose naturellement d une
communication asynchrone, avec des messages

• Associer un modèle de communication qui
• convient aux besoins des applications
• suit la sémantique du modèle de programmation
• Le choix de la plate-forme ou limplémentation du
  langage / compilateur font cette association
  implicite
• communication synchrone pour RPC
• communication asynchrone pour le modèle de
  programmation basé sur des événements

5
Modèles de communication
La communication synchrone implique la
disponibilité simultanée des entités pour la
communication. Sa ressemblance sémantique avec
linvocation locale et sa simplicité
dutilisation font que le mariage invocation
distante communication synchrone et un vrai
standard dans les SR. Il est utilisé partout
...zzZZzz...

• Invocation synchrone
• ressemblance sémantique avec l invocation locale
  
• obj.méthode (param)
• RPC, RMI, CORBA ORB

6
Modèles de communication
Dans l autre cas, la communication asynchrone
sappuie sur une infrastructure qui fournit des
facilités pour la création, lenvoi, la réception
et la lecture de messages. Pour communiquer on
crée et envoie un message à une tierce entité qui
le stocke dans une fille d attente. Les
récepteurs soit contactent l agent intermédiaire
pour obtenir le message, soit s inscrivent
auprès du même agent pour se faire livrer. Il
n y a pas des interfaces de programmation a part
celles nécessaires à la gestion des messages.

• Communication asynchrone
• pas dinterface
• send(message)

pull
Récepteur(s)
Emetteur
MOM
push
(Message Oriented Middleware)
7
Modèles de programmation / communication
En analysant cette synergie entre les deux types
de modèles (de programmation et de communication)
on se demande -gt Est-ce on ne pourrait pas
utiliser des messages pour communiquer avec un
serveur qui affiche une interface et attend des
invocations? Ou, à l envers, dans un paradigme
de programmation basé sur des événements, peut-on
contacter ces entités par l intermédiaire des
invocations directes, synchrones? Enfin, ce
changement de type de communication pourrait-il
être réalisé pendant lexécution du programme
(dynamiquement) et non pas être prédéterminé à la
conception? Avant danalyser ces possibilités
croisées l intérêt d une telle démarche doit
être justifié

• Dans quelle mesure l adoption d un modèle de
  programmation influence-t-elle le choix du modèle
  de communication?
• orthogonaux gt combinaisons hybrides

Modèle de communication
8
Régime hybride de communication
Pour mieux comprendre la motivation de changer de
modèle de communication pendant la communication
elle-même prenons l exemple banalisé de la
communication téléphonique. Le réseau propose 2
types de communication le service téléphonique
de base et celui par messages (vocaux ou SMS). Le
premier est synchrone car nécessite la présence
simultanée de deux interlocuteurs. Si le contact
échoue (appareil éteint) la connexion ne pourra
pas être établie et le système propose à
l initiateur de laisser un message sur un
support stable. Ainsi une communication
asynchrone est établie en cas d échec de la
communication synchrone. Elle évite le rappel
systématique La transposition -gt

• La communication par messages évite le rappel
  systématique
• Transposition dans les systèmes répartis
  fournir le choix dynamique du type de
  communication synchrone ou asynchrone
• Décision système

échec
Messagerie
9
Commutateur S/A (synchrone/asynchrone)
Afin de permettre un changement transparent de
type de communication un modèle d intercepteur
doit être mis place. Sur chaque nud il existe un
élément qui intercepte les messages ou les
invocations à la fois entrantes et sortantes.
Supposons qu un composant essaie de communiquer
avec un autre et effectue pour cela une
invocation. Dans ce cas le commutateur laisse
passer celle-ci sans la modifier. Si la connexion
est impossible, l infrastructure sous-jacente va
retourner une exception qui est capté par
l intercepteur. Il initie une communication
asynchrone en empaquetant l invocation originale
et la postant dans un serveur de messages. Quand
le serveur est à nouveau disponible, le message
lui est remis (en effet l invocation déballée
car il attend des invocations lui). L usage de
messages pour contourner l impossibilité d un
dialogue direct est totalement transparente aux
2 entités. Scénario inverse - elim surcoût

• Si transparent gt modèle intercepteur
• Changement de type de communication suite a une
  exception / selon une configuration

Invocation
Service de messages
Message (invocation empaquetée)
10
Synchronisme - Asynchronisme
Selon les modèles utilisés on distingue 4
combinaisons possibles 1,2 les plus répandues. no
comment 3 - offre la possibilité à une
application basée sur des événements de
bénéficier de la rapidité relative de la
communication avec des invocations synchrones.
L intérêt est d éviter le surcoût du service de
messages 4 - combine la- gt Mais dans ce cas - gt

• 1,2 des vrais standards
• 3 élimine le surcoût du service de messages
• 4 facilité de programmation flexibilité du
  dialogue par messages
• On profite assez de l asynchronisme de la
  communication?

11
Synchronisme - Asynchronisme
... res serv.méthode(param) ...
12
Synchronisme - Asynchronisme
-gt Un appel de ce type ne retourne que lorsque
linvocation a été achevée avec succès (v. page
précédente) Une amélioration est représentée par
le type de méthode oneway dans CORBA. Pourtant
elle ne garantit pas la livraison et seules les
méthodes qui n'attendent pas un résultat peuvent
être étiquetées avec le label oneway Si la
méthode doit retourner un résultat d autres
structures syntaxiques ont été développés pour
contourner ce problème.

• Les langages de programmation proposent en
  général des appels bloquants pour les invocations
  distantes
• Améliorations
• CORBA IDL oneway
• sémantique best-effort
• seules les méthodes qui n attendent pas de
  résultat
• Futures, Promises, delegates
• retardent le blocage de linvocation jusquà la
  demande explicite du résultat

13
Synchronisme - Asynchronisme
Pour rendre les appels non-bloquants, la solution
courante est la modification de la syntaxe et
l utilisation d un thread pour chaque
invocation (RMI Asynchrone, .NET) -gt

• Pour rendre les appels non-bloquants
• modifications de la syntaxe
• un thread par invocation
• Bien que gérés par les conteneurs
• gestion  lourde 
• synchronisation - souvent source d erreurs
• Le commutateur S/A élimine l utilisation des
  threads

14
Commutateur S/A
Les solutions trouvées pour rendre les
invocations plus performantes ont des  effets
secondaires  Si ces optimisations passent par
des compilateurs particuliers et des protocoles
de sérialisation propriétaires. -gt

• Effets secondaires des modèles modifiés
• incompatibles avec les systèmes  standard 
• éloignement des modèles de programmation usuels
  gt usage limité
• Commutateur S/A
• Le mécanisme de changement dynamique de modèle de
  communication n altère pas le modèle de
  programmation choisi
• Les plus importants aspects du commutateur
• le changement de modèle est dynamique
• n altère pas le modèle de programmation
• transparent (le code applicatif reste intact)

15
Commutateur S/A

• Il emploie dune manière transparente différents
  moyens de communication (JavaRMIJMS,SOAP)
• Les systèmes répartis sont plus efficaces si
  programmés avec un modèle de programmation basé
  sur des événements
• difficile
• gt  easy-to-use-and-understand  RPC models
• C est là que le commutateur S/A trouve son
  utilité

16
Implementation

• Plate-forme J2EE JavaRMI, JMS, MDB
• 1) Conversion Message - Invocation
• objet Invocation --gtsérialisation Java --gtJMS
  message
• 2) Passage de ASYN à SYN
• Dans le paradigme événements la source ne
  spécifie pas le(s) destinataire(s)
• La communication synchrone nécessite la
  connaissance du destinataire
• Si pas de modifications du serveur message gt
• protocole d échange de stubs pour éliminer
  l extra hop
• 3) gestion des erreurs, élimination du service de
  messages

17
Conclusions

• Changement dynamique et transparent de modèle de
  communication
• Garde le modèle de programmation et le code
  applicatif intact
• Gains de performance, adaptation aux changements
  d environnement, applications à grande échelle,
  mobiles
• coupure de canaux de transmission
• indisponibilité temporaire des serveurs
• reconfigurations architecturales
• Si adaptation transparente gtprotection du code
  applicatif face à la reconfiguration système
• Besoin de mesures de performance pour validation