Application Rparties

1
Application Réparties

• Pascal Molli
• Maître de Conférence,
• Université Henri Poincaré.

2
Principales Références...

• Développement d application réparties, Principes
  et applications en Java (Hagimont, Riveill).
  Greco Informatique
• Ecole d été  Construction d application
  réparties  (IMAG, INRIA, LILFL).
• Cours de Roger Withney (University San Diego)

3
Application réparties
Source Balter/Riveill

• Application répartie traitements coopérants sur
  données réparties
• Coopération communication synchronisation
• Modèle d exécution
• interface de programmation
• Outils de développement

4
Applications réparties

• Distribution des données
• Données distribuées traitement centralisé
• Distribution du contrôle
• Données centralisées, contrôle distribué
• Distribution des utilisateurs
• Données et contrôle centralisé, utilisateurs
  distribués
• Un combinaison de tout ça...

5
Examples d application réparties

• Coordination dactivités
• Systèmes à flots de données (workflow)
• Systèmes à agents
• Communication et partage dinformation
• Bibliothèques virtuelles
• Collecticiels
• Édition coopérative
• Téléconférence
• Ingénierie concourante

6
Examples d applications réparties
Source S. Krakoviac CAR99

• Applications temps réel
• Contrôle de procédés
• Avionique, etc.
• Localisation de mobiles
• Nouveaux services grand public
• Presse électronique
• Télévision interactive
• Commerce électronique

7
Un exemple Workflow
Source S. Krakoviac CAR99
Source Krakoviac (école objets répartis 99)
8
Workflow...
Source S. Krakoviac CAR99
9
Workflow
Source S. Krakoviac CAR99

• Coordination des tâches
• Synchronisation et communication
• Mécanismes à base dévénements
• Gestion de lexécution
• Association tâche - agent
• Rôles, groupes de processus
• Adaptation à lenvironnement
• Correspondance structure logique -gt structure
  physique
• Support (système centralisé, grappe, LAN, WAN, )
• Protocole (objets partagés, RPC, CORBA, bus, WWW,
  )
• Réutilisation de lexistant

10
E-Commerce
Source S. Krakoviac CAR99
11
E-Commerce
Source S. Krakoviac CAR99

• Panne dans les étapes 1 à 4
• aucune transaction financière na eu lieu
• pas de paiement, pas de livraison
• Panne après émission de 5 (ordre de paiement)
• le client a accepté le produit
• pas de réponse du serveur
• le client a linitiative de la reprise (contacte
  fournisseur ou serveur NetBill pour connaître
  létat de la requête)
• Erreurs possibles
• Ordre de paiement non transmis au serveur
  annuler (délai de garde)
• Ordre de paiement transmis et accepté
  (transaction) le client finira par recevoir la
  clé (si besoin, du serveur)

12
E-Commerce
Source S. Krakoviac CAR99

• Panne dans les étapes 1 à 5
• aucune transaction financière na eu lieu
• pas de paiement, pas de livraison
• Panne après émission de 6 (facture)
• le fournisseur finira par obtenir une réponse du
  serveur NetBill (au besoin en renvoyant la
  facture 6)
• propriété transactionnelle sur 67 (envoi
  facture et résultat du réglement) annulation
  possible si panne durable
• Source pour NetBill http//www.ini.cmu.edu/NETBI
  LL/

13
E-Commerce
Source S. Krakoviac CAR99

• Sécurité
• Confidentialité (secret des informations)
  chiffrement
• Intégrité (pas de modifications non désirées)
• Authentification
• des partenaires (signature électronique)
• du contenu des messages
• Tolérance aux fautes
• Atomicité des transactions commerciales
  (paiementlivraison)
• Garanties assurées par le serveur (état défini,
  opérations transactionnelles)
• Pas dhypothèses sur sites extérieurs au serveur

14
Vidéo-Conférence
Source S. Krakoviac CAR99

• Réunion virtuelle (broadcast du flot audio/video
  aux autres participants)
• PB
• Déploiement sur réseau hétérogène
• Adaptation aux conditions variables
  d exploitation
• Montée en charge

15
Contruction dapplications réparties
Source Riveill/hagimont greco99

• Conception de l architecture de l application
• Programmation des entités logicielles
• Utilisation d un mécanisme de communication avec
  un modèle d exécution (socket, rpc, rmi)
• Programmation en fonction du modèle d exécution
  
• Configuration des entités de diverses provenance
• Installation et déploiement
• Administration
• Surveillance ,maintenance et évolution

16
Exemple Morpion C/S en RMI

• Conception Architecture Client/Serveurnotificati
  on
• Le client passe des commandes au Serveur (joueur
  joue)
• Le Serveur notifie les changements d état aux
  clients (joueur X à joué en (x,y)) (notification
  gérée en C/S aussi)

17
Example suite

• Modèle d exécution
• Appel de procédure à distance (RMI)
• Ajout des classes techniques
• Serveur et client implante remote-objet
• Serveur externalise une méthode execute
• Client aussi
• Pattern  commande  

18
Example suite

• Configuration
• Mise en place des politiques de sécurité
• fichier de sécurité
• Mise en place des serveur d authentification
• Configuration Serveur Web pour recevoir l applet

19
Exemple Suite

• Déploiement (applet client)
• Copie des .class adéquats sur le serveur
• Démarrage rmiregistry
• Démarrage Serveur http
• Démarrage Server Morpion
• Accés distant à la page Morpion depuis client
• Et maintenant ça marche pas -D

20
Schéma général d appli répartie
Source Krakoviac CAR99

• Middleware couche logicielle destinée à
• masquer l hétérogénéité des machines et systèmes
• masquer la répartition des données et des
  traitement
• fournir une API de programmation

21
Problèmes généraux

• Tolérance aux pannes (reliability,
  fault-tolerance)
• Un serveur participant à l application crash..
• Un serveur raconte n importe quoi
• Un serveur n est plus atteignable (mais n est
  pas crashé) et le redevient
• Atomicité dans les application réparties...

22
Problèmes généraux

• Passage à léchelle (scalability)
• ça marche pour 1 utilisateur et pour 10000 ?
• ça marche pour un objet et pour 1000000 ?
• Ça marche pour 1 site et pour 1000 ??
• Ex Construire un serveur E-Commerce résistant à
  10 000 utilisateurs simultanés ?
• Application serveur pooling, cache, réplication,
  duplication, monitoring

23
Problèmes généraux

• Nommage (naming)
• Un objet Un Id Un état Un comportement
• Appli non répartie Nommage géré par le langage
  (référence) ou l OS (addressage)
• Appli répartie nommage explicite ? Dynamique ?
• Ex Url, DNS, JNDI, X500, LDAP ...

24
Problèmes généraux

• Intégration de l existant (legacy)
• Connexion sur toutes les ressources de
  l entreprise
• Facturation, Gestion de Stock, Workflow
• Intéropérabilité
• Transactions réparties

25
Problèmes généraux

• Déploiement
• Tout est prêt Comment j installe tous mes
  composant logiciels sur mes différents serveurs
  et clients ?
• Je change un nom de serveur, ou j en ajoute un
  je recompile tout ? Je redéploie tout ? Ou je
  peux configurer le déploiement ?

26
Problèmes généraux

• Sécurité
• Confidentialité
• Intégrité
• Droits d accès, Pare-feux
• Authentification
• Identification partenaire
• Non-répudiation
• Messages authentifiés

27
Problème généraux
Source Withney

• Security/Logging
• How many people use your server?
• How will you know if someone is trying to hack
  into your server?
• How will you know what they did?
• If something goes wrong in the server how will
  you know? How will you determine what went wrong?
• How will you know if a particular client program
  has trouble connecting to your server?
• Servers need to log client access

28
Problèmes généraux

• Disponibilité (availability)
• Un système occupé à faire autre chose (par
  exemple gérer la tolérance aux fautes) n est pas
  disponible !
• Ex serveur mono-thread
• 2 appels simultanés sur un même objet distants ?
• Sérialisé ?
• Parallèle ?
• Différentes politiques ?

29
Problèmes Généraux
Source Krakoviac CAR99

• Coordination Communication Synchronisation
  données partagées
• Synchronisation
• Mécanisme élémentaires Messages, événements...
• Transaction réparties
• Workflow
• Communication
• Synchrone, asynchrone, flots discrets ou continus
• Information partagées
• Données centralisées, réparties, dupliquées
  (cohérence des données)

30
Problèmes généraux

• Développement, génie logiciel
• Outils pour gérer
• Conception
• Déploiement
• Débogage !!!!

31
Modèle d exécution...

• Modèle Client-Serveur
• (RPC, RMI, Corba, Servlet)
• Modèle de communication par messages
• MOM, Message oriented middleware,
• Queue de messages
• Modèle de communication par événements
• publish/subscribe, push/pull, JMS
• Modèle à Composant
• Bean, EJB
• Modèle à agents mobiles
• Agglet, Voyager
• Modèle à mémoire  virtuelles  partagées.
• Modèle à espace de tuples(JavaSpaces)
• Modèle à objets dupliqués

32
Modèle Client/Serveur
Requête
Client
Serveur
Réponse
Client

• Emet des requêtes et attend la réponse
  (Synchrone)
• Initiateur du dialogue

• Externalise le service
• Attend les requêtes et les exécutent (en
  séquentiel ou parallèle)

33
Client Serveur
Client
Serveur
Exécution
getSolde( molli )
-3000
Exécution suspendue (appel synchrone !)
Exécution single thread ou multi-thread
34
Client/serveur
Designation serveurobjet receveur ou fonction à
exécuter ??
(1)
Client
Serveur
getSolde( molli )
Exécution
stub
skel
(2)
-3000
(3)
Encodage/ décodage des paramètres passage par
valeur, référence ??
35
Stub et skeletton
Source Balter CAR99

• Stub
• interface coté client
• reçoit l appel en local
• emballe les paramètres
• attends les résultats du serveur
• déballe les résultats
• redonne la main à la fonction appelante

• Skeletton
• interface coté serveur
• recoit l appel sous forme de  stream 
• déballe les param
• demande l exécution
• emballe les paramètres resultats (resultats
  param par réf)

36
Client/Serveur PB généraux

• Préserver la sémantique des langages
• (langage clientltgt langage serveur)
• interopérabilité des données
• Système client ltgt système serveur
• Big/little indian, ASN1, XDR
• Traitement des défaillances
• client, serveur, réseau,
• gestion des time-out
• Nommage
• à la compil en dur ou à l exécution, à chaque
  appel ?

37
Client/Serveur PB généraux

• Sécurité
• authentification
• confidentialité
• intégrité
• Performances
• gestion de la concurrence coté serveur
• passage par valeur/référence,
• cout d encodage/décodage

38
Client/Serveur et sessions
Source Withney

• Stateless Server
• Client connects to the server
• Client makes one request
• Server handles request
• Client and server drop connection
• Stateful Server
• Client connects to the server
• Client makes one request
• Server handles request
• Client makes another request
• Server handles request
• etc.

39
C/S et Sessions
Source Withney

• Server needs to remember information about the
  client while the client is connected - the state
  of the connection
• Stateful servers are much more complicated than
  stateless servers
• Ex Transactions

40
Mise en uvre Serveur Unique
Source Riveill/Hagimont greco99

• Processus Serveur Unique

41
1 Processus par service
Source Riveill/Hagimont greco99
42
1 processus par service
Source Riveill/Hagimont greco99
43
Modèle Client/Serveur

• Client/Serveur  traditionnel 
• RPC
• Client/Serveur  à objet 
• RMI, Corba, DCOM
• Client/Serveur  de données 
• Requêtes SQL
• Client/Serveur  WEB 
• CGI, servlet, asp, jsp, php...

44
C/S RPC
Source Balter CAR99

• Repr des données échangées ASN1,XDR
• Défaillance timeout (client et serveur)
• Nommage serveurportfunction
• Session ? Sécurité ? Performance ? Pannes ?

45
C/S à objets
Source Balter CAR99

• Paradigmes objets encapsulation polymorphisme,
  composition, généricité
• objet unité de désignation et de distribution
• Session ? Sécurité ? Performance ? Pannes ?

46
C/S à objets
Source Balter CAR99

• Attention à la cohabitation de plusieurs langages
  à objets (C/Java)
• avec RMI Javalt-gtJava, conçu comme une extension
  du langage (DGC, passage par valeur). Les objets
   remote  sont des objets Java
• avec CORBA indépendant d un langage, mise en
  place d un langage pivot (IDL). Les objets
   remote  sont des objets CORBA. Instance de
  l IDL

47
C/S à objets
Source Balter CAR99
48
C/S Corba
Source Balter CAR98
49
C/S à objet Corba

• Le client et le serveur peuvent être écrit dans
  des langages différents
• IDL un langage d interface permet de définir
  des objets intermédiaires (corba) existant dans
  un serveur intermédiaire  broker .

50
Broker pattern...
Source A system of patterns Buschmann et al
51
Corba
Source Roger withney

• A broker
• Handles the transmission of requests from clients
  to servers
• Handles the transmission of responses from
  servers to clients
• Must have some means to identify and locate
  server
• If server is hosted by different broker, forwards
  the request to other broker
• If server is inactive, active the server
• Provides APIs for registering servers and
  invoking server methods
• Bridge
• Optional components used for hiding
  implementation details when two brokers
  interoperate

52
Corba service registration
Source A system of patterns Buschman et al
53
Corba C/S interaction
Source A system of patterns Buschman et al
54
CS/ objet Corba Bridge
Source A system of patterns Buschman et al
55
C/S notifications (serveur/serveur)
Source R. Withney
56
C/S objet Corba

• Avantages Corba
• indépendance de la localisation (localis ation
  independant)
• intégration d application existantes (legacy)
• Passage à l échelle

57
C/S de données
Source BalterCAR98

• Client Code de l application non lié aux
  données (séparation données/traitement)!!
• Pourquoi pas de stub/skel avec des requêtes SQL
  ??
• Impedance mismatch avec le langage hote.
• Médiateur (DBLib) préparation/Communication des
  requêtes, gestion de caches, connexion
• Session ? Sécurité ? Performance ? Pannes ?

58
C/S Web

• La requête est conforme htpp1.1 (get, post) URL
  param (normalisé)
• Le serveur web résout le nommage et active un
  traitement coté serveur (servlet, CGI-bin, jsp)
• Le serveur répond en renvoyant un  stream  dont
  il déclare le type (html ou autre)
• Ou sont les stub et skeleton ??

59
Conclusion C/S

• Avantage modèle habituel de programmation
• PB
• Appel synchrone
• Connexion 1-1
• Désignation explicite du receveur...
• Outils de développement génération automatique
  des stub/skel et c est tout.

60
Modèle d exécution...

• Modèle Client-Serveur
• (RPC, RMI, Corba, Servlet)
• Modèle de communication par messages
• MOM, Message oriented middleware,
• Queue de messages
• Modèle de communication par événements
• publish/subscribe, push/pull, JMS
• Modèle à Composant
• Bean, EJB
• Modèle à agents mobiles
• Agglet, Voyager
• Modèle à mémoire  virtuelles  partagées.
• Modèle à espace de tuples(JavaSpaces)
• Modèle à objets dupliqués

61
Modèle de communication par Message
Source Balter CAR99

• Mode de synchronisation
• Communication asynchrone
• émission non bloquante
• réception bloquante (attente jusqu à reception
  d un messsage)
• Mode de communication
• Communication directe entre processus (agent)
• Communication indirecte via des  portes 
  (boîtes aux lettres)
• Mode de transmission
• Peut-être typés

62
Communication par messages
Source Balter CAR99

• Appel asynchrone

63
Communication par messages
Source Balter CAR99

• Simulation d un client/serveur avec une
  communication par message

64
Communication par messages
Source Balter CAR99

• Environnement à la UNIX
•  Socket  (un peu draft quand même)
• Environnement de programmation parallèle
• PVM et MPI
• Environnement industriel
• Middleware à message (MOM)
• normalisation JMS (java messenging service)

65
MOM et queues de messages
Source Balter CAR99

• Queue de messages à ID uniques
• Persistantes, fault-tolerant, mettre un
  messagetransaction ACID !
• Partagées par les applications
• Sécurité droits d accès confidentialité

66
MOM API
Source Balter CAR99

• MsgQ.attach(name, type) -gt msgQ
• SendQ.sendMsg(msg)
• RecvQ.recvMsg(wait)-gt msg
• RecvQ.confirmMsg(msg)
• MsgQ.detach()
• Mode de réception variable
• Exemple Isis, Horus.

67
Conclusion
Source riveill/hagimont Greco99

• Bus logiciels à messages (MOM)
• appel asynchrone
• envoi de messages
• désignation explicite ou anonyme du destinataire
• connexion 1-1 ou 1-n ou diffusion
• Avantage
• simplicité du modèle, pas d interblocage
• PB propagation d erreurs

• Bus Logiciel C/S (Corba, RMI)
• appel synchrone (RPC)
• Désignation explicite du destinataire
• Connexion 1-1
• Avantage
• habitué aux appels de procédure

68
Modèle d exécution...

• Modèle Client-Serveur
• (RPC, RMI, Corba, Servlet)
• Modèle de communication par messages
• MOM, Message oriented middleware,
• Queue de messages
• Modèle de communication par événements
• publish/subscribe, push/pull, JMS
• Modèle à Composant
• Bean, EJB
• Modèle à agents mobiles
• Agglet, Voyager
• Modèle à mémoire  virtuelles  partagées.
• Modèle à espace de tuples(JavaSpaces)
• Modèle à objets dupliqués

69
Communication événementielle
Source Balter CAR99

• Concepts de base
• événements, réactions
• Principe d attachement
• association dynamique entre un type d événement
  et une réaction
• Communication anonyme
• Indépendance entre l émetteur et les
   consommateurs  d un événement
• Finalement, un modèle par délégation.

70
Communication événementielle
Source Balter CAR99
71
Communication événementielle
Source Riveill/Hagimont Greco99
72
Gestion des événements
Source Balter CAR99

• Mode  pull 
• Les clients viennent prendre périodiquement leurs
  messages
• Mode  push 
• Une méthode prédéfinie est attachée à chaque type
  de message
• Elle appelée automatiquement à chaque occurrence
  de l événements.

73
Gestion d événements
Source Riveill/Hagimont Greco99

• Pull
• //créer et lier file
• msgQnew MsgQ(name, properties)
• // produire message
• sendQmsgQ.attachSender(type)
• sendQ.sendMsg(msg)
• //consommer message
• rcvQmsgQ.attachRecv(type)
• msgrecvMsg(wait,select)
• recvQ.confirm(msg)
• // délier une file
• msgQ.detach()

• Push
• // créer et lier une file
• topicnew Topic(name,properties)
• //produire un message
• pubtopic.createPub()
• pub.publish(msg)
• //consommer un message
• subtopic.createSub()
• sub.subscribe(msg_reaction)
• //délier une file
• topic.detach()

74
Gestion des événements
Source Balter CAR99

• Serveur centralisé protocole point à point
  architecture  hub and spoke 

75
Gestion d événements
Source Balter CAR99

• Serveur réparti architecture  snowflake 

76
Gestion d événements
Source Balter CAR99

• Architecture bus de messages
• Service réparti de gestion d événements.
  Protocole multicast

77
Communication événementielle Conclusions
Source Balter CAR99

• Domaine d application
• Génie logiciel (coopération entre outils de
  développement) softbench, tooltalk
• Workflow koala bus
• diffusion de logiciels et d information sur le
  web
• iBus, castanet, ambrosia, active WEB
• Gestion des notifications...

78
Modèle d exécution...

• Modèle Client-Serveur
• (RPC, RMI, Corba, Servlet)
• Modèle de communication par messages
• MOM, Message oriented middleware,
• Queue de messages
• Modèle de communication par événements
• publish/subscribe, push/pull, JMS
• Modèle à Composant
• Bean, EJB
• Modèle à agents mobiles
• Agglet, Voyager
• Modèle à mémoire  virtuelles  partagées.
• Modèle à espace de tuples(JavaSpaces)
• Modèle à objets dupliqués

79
Modèle par composant
Source

• Définition d un composant
• Module logiciel autonome (self contained) et
  réutilisable
• Peut-être composé visuellement (donc
  dynamiquement !) pour former une application
  (application builder).
• Beans, EJB, Corba Component.

80
La philosophie des composants
Source IBM online course
81
Composants

• Un composant
• des inputs/outputs déclarés
• pour établir des connexions
• des propriétés déclarées
• pour configurer le composant
• pour l écran voltage, taux de rafraichissement
• pour l ordinateur la séquence de boot, avec ou
  sans passwd
• Utiliser des composants
• Les connecter et les configurer

82
Composant JavaBeans...

• Bean classe conventions d écriture
• Inputméthodes publiques
• Propriétésvariables d instances
  accesseurs/modificateur
• Outputévénements émis
• Mais ATTENTION
• on connecte et on configure des INSTANCES!!
• Les instances sont créées sur un BeanContainer
  (modèle par composition)

83
Composant Bean

• Le BeanContainer doit être capable d interroger
  les INSTANCES pour
• Découvrir les propriétés qui peuvent être
  manipulées
• Comment elles doivent être manipulées
• Découvrir les événements qui peuvent être émis
• Utilisation de l introspection ! La classe class
  !!

84
Composant Bean !

• Pour aider le BeanContainer, on prend les
  conventions d  écriture suivantes
• Constructeur de la classe sans paramètres
• Set/Get Methodes pour les propriétés
• Add/Remove methodes pour les événements

85
Exemple Alarm Bean

• Un timer
• Propriétés durée du time-out
• private int timeout30
• input
• public void start(),
• public void stop()
• output
• public void addAlarmListener (AlarmListener
  listener) ...
• public void removeAlarmListener (AlarmListener
  listener) ...

86
Alarm Bean...
Source Pas de moi mais je sais plus -D
public class AlarmBean implements Runnable,
Serializable protected int timeout 1000
public AlarmBean () public void setTimeout
(int t) timeout t public int
getTimeout () return timeout
transient protected Thread alarm public
synchronized void start () ... public
synchronized void stop () ... public void run
() ... protected Vector listeners new
Vector () public void addAlarmListener
(AlarmListener listener) listeners.addElemen
t (listener) public void
removeAlarmListener (AlarmListener listener)
listeners.removeElement (listener)
protected void dispatchAlarmCall ()
AlarmEvent event new AlarmEvent (this)
Vector listeners (Vector) this.listeners.clone
() for (int i 0 i lt listeners.size ()
i) ((AlarmListener) listeners.elementAt
(i)).alarmCalled(event)
87
Alarm Bean et Juggler Bean...
88
Composant Bean

• Quand l alarme est activée
• il faut appeler juggler.stop()
• l application builder appelle
• alarm.addAlarmListener(juggler)
• et génère un adapteur qui implémente
  AlarmListener et dans alarmCalled() appelle
  juggler.stop().
• L adapteur est généré, compilé et chargé pendant
  l exécution de l application builder...

89
Composants Bean Java
Source IBM online course
1- actionPerformed -gt addItem 2- AddItem avec
textfield.getText() 3- clean-up textfield 4- put
the cursor at the beginning
90
Output de tout ça...
Source IBM online course

• Soit une application Java
• Soit une applet Java
• Soit un nouveau JavaBean qui n est lui-même
  qu une composition de Bean primitifs
• Modèle par composition

91
Composant Bean

• Un bean n est pas forcément un composant visuel
  il remplit une fonctionalité (input/output/propr
  iétés)
• Il peut tout à fait accéder à un objet distant
  (RMI, CORBA), se connecter à un base de données,
  ou attacher une queue JMS.
• Mais pas de de gestion automatique de la
  répartition...

92
EJB L idée...

• Avoir un  framework  pour objet répartis
• Ici -gt un serveur générique qui gère tous les
  problèmes de répartition (availability,
  scalability, security, Fault-tolerance)
• le développeur écrit ses  objets métiers  en se
  conformant au modèle du framwork et profite des
  avantages du framwork
• Un // avec awt...

93
Entreprise Java Bean (EJB)

• Un serveur EJB
• un conteneur avec des services
• de répartition (configurable)
• transactionnel distribué (JTA)
• nommage (JNDI)
• Concurrence (serveur multi-thread)
• Persistence (activation/passivation/pooling par
  JDBC)
• Sécurité (géré par le conteneur)
• Ces services appellent des méthodes fournies par
  le bean (au moment opportun)
• des Entreprise Bean (EB) (business logic)
• Des clients Accés en C/S par RMI/IIOP et/ou JMS

94
EJB Archi...
Source G. Vendome (Objectweb.org)
95
EB Enterprise Bean

• Entity Bean  Business object 
• Ex  Commandes  dans une système de
  e-business, ou  Account  dans un système
  bancaire
• Persistants,
• participent à des transactions,
• fault-tolerant (Panne serveur),
• acceptent les accès multiples de plusieurs clients

96
Entreprise Bean

• Session Bean
• Associé à un seul client !
• Non persistant
• Stateless ou statefull
• Peut gérer un traitement repartit sur plusieurs
  Entity Bean
• Ex Virement(compte1, Compte2)

97
EJB
Source Monica Pawlan http//java.sun.com/product
s/ejb/articles/multitier.html
98
EJB
Source developper guide (sun) http//www.nova-la
bs.com
99
Placement des EBeans
Source www.objectweb.org

• Déploiement configurable sans changement du code
  client ou EB !

100
Conclusion modèle par composants

• Séparer les problèmes de distribution (géré par
  le conteneur)...
• des  business objects 
• A priori, gain de temps pour le développeur ...
• Réutilisabilité configuration adminisatration
• Ex Application Server (Bea WebLogic, WebSphere,
  Jaguar, Jonas)

101
EJB Business Model
Source G. Vendome (Objectweb.org)
102
EJB Business Model
Source G. Vendome (Objectweb.org)
Deployment
Creation
Assembly
Application assembler
Deployer
Component provider
Application
Module
Enterprise Components
Enterprise components
Container/server
103
Modèle d exécution...

• Modèle Client-Serveur
• (RPC, RMI, Corba, Servlet)
• Modèle de communication par messages
• MOM, Message oriented middleware,
• Queue de messages
• Modèle de communication par événements
• publish/subscribe, push/pull, JMS
• Modèle à Composant
• Bean, EJB
• Modèle à agents mobiles
• Agglet, Voyager
• Modèle à mémoire  virtuelles  partagées.
• Modèle à espace de tuples(JavaSpaces)
• Modèle à objets dupliqués

104
Systèmes à agents mobiles

• Daniel Hagimont
• INRIA Rhône-Alpes
• http//sirac.inrialpes.fr/hagimont

105
Plan de la présentation

• Présentation générale
• Définitions
• Motivations et applications
• Concepts de base
• Caractéristiques techniques
• Etude dun exemple (Aglets)
• Le système
• Ses interfaces
• Exemple dapplication

106
Modèle à agents mobilesExemples de code mobile

• Code mobile programme pouvant se déplacer d'un
  site à un autre sur un réseau
• Exemples
• Postscript
• SQL
• Applets

107
Modèle à agents mobiles Exemples de code mobile

• Postscript
• code exécuté par machine physique ou virtual
• reporte le travail sur différents sites

108
Modèle à agents mobiles Exemples de code mobile

• SQL
• code exécuté par un interpréteur SQL
• code déplacé vers le serveur de base de données

109
Modèle à agents mobiles Exemples de code mobile

• Applets
• programme exécutable inclus dans une page HTML
• exécution sur le site qui télécharge la page HTML

110
Motivations et applicationsMobilité (1)

• Comparaison entre
• appel de procédure à distance (RPC)
• agents mobiles

App
Service
programmationpar RPC
App
programmation par agents mobiles
111
Motivations et applicationsMobilité (2)

• Avantages de la mobilité
• tactique
• efficacité
• privilégie les interactions locales
• moins de messages à distance
• Parfois plus judicieux d amener le code aux
  données que les données au code...
• stratégique
• extension des fonctions dun serveur
• permet aux clients dadapter un serveur à des
  besoins spécifiques

112
Motivations et applicationsMobilité (3)

• Exemple davantage tactique
• un serveur retourne une liste de noms
• un serveur gère un annuaire téléphonique

Service
rpc (1)
App
rpc (n)
Annuaire
113
Motivations et applicationsMobilité (4)

• Exemple davantage stratégique
• un client demande un document à un serveur
• le client passe un algorithme de chiffrement ou
  de compression des données
• le code de cet algorithme est propre au client

agent avec code de compression
App
document compressé
114
Concepts de base (4)
interaction
déplacement
agent
place
site
système support
115
Concepts de base (1)(inspiré de Telescript)

• Agents
• unité de structuration des applications
• agents mobiles ou stationnaires
• ressources allouées (contrôlées) aux agents
• Places
• endroit que peut visiter un agent
• plus fin que le site (contrôle daccès)
• certaines places prédéfinies pour un agent
  (home/proxy)

116
Concepts de base (2)

• Déplacement
• entre des places
• parfois notion ditinéraire
• permet de co-localiser des agents pour des
  interactions locales
• Interactions
• entre des agents co-localisés (meetings)
• appel de procédure ou dobjet
• entre des agents distants messages

117
Concepts de base (3)

• Contrôle daccès
• autorité
• associé à un agent ou une place
• permet une authentification dun agent ou dune
  place
• permis
• des capacités associées à des agents ou des
  places
• permet de limiter des droits daccès

118
Les Aglets

• En général
• un projet dIBM Japon
• conçu sur Java
• Les abstractions
• Contexte une place
• Aglet un agent mobile
• AgletIdentifier un identifiant unique
• AgletProxy un objet daccès
• Message
• message asynchrone
• appel de procédure synchrone ou asynchrone

119
Un aglet (1)

• Une classe qui étend la classe Aglet
• Un graphe dobjets sérialisable
• Des méthodes prédéfinies de gestion des aglets
• Aglet.dispatch (URL url)
• Aglet.deactivate (long time)
• Aglet.clone ()
• Aglet.getAgletContext ()
• Des méthodes définies par le programmeur
• Aglet.onCreation (Object init)
• Aglet.run ()
• Aglet.HandleMessage (Message msg)
• Aglet.onDisposing ()

120
Un aglet (2)

• public class Hello extends Aglet
• public void onCreation (Object init)
• System.out.println (created!)
• public void run ()
• System.out.println (hello!)
• public boolean handleMessage (Message msg)
• if (msg.sameKind(sayHello))
• System.out.println (hello!)
• return true
• return false
• public void onDisposing ()
• System.out.println (bye!)

121
Un proxy

• Un objet intermédiaire pour la manipulation des
  aglets
• moyen dappeler une méthode sur un aglet (pour
  déplacer, envoyer un message ...)
• masque la localisation de laglet
• limite les méthodes appelables sur laglet
• Un aglet peut obtenir un proxy désignant un aglet
• AgletContext.getAgletProxies()
• AgletContext.getAgletProxy (AgletID)
• ou en adressant un contexte (URL) à distance
• ou en le recevant dans un message

122
Un message

• Composé de deux champs
• un type (String)
• un objet
• Peut être passé de trois façons
• appel synchrone
• AgletProxy.sendMessage (Message msg)
• appel à résultat différé
• AgletProxy.sendAsyncMessage (Message msg)
• message asynchrone
• AgletProxy.sendOnewayMessage (Message msg)

123
Programmation de la mobilité (1)

• Programmation basée sur des événements
• une gestion dévénement de mobilité associée à un
  Aglet (MobilityListener)
• définies par le programmeur
• onArrival (MobilityEvent l)
• onDispatching (MobilityEvent l)
• onReverting (MobilityEvent l)
• Même chose pour le clonage (CloneListener) et la
  persistance (PersistencyListener)

124
Programmation de la mobilité (2)
onDispatching ()
onArrival ()
dispatch
aglet
aglet
retract
onReverting ()
125
Programmation de la mobilité (3)

• class myListener implements MobilityListener
• public void onDispatching (MobilityEvent l)
• System.out.println (I am leaving!)
• public void onReverting (MobilityEvent l)
• System.out.println (I am going home!)
• public void onArrival (MobilityEvent l)
• System.out.println (I have arrived!)
• public class MyAglet extends Aglet
• public void onCreation (Object init)
• MobilityListener listener new myListener()
• addMobilityListener(listener)

126
Programmation dun contexte

• Programmation basée sur des événements
  (ContextListener)
• événements concernant le contexte
• contextStarted (ContextEvent ev)
• contextShutdown (ContextEvent ev)
• événements concernant les aglets
• agletCreated (ContextEvent ev)
• agletCloned (ContextEvent ev)
• agletArrived (ContextEvent ev)
• agletDispatched (ContextEvent ev)
• agletReverted (ContextEvent ev)
• agletStateChanged (ContextEvent ev)

127
Limitations des systèmes actuels

• La localisation des agents reste un problème
  difficile sur un réseau à grande échelle.
• doit-elle être prise en charge entièrement par le
  système ?
• Peu de retour sur lintérêt de la technologie
• stratégique intérêt certain, mais peu de
  grandes applications
• tactique pas de mesures

128
Les systèmes à agents mobiles actuels (1)

• Sur Java
• Aglets (IBM)
• http//www.trl.ibm.co.jp/aglets
• Odyssey (General Magic Inc.)
• http//genmagic.com/technology/mobile_agent.html
• Concordia(Mitsubishi)
• http//www.meitca.com/HSL/Projects/Concordia
• Voyager (Object Space)
• http//www.objectspace.com/voyager
• MOA (OSF/OpenGroup)
• http//www.osf.org/RI/java/moa

129
Les systèmes à agents mobiles actuels (2)

• Autres environnements (Tcl, Python ...)
• AgentTcl (Dartmouth College)
• http//www.cs.dartmouth.edu/agent
• Ara (Université de Kaiserslautern)
• http//www.uni-kl.de/AG-Nehmer/Projekte/Ara
• Tacoma (Université de Tromsø et Cornell)
• http/www.cs.uit.no/DOS/Tacoma

130
Conclusion

• Agents mobiles
• agent autonomie et réactivité
• mobiles avantage tactique et stratégique
• De nombreuses implantations sur Java
  Aglets,Odyssey, MOA ...
• Concepts agents, places, messages,
  déplacements, interactions
• Technologie prometteuse pour certaines
  applications
• Des problèmes peu ou pas traités intégration de
  la mobilité, contrôle daccès, tolérance aux
  pannes

131
Modèle d exécution...

• Modèle Client-Serveur
• (RPC, RMI, Corba, Servlet)
• Modèle de communication par messages
• MOM, Message oriented middleware,
• Queue de messages
• Modèle de communication par événements
• publish/subscribe, push/pull, JMS
• Modèle à Composant
• Bean, EJB
• Modèle à agents mobiles
• Agglet, Voyager
• Modèle à mémoire  virtuelles  partagées.
• Modèle à espace de tuples(JavaSpaces)
• Modèle à objets dupliqués

132
Systèmes à mémoire partagée
Source R. Balter

• Motivations
• Replacer le programmeur dans les conditions d un
  système centralisé
• utiliser une mémoire commune comme espace de
  communication
• Synchronisation par variables partagées
• Avantages attendus (pour le programmeur)
• Simplicité distribution  transparente 
• efficacité utilisation des paradigmes usuels de
  la programmation concurrente.

133
Systèmes à mémoire partagée

• Problèmatique
• Utilisation des outils de développement existant
• Langages, compilateur, debuggeurs
• Mise en uvre efficace d une mémoire partagée
  distribuées.

134
Systèmes à mémoire partagée

• Principe simulation d une mémoire globale
  partagée d objets
• Différence vs RMI/Corba ??

135
Systèmes à mémoire partagée
Source R. Balter CAR99

• Approches
• Modèles à espace de tuples
• Base de données (relationnelle) partagées
• Modèle de programmation à la  linda 
• Dépôt, retrait et consultation d objets
• Exemple Javaspaces
• Modèles à objets répartis partagés
• Espace d objets répartis partagés
• Interface de programmation Langage à objets
   étendus 
• Plusieurs mode de réalisation
• Objets répliqués (Javanaise)
• Objets à image unique (exemple Guide)

136
JavaSpace un modèle à espace de tuple.
Source Hagimont

• Un JavaSpace un espace de tuples (entrées)
• Un entrée Un ensemble de champs
• Un champ une référence à une instance Java

137
Java Spaces
Source JavaSpaces Specification
138
JavaSpace Interface
Source JavaSpaces Specification
public interface JavaSpace Lease write(Entry e,
Transaction txn, long lease) throws
RemoteException, TransactionException public
final long NO_WAIT 0 // dont wait at
all Entry read(Entry tmpl, Transaction txn, long
timeout) throws TransactionException,
UnusableEntryException, RemoteException,
InterruptedException Entry readIfExists(Entry
tmpl, Transaction txn, long timeout) throws
TransactionException, UnusableEntryException, Rem
oteException, InterruptedException Entry
take(Entry tmpl, Transaction txn, long
timeout) throws TransactionException,
UnusableEntryException, RemoteException,
InterruptedException Entry takeIfExists(Entry
tmpl, Transaction txn, long timeout) throws
TransactionException, UnusableEntryException, Rem
oteException, InterruptedException EventRegistrat
ion notify(Entry tmpl, Transaction txn,
RemoteEventListener listener, long lease,
MarshalledObject handback) throws
RemoteException, TransactionException Entry
snapshot(Entry e) throws RemoteException
139
JavaSpace

• Pour lire dans un javaspace
• sélectionner une entrée dans un espace de tuple
  (mais pas de SQL ici !)
• Utilisation de  template 
• read lit une entrée conforme à un  template 
• take lit une entrée et la retire du JavaSpace.

140
JavaSpace

• Notifications
• Spécifie un template
• Si une entrée conforme est écrite Notifaction
• Relation avec les transactions
• Les notifications ne partent qu après les commit
  !

141
JavaSpace et Transactions !

• Transaction ACID distribuées !
• Read ou Take posent de verrous en lecture
• les write ne sont visibles qu après Commit
• Utilisation intensive de 2-Phase Commit !

142
JavaSpaces écrire dans 1 Javaspace

• Using a JavaSpace...

JavaSpace space getSpace() AttrEntry e new
AttrEntry() e.name "Duke" e.value new
GIFImage("dukeWave.gif") space.write(e, null, 60
60 1000)// one hour // lease is ignored --
one hour will be enough
143
JavaSpaces
Source Hagimont

• Exemples d  application
• Un marché de livre
• Des Vendeurs/acheteurs peuvent déposer des ordres
  de ventes/acahts
• Ils peuvent sélection des ordres en fonction des
  besoins
• Ils peuvent se faire notifier si un dépôt les
  intéresse.

144
Modèle à espace de tuplesConclusion

• Modèle simple pour écrire des applications
  réparties
• Utilisé dans Jini
• Liaison dynamique à des ressources dans un
  réseau

145
Modèle à objets dupliqués Exemples
Source Hagimont CAR99

• Origine extension aux systèmes répartis des
  méthodes de partage
• partage de la mémoire commune dans un SMP
• partage dun système de fichiers (NFS)
• extension du partage de mémoire virtuelle dans
  Unix

146
Modèle à objets dupliqués Exemples
Source Hagimont CAR99

• Partage de la mémoire commune dans un Sytème
  Multi Processeur
• cache associé à chaque processeur
• Mise à jour immédiate (write through) ou retardée
  (write back)

147
Modèle à objets dupliqués Exemples
Source Hagimont CAR99

• Partage dun système de fichier (NFS)
• cache NFS sur les sites clients
• invalidations périodiques

partition montée
partition exportée
148
Modèle à objets dupliqués Exemples
Source Hagimont CAR99

• Partage de mémoire virtuelle (Unix)
• partage de segments (suite de pages)
• partage de la mémoire centrale par couplage

processus Unix
segment
mémoire centrale
149
Modèle à objets dupliqués Exemples
Source Hagimont CAR99

• Partage de mémoire virtuelle en réparti

150
Modèle à objets dupliquésPrincipe général
Source Hagimont CAR99

• Principe fournir des objets partagés par
  couplage dans les espaces dadressage de
  structures dexécution (couplage virtuel)
  réparties
• Partage par copie locale (efficacité)
• Programmation simple (accès local)
• Le système charge les données à la demande
  (lunité nest pas forcément lobjet)
• Le système assure la cohérence des données
  partagées

151
Modèle à objets dupliquésGestion de la cohérence
Source Hagimont CAR99

• Cohérence relation que gardent entre elles les
  différentes copies des données
• Cohérence séquentielle
• Cohérences faibles
• cohérence faible (weak consistency)
• cohérence à la sortie (release consistency)
• cohérence à l'entrée (entry consistency)
• Cohérences non-séquentielles
• cohérence causale

152
Modèle à objets dupliquésCohérence séquentielle
Source Hagimont CAR99

• Même résultat que si les opérations de tous les
  processeurs exécutées dans un ordre séquentiel
• L'ordre spécifié par le programme est respecté
  par chaque processeur

W(y)4
W(x)1
P1 P2 P3
W(y)2
R(y)2
R(x)0
R(x)1
W2(y)2 R3(y)2 R3(x)0 W1(x)1 R3(x)1
W1(y)4 respecte l'ordre séquentiel
153
Modèle à objets dupliquésCohérence séquentielle
Source Hagimont CAR99

• Les processeurs doivent s'accorder sur l'ordre
  des accès
• un accès en écriture est terminé si une lecture à
  la même adresse rend la valeur écrite (quelque
  soit le processeur)
• chaque écriture doit être terminée pour continuer
  l'exécution
• Dans la pratique, diffusion des modifications à
  tous les sites
• algorithme d'ordonnancement
• lourd et inefficace

154
Modèle à objets dupliquésCohérence séquentielle
Source Hagimont CAR99

• Inutile si synchronisation
• a une variable de synchronisation (avec P et V)
• la diffusion des modifications n'est pas
  nécessaire

P(a) W(x)v W(y)v W(z)v
V(a)
P1 P2
155
Modèle à objets dupliquésCohérences faibles
Source Hagimont CAR99

• Imposent des contraintes de programmation pour
  fournir la cohérence séquentielle
  synchronisation
• La cohérence faible (weak consistency)
• cohérence séquentielle sur les verrous
• les accès mémoires doivent être terminés avant
  chaque point de synchronisation

156
Modèle à objets dupliquésCohérences faibles
Source Hagimont CAR99

• La cohérence à la sortie (release consistency)
• on différencie les points d'entrée et de sortie
• en sortie de synchronisation, les accès doivent
  être terminés
• mise à jour précoce (eager) notification des
  modifications à tous les noeuds ayant une copie
• mise à jour paresseuse (lazy) notification
  qu'au processeur qui reprend le verrou (sorte de
  cohérence à l'entrée)
• TreadMarks

157
Modèle à objets dupliquésCohérences faibles
Source Hagimont CAR99

• La cohérence à l'entrée (entry consistency)
• association explicite entre variable de
  synchronisation et variables partagées
• lorsqu'on utilise un objet, on le vérrouille
• on met en cohérence l'objet lors de la prise du
  verrou
• utilisation possible de diffs
• remarque une mémoire virtuelle répartie paginée
  en est un exemple
• Midway

158
Modèle à objets dupliquésCohérences non
séquentielles
Source Hagimont CAR99

• Cohérence causale
• OP1 précède OP2 causalement si
• OP1 précède OP2 sur le même processeur
• OP2 est une lecture de la valeur écrite par OP1
• OP1 et OP2 sont concurrentes si pas de précédence
  causale transitive
• Cohérence causale deux écritures concurrentes
  peuvent être vues dans des ordres différents sur
  des processeurs différents

159
Modèle à objets dupliquésCohérences non
séquentielles
Source Hagimont CAR99

• Cohérence causale
• complexe à mettre en uvre (trace des
  dépendance)
• gains significatifs (60-90) pour certaines
  applications

W(x)1
W(x)3
P1 P2 P3 P4
//
R(x)1
W(x)2
R(x)3
R(x)2
R(x)1
R(x)1
R(x)2
R(x)3
160
Modèle à objets dupliquésBilan sur les cohérences
Source Hagimont CAR99

• Initialement cohérence séquentielle
• Ensuite cohérences faibles pour l'efficacité
• utiliser les liens entre cohérence et
  synchronisation
• mise en uvre simple de plus
• Plus récemment course à l'efficacité
• des systèmes de plus en plus complexes
• des gains de plus en plus marginaux

161
Modèle à objets dupliqués Conclusion
Source Hagimont CAR99

• Intétêts du modèle à objets dupliqués
• Développement simplifié (distribution
  transparente)
• Favorise les accès locaux
• Limites et perspectives
• Quel protocole de cohérence ?
• Approche mono-langage
• Coût du maintien de la cohérence des objets
  dupliqués (dépendant de la sémantique des appli
  et de l env. d exécution).

162
Modèle d exécut