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, 3rd party)

O2

O3

O1O1

Ref

o = <ref sur O1>;o.m (args);

m *

ORBs - 1

• Transparences– accès– localisation

• Contrôle– interfaces typées– services : nommage, persistence, migration, …

O.m (...args...);

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

• NamingContext

• référence = collections de noms

– lier : Usine à liaisons• BindingFactory

• utilise un des noms de la référence

Liaison

Binding Factory

GIOP

TCP

Client StubSessionGIOP

SessionGIOP

Skeleton ServeurLiaison TCP

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)

• rmic, rmiregistry

serveurclientskel

registry

serv = …

stub

stub

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

• Partager les mêmes instants d’exécution et des événements (pas forcément tous)

Synchroniseur

Machineréactive

connecterdéconnecter

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 ()

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)

Concurrence

Démarrer instant local

Clore instant local

Machine Synchronisateur

gérer un instant distribué

generate, closeInstant

(dis)connect, broadcast,suspended, completed

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 serveurpublic interface ServeurI {

public int add (int a, int b);}

• Un client...ServeurI serveur = <ref. sur un serveur>;...res = serveur.add (x1, x2);

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

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

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ésultatprendre celui de serveur2 si

présent, sinon 0;

A coeur vaillant...

• En Java, pour les activités // et concurrentes, => on a les Threads !

• Essayons :

3 sec.

serveur1.add ... serveur2.add ...

débloque (val)

valide (val)

débloquedébloque

bloquedémarre

démarreattend

débloque (val)

attend

2 sec.

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 » !

...

requeteServeur1.start (); requeteServeur2.start ();

... res = serveur.add (a, b); serveur.add (a, b, moi); ... timer.start (); requeteServeur.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

BindingDomaine D1

Domaine D20R1

0R3

01

0R2

...o = <ref sur OR1>...o.meth (x, y, this);...

...o = <ref sur OR1>...o.meth (x, y);...

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é…

O1

meth ()

…o = (ref sur O1)…o.meth ();...

generate (evt)

… dans un contexte quelconque… :

En détail…

Remote Stub

Reference

Session Req. Session

Local Stub

React. Insta.

Reference

Jonathan/Jeremie(mf, iiop, tcp/ip)

ROA

StubFact. RO

JIOP

« Serialization »

(ep + id)

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

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 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);}

}

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}

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}

}

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;...

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

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