1 / 50

Programmation réactive et distribution

Programmation réactive et distribution. Laurent Hazard France Telecom R&D 07/02/03. Pourquoi moi ?. FT R&D DTL ASR Recherche et développement Direction des Techniques Logicielles Architecture des Systèmes Répartis « Vieille » collaboration avec Inria/CMA Programmation synchrone, réactive

marie
Download Presentation

Programmation réactive et distribution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Programmation réactive et distribution Laurent Hazard France Telecom R&D 07/02/03

  2. Pourquoi moi ? • FT R&D DTL ASR • Recherche et développement • Direction des Techniques Logicielles • Architecture des Systèmes Répartis • « Vieille » collaboration avec Inria/CMA • Programmation synchrone, réactive • Infrastructures d’exécution

  3. FT R&D DTL ASR • de + en + AS, R se banalise • pôle de compétences • veille technologie • modèle Objet • système d’information • plate-formes de support • peu d’algorithmique (dommage !) • intérêt pour les problèmes de synchronisation répartie

  4. Distribution - Répartition • Unités d’exécution phys. distinctes … • parallèlisme de fait (vs d’expression) • et possiblement éloignées • pas d’horloge globale • « le monde réel est asynchrone » • pas de communication certaine et instantanée • besoin de protocoles

  5. Prog. réactive/synchrone et répartition • Langages synchrones / réactifs • à la base, compilés en code séquentiel • Prendre en compte une parallèlisation de fait • spécifier une application distribuée • Tirer profit d’une parallèlisation possible • multi-processeurs

  6. Restons modestes… • Qqs mots sur les ORBS • Des instants distribués en prog. réactive • « machines synchronisées » • ORB pour objets réactifs • modèle d’objet réactif • domaine d’exécution synchrone/réactive • Qqs mots sur le passage à l’échelle • ou autre chose … si on a le temps…

  7. Petits rappels • RPC • ports, protocoles (bas-niveau, applicatifs), sockets • Programmation par objets • RM-ODP (iso – officiel !) • Corba (consortium – de fait !) • Java RMI (succès populaire !) • anecd. : DCOM (+)… ? • (Algorithmique répartie) • indép. des plateformes • utilisée dans les protocoles ou les services

  8. O2 m * O1 O1 Ref O3 o = <ref sur O1>; o.m (args); Objets dans contextes répartis • Objet, Interface, Référence • Export, Bind (implicite or explicite, 3rd party)

  9. ORBs - 1 • Transparences • accès • localisation • Contrôle • interfaces typées • services : nommage, persistence, migration, … O.m (...args...);

  10. ORBs – 2 • Qqs problèmes de base • « annonces » et « interrogations » • en Corba, mot-clé « oneway » • parallèlisme et concurrence ?… • exécution séquentielle • appel de procédure • pas de gestion d’activités : • création de threads • paramétrages de « timeout »

  11. Exportation / Liaison • Implicite / Explicite • Référence • construire : Contexte de nommage • NamingContext • référence = collections de noms • lier : Usine à liaisons • BindingFactory • utilise un des noms de la référence

  12. Liaison TCP Client Stub Session GIOP Session GIOP Skeleton Serveur TCP GIOP Binding Factory Liaison

  13. RMI (1) • Remote Method Invocation • Intégré à Java • pbs avec Microsoft • typage des données • (dé)sérialisation masque marshalling/unmarshalling • Transparence d’accès et de localisation • référence d’objet Java • méthodes d’une interface, étendant « Remote » • appel de méthode • RPC = on attend le retour…

  14. RMI (2) • La « transparence » est dans la sérialisation • un objet « Remote » n’est pas sérialisé • sa référence l’est… d’une façon particulière • la dé-sérialisation de la référence rend une référence de « Stub ». • les invocations du « Stub » masquent la communication d’une invocation via les protocoles (jiop, tcp) jusqu’au « Skeleton »

  15. RMI (3) • rmic, rmiregistry serveur client skel stub stub serv = … registry

  16. Jonathan • Un ORB pour les télécommunications • ouvert • adaptable, configurable • basé sur le modèle ODP • objet, interface, référence • implémenté en Java • 2 « personnalités » : David, Jeremie • www.objectweb.org

  17. Machines synchronisées

  18. But • Partager les mêmes instants d’exécution et des événements (pas forcément tous) Synchroniseur connecter déconnecter Machine réactive

  19. Interfaces - 1 • Machine (e.g. de Junior) • void add (Program p) • void generate (Identifier id, Object value) • boolean react () • instant « complet » • Machine synchronisée(/able) • void generate (Identifier id, Object value) • pour l’instant courant ou prochain • void closeInstant ()

  20. Interfaces - 2 • Synchronisateur • int connect (MachineSync m) • void disconnect (MachineSync m) • void broadcast (Identifier id, Object val); • void suspended (int id) • void completed (int id)

  21. Concurrence Machine Synchronisateur (dis)connect, broadcast, suspended, completed Démarrer instant local Clore instant local gérer un instant distribué generate, closeInstant

  22. Remarques • Comportement… réactif ! • Attente active • politique « naïve » • Pas de sécurité/sûreté wrt communication • ordre des msgs, échec de communication, machine qui ne répond plus,… • Algos en multicast/broadcast • sans synchronisateur • Paramétrage/politique d’exécution

  23. Rhum Un ORB réactif Laurent HazardFT R&D DTL/ASR 07/02/03

  24. Sommaire • Motivation • exemple et discussion • Présentation de Rhum • et quelques détails d’implémentation • Retour sur l’exemple • Conclusion

  25. Motivation • Programmation réactive/synchrone • systèmes réactifs, interactions, //, synchro. • Contexte de la programmation objet • Java, ORBs • interaction procédurale -> RPC • séquence d’actions • Carences, difficultés...

  26. Exemple • Un serveurpublic interface ServeurI { public int add (int a, int b); } • Un client... ServeurI serveur = <ref. sur un serveur>; ... res = serveur.add (x1, x2);

  27. Requêtes parallèles • Comment faire pour programmer : ... ServeurI serveur1 = <ref. sur un serveur>; ServeurI serveur2 = <ref. sur un serveur>; ... res = serveur1.add (x1, x2) ou serveur2.add (x1, x2)(le premier qui - y - arrive) ; • ... Parallèlisme

  28. Requête gardée • Comment faire pour programmer :... ServeurI serveur = <ref. sur un serveur>; ... res = serveur.add (x1, x2)en moins de 3 secondes sinon 0; • ...Concurrence

  29. Requêtes gardées en // • Comment faire pour programmer : ... ServeurI serveur1 = <ref. sur un serveur>; ServeurI serveur2 = <ref. sur un serveur>; ... res = serveur1.add (x1, x2) si après 3 secondes pas de résultat, lancer serveur2.add (x1, x2)si après 2 sec. supp. serveur1 n’a pas rendu de résultat prendre celui de serveur2 si présent, sinon 0;

  30. débloque (val) serveur1.add ... serveur2.add ... valide (val) bloque attend démarre res = débloque (val) démarre 3 sec. attend 2 sec. débloque débloque A coeur vaillant... • En Java, pour les activités // et concurrentes, => on a les Threads ! • Essayons :

  31. Discussion... • Faisable ? mouais... • pas simple • pas modulaire • pas « scalable » • Faisable ? pas sûr... • a-t-on vraiment «programmé» ce qu’on voulait? • sémantique d’approximation • modèle d’activité implicite et... inconnu...

  32. Discussion (2) • Programmation ? • on reste en séquence... seule « garantie » ! ...requeteServeur1.start (); requeteServeur2.start (); ... res = serveur.add (a, b); serveur.add (a, b, moi); ... timer.start (); requeteServeur.start ();

  33. Discussion (3) • Valeur de retour (RPC) ou pas ? • en partie, un problème (mais il y a aussi d’autres problèmes) • et c’est quand même pratique. • Si retour « asynchrone » => le client doit être aussi serveur…et alors là… : • threads de l ’ORB, sans contrôle de l’appli • protection des accès concurrents

  34. Discussion (4) • Manque un modèle explicite • d’activité • d’activationpour les clients et les serveurs • Manque une définition de contexte • pour y appliquer un modèle • commun avec les autres activités du système

  35. Rhum (1) • Modèle d’Objet Réactif... • Papier « Reactive Objects » • ROM/DROM • appel procédural vs. message (send and forget) • messages <=> appels de méthodes de l’interface • objets exécutent des instants • domaine d ’exécution • communication synchrone • au plus, 1 exécution de chaque méthode par instant

  36. Rhum (2) • ... appliqué à des objets Java ... • interface Java « normale » • méthodes obligatoirement  « void ... » - • OR.m (args); • ...dans une machine réactive « classique ». • des événements, des instants, ... • exécution de comportements (pas de threads).

  37. Rhum (3) • Domaine (machine réactive) • lieu d’exécution des comportements • lieu de diffusion des événements • une invocation ou un evt. de l’environnement => un événement - diffusé - • présence des événements : • intra-domaine : synchrone • inter-domaine (ou environnement) : asynchrone • possib. de groupage/synch. de plusieurs domaines

  38. Binding Domaine D1 0R2 0R1 ... o = <ref sur OR1> ... o.meth (x, y, this); ... Domaine D2 ... o = <ref sur OR1> ... o.meth (x, y); ... 0R3 01

  39. Rhum : personnalité Jonathan • Référence d’interface réactive • sur un objet réactif • invocation uniforme • fournie par l ’infrastructure • transparence d’accès, à la localisation. • Les domaines sont intégrés dans Jonathan • export : attacher un objet à un domaine • lier : fabriquer la chaine pour générer un événement pour l’objet dans son domaine

  40. En résumé… generate (evt) meth () … dans un contexte quelconque… : O1 … o = (ref sur O1) … o.meth (); ...

  41. « Serialization » Remote Stub Local Stub RO StubFact. Reference Reference JIOP React. Insta. (ep + id) Session Req. Session ROA Jonathan/Jeremie (mf, iiop, tcp/ip) En détail…

  42. Mise en oeuvre (2) • Spécification d’objet réactif • langage réactif (à la « script réactif ») • classe Java « passive » • Codage de la plate-forme • ORB Jonathan • StubFactory, ObjectAdaptor, binder JIOP • comportement en Junior, domaine = Jr.Machine • parsing de la spécif en JavaCC - JJTree

  43. Spécif. d’objet réactif (1) • Déclare/utilise une interface • Utilise une instance « passive » • Spécifie un comportement • exécute des instants (séquence, parallèle, etc.) • connaît des événements (attente, garde, etc.) • méthodes de l ’interface • « channel » • environnement

  44. Spécif. d’objet réactif (2) public class Client extends RBase implements ClientI { ServeurI serveur; int res; public void setServ (ServeurI serv) {serveur = serv;} public void request (int a, int b) { if (serveur != null) serveur.addFor (a, b, this); } public void print (String msg) {System.out.println (msg);} public void receive (int resul) {print (" Client recoit :"+ resul);} } public class Serveur implements ServeurI { public void addFor (int a, int b, ClientI r) { r.receive (a+b); } }

  45. Spécif. d’objet réactif (3a) • rclass RClient { • interface /* ClientI */ { • public void setServ (Serveur serv) • public void request (int a, int b); • public void receive (int resul); • } • uses Client; • environment { • ms; // signal de milliseconde • }

  46. Spécif. d’objet réactif (3b) • behavior { • control loop {setServ (setServ::serv);}; stop end by setServ; • || • loop • await request; • (( • {request (request::a, request::b);}; • do • await receive; • {receive (receive::resul);}; • until 1000 ms actual {print ("1 sec. et pas de réponse ! ")} end • ) || ( • stop; // pas de boucle instantanée • )) • end • } • }

  47. L’exemple revisité • Une solution à notre petit problème :...do {request (serveur1, a, b);}; await Receive;until 3000 ms actual {request (serveur2, a, b);} end;do await Receive; {res = Receive::val;}until 2000 ms actual {res = <dflt>;} end;...

  48. Remarques • Le code est simple, clair et précis... • Les instants doivent être de durée < 1 ms • Le serveur doit aussi être un objet réactif • si « addFor » dure, ce doit être sur plusieurs instants ou dans un autre domaine • Les arguments possibles sont : • d’un type de base (String, int, boolean, Object…) • des références d’objets réactifs

  49. Bilan • intégration d’un modèle d’activités… réussi (?) • 2 « langages » • traitement de données + comportement • repose sur un Orb « classique » pour les comms.: • configuration des protocoles • dépend du système sous-jacent • threads, sockets, etc... • gestion (complexe) de la concurrence • prototype utilisé au sein de FT R&D => retours

  50. Perspectives • Nouveau modèle • 2 sémantiques d’invocation possibles • 1 événement ou 1 nouveau comportement • spécification du « serveur » • possibilité de valeur de retour • notion de ‘rvoid’ • usage par le « client » • Meilleure intégration : desc. comp. + java • Indépendance wrt ORB

More Related