Programmation ractive et distribution Laurent Hazard France Telecom
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 – Infrastructures d’exécution
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
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
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
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…
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
Objets dans contextes répartis • Objet, Interface, Référence • Export, Bind (implicite or explicite, 3 rd party) m* O 2 O 1 Ref o = <ref sur O 1>; o. m (args); O 3 O 1
ORBs - 1 • Transparences – accès – localisation O. m (. . . args. . . ); • Contrôle – interfaces typées – services : nommage, persistence, migration, …
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 »
Exportation / Liaison • Implicite / Explicite • Référence – construire : Contexte de nommage • Naming. Context • référence = collections de noms – lier : Usine à liaisons • Binding. Factory • utilise un des noms de la référence
Liaison Client Stub Session GIOP Liaison TCP GIOP Binding Factory Session Skeleton GIOP Serveur
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…
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 »
RMI (3) serveur client skel stub serv = … stub registry • rmic, rmiregistry
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
Machines synchronisées
But Synchroniseur Machine réactive connecter déconnecter • Partager les mêmes instants d’exécution et des événements (pas forcément tous)
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 close. Instant ()
Interfaces - 2 • Synchronisateur – int connect (Machine. Sync m) – void disconnect (Machine. Sync m) – void broadcast (Identifier id, Object val); – void suspended (int id) – void completed (int id)
Concurrence Machine (dis)connect, broadcast, suspended, completed Démarrer instant local Synchronisateur gérer un instant distribué Clore instant local generate, close. Instant
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
Rhum Un ORB réactif Laurent Hazard FT R&D DTL/ASR 07/02/03
Sommaire • Motivation • exemple et discussion • Présentation de Rhum • et quelques détails d’implémentation – Retour sur l’exemple • Conclusion
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. . .
Exemple • Un serveur public interface Serveur. I { public int add (int a, int b); } • Un client. . . Serveur. I serveur = <ref. sur un serveur>; . . . res = serveur. add (x 1, x 2);
Requêtes parallèles • Comment faire pour programmer : . . . Serveur. I serveur 1 = <ref. sur un serveur>; Serveur. I serveur 2 = <ref. sur un serveur>; . . . res = serveur 1. add (x 1, x 2) ou serveur 2. add (x 1, x 2) (le premier qui - y - arrive) ; • . . . Parallèlisme
Requête gardée • Comment faire pour programmer : . . . Serveur. I serveur = <ref. sur un serveur>; . . . res = serveur. add (x 1, x 2) en moins de 3 secondes sinon 0; • . . . Concurrence
Requêtes gardées en // • Comment faire pour programmer : . . . Serveur. I serveur 1 = <ref. sur un serveur>; Serveur. I serveur 2 = <ref. sur un serveur>; . . . res = serveur 1. add (x 1, x 2) si après 3 secondes pas de résultat, lancer serveur 2. add (x 1, x 2) si après 2 sec. supp. serveur 1 n’a pas rendu de résultat prendre celui de serveur 2 si présent, sinon 0;
A coeur vaillant. . . • En Java, pour les activités // et concurrentes, => on a les Threads ! • Essayons : débloque (val) serveur 1. add. . . serveur 2. add. . . bloque démarre attend valide (val) débloque (val) démarre 3 sec. débloque attend 2 sec. débloque res =
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. . .
Discussion (2) • Programmation ? – on reste en séquence. . . seule « garantie » !. . . requete. Serveur 1. start (); requete. Serveur 2. start (); . . . res = serveur. add (a, b); serveur. add (a, b, moi); . . . timer. start (); requete. Serveur. start ();
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
Discussion (4) • Manque un modèle explicite – d’activité – d’activation pour 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
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
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).
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
Binding Domaine D 1 0 R 2 0 R 1 . . . o = <ref sur OR 1>. . . o. meth (x, y, this); o = <ref sur OR 1>. . . o. meth (x, y); . . . 01 Domaine D 2 0 R 3
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
En résumé… generate (evt) meth () O 1 … dans un contexte quelconque… : … o = (ref sur O 1) … o. meth (); . . .
En détail… « Serialization » Remote Stub Local Stub RO Stub. Fact. Reference (ep + id) Reference JIOP Session React. Insta. Req. Session Jonathan/Jeremie (mf, iiop, tcp/ip) ROA
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 – Stub. Factory, Object. Adaptor, binder JIOP • comportement en Junior, domaine = Jr. Machine • parsing de la spécif en Java. CC - JJTree
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
Spécif. d’objet réactif (2) public class Client extends RBase implements Client. I { Serveur. I serveur; int res; public void set. Serv (Serveur. I serv) {serveur = serv; } public void request (int a, int b) { if (serveur != null) serveur. add. For (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 Serveur. I { public void add. For (int a, int b, Client. I r) { r. receive (a+b); } }
Spécif. d’objet réactif (3 a) rclass RClient { interface /* Client. I */ { public void set. Serv (Serveur serv) public void request (int a, int b); public void receive (int resul); } uses Client; environment { ms; // signal de milliseconde }
Spécif. d’objet réactif (3 b) behavior { control loop {set. Serv (set. Serv: : serv); }; stop end by set. Serv; || 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 } }
L’exemple revisité • Une solution à notre petit problème : . . . do {request (serveur 1, a, b); }; await Receive; until 3000 ms actual {request (serveur 2, a, b); } end; do await Receive; {res = Receive: : val; } until 2000 ms actual {res = <dflt>; } end; . . .
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 « add. For » 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
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
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
- Slides: 50