Upload
marie
View
35
Download
0
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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