Conception et réalisation d'un syst`eme d'instrumentation ... - CoDE

More documents

Recommendations

Info

4.3. LE MODÈLE D’INTERACTION DYNAMIQUE réalisent les interfaces requises par celui-ci. La terminologie Jini fait état de trois transitions différentes. On parlera de transition 1. no match to match lorsqu’un nouveau service, non connu jusqu’à présent, s’enregistre auprès du lookup et correspond aux demandes du client. 2. match to no match si un service connu venait à disparaître, soit intentionnellement, soit par expiration du délai de bail de son proxy. 3. match to match portant sur un service déjà existant mais dont le proxy s’est modifié. Il s’agit par exemple de la mise à disposition d’une nouvelle classe proxy ou de la modification des attributs secondaires – les Entry – associés à ce proxy. La figure 4.4 montre que l’apparition d’un nouveau fournisseur de service entraine la réexécution du schéma que nous avons détaillé plus haut. Consumer L Provider Lookup Service Consumer announcement lookup discovery 3 S event usage usage 4 2 register register Lookup Service Provider Lookup Service Consumer discovery 1 announcement Fig. 4.4 – A l’apparition d’un nouveau service, le lookup génère un évènement auprès du client afin que celui-ci puisse bénéficier du nouveau proxy. 43
4.3. LE MODÈLE D’INTERACTION DYNAMIQUE 4.3.2 Le concept de Leasing Le transfert du proxy effectué, les compétences des services présents sur le bus peuvent être librement exploitées par les clients possédant les proxy qu’ils requiéraient. Mais cette distribution de code à travers le réseau soulève la problématique de la robustesse de l’architecture ainsi mise en place. La plupart des approches relatives à la conception et à la mise en oeuvre de systèmes distribués, faisant intervenir des objets ou non, postulent que le réseau est transparent. Transparent signifie ici qu’il n’est pas un paramètre critique de l’interaction entre client et serveur : la latence est faible ou inexistante, les machines sont stables et sont peu susceptibles de présenter une panne ou de ”disparaître” soudainement du réseau, les méthodes invoquées sur les objets distants n’échouent pas. Force est de constater qu’à long terme ces préceptes se révèlent être faux. L’interaction dynamique entre noeuds d’une communauté d’appareils hétérogènes implique que ceux ci peuvent apparaître ou disparaître à tout moment. l’activation d’une méthode sur un objet distant peut potentiellement échouer ; il suffit de penser par exemple à l’appel d’une méthode de mesure du potentiel dans un calibre largement supérieur à celui que pourrait supporter le voltmètre. Jini intègre cette vision en offrant deux mécanismes afin d’assurer la robustesse des interactions. Le premier mécanisme permet de traiter avec la partie relative à l’activation des méthodes sur un objet serveur. En cas d’échec de l’appel à la méthode ou en cas de problème lors de la réalisation de la méthode, une exception est jetée. Ainsi le client sera non seulement averti de l’insuccès de l’invocation distante, mais il sera de plus obligé de traiter l’exception éventuelle. En effet, les mécanismes syntaxiques du langage Java imposent, lorsqu’une méthode est déclarée comme pouvant potentiellement jeter une exception, de prévoir une portion de code qui sera inconditionnellement exécutée. C’est donc la responsabilité du développeur d’agir en conséquence. Le second mécanisme,plus subtil, assure une connaissance continue des objets présents dans la communauté Jini. Fondamentalement, un Service peut quitter le réseau local de deux manières : soit proprement, en faisant part de son départ, soit suite à un impondérable (crash matériel, déconnexion du réseau). Un Service quittant le réseau proprement le fera en annonçant son intention au Lookup en charge de son ou ses Proxy (Fig. 4.5). Le Lookup décidera alors d’invalider les Proxy mis en dépôt par le Service et avertira, au moyen d’évènement distribués, les Clients faisant usage de ces Proxy qu’il ne convient plus de les utiliser plus longtemps (Fig 4.6). Les Clients pourront alors envisager de détruire ou non les Proxy invalides. Le deuxième mécanisme est utilisé afin de prévenir qu’un Service disparaisse du réseau local, sans avertir de son départ, mettant ainsi l’équilibre de l’architecture en péril. Ce mécanisme est connu sous le nom de Leasing. Lors de la mise en dépôt du Proxy, le Service et le Lookup conviennent du temps pendant lequel le Proxy sera mis à disposition ainsi que d’une fréquence à laquelle ils prendront régulièrement contact. La transaction prend la 44
Page 1 and 2: UNIVERSITE LIBRE DE BRUXELLES Facul
Page 3 and 4: Table des matières I Étude théor
Page 5 and 6: Introduction Contexte de travail Le
Page 7 and 8: Première partie Étude théorique
Page 9 and 10: 1.1. INTRODUCTION ET MOTIVATION l
Page 11 and 12: 1.2. LE CONTRÔLE LOCAL DES APPAREI
Page 13 and 14: 1.2. LE CONTRÔLE LOCAL DES APPAREI
Page 15 and 16: 1.3. INSTRUMENTATION DISTRIBU ÉE 1
Page 17 and 18: 1.3. INSTRUMENTATION DISTRIBU ÉE d
Page 19 and 20: 1.3. INSTRUMENTATION DISTRIBU ÉE s
Page 21 and 22: Chapitre 2 CORBA Sommaire 2.1 Intro
Page 23 and 24: 2.2. ARCHITECTURE structure forteme
Page 25 and 26: 2.2. ARCHITECTURE système local. S
Page 27 and 28: 2.2. ARCHITECTURE La marshallisatio
Page 29 and 30: 2.3. CONCLUSION l’Event Service N
Page 31 and 32: 3.2. LA TECHNOLOGIE JAVA 3.2 La tec
Page 33 and 34: 3.3. RMI Il faut être conscient qu
Page 35 and 36: 3.3. RMI 3.3.2 Le transfert dynamiq
Page 37 and 38: 3.4. JAVA HARDWARE : LE PICOJAVA 3.
Page 39 and 40: Chapitre 4 Architecture Jini Sommai
Page 41 and 42: 4.2. ARCHITECTURE ET PRINCIPE Consu
Page 43: 4.3. LE MODÈLE D’INTERACTION DYN
Page 47 and 48: 4.3. LE MODÈLE D’INTERACTION DYN
Page 49 and 50: Deuxième partie Réalisation d’u
Page 51 and 52: 5.1. CORBA 5.1 CORBA 5.1.1 Introduc
Page 53 and 54: 5.2. UPNP 5.1.4 Conclusion CORBA et
Page 55 and 56: 5.4. CONCLUSION 5.4 Conclusion Pour
Page 57 and 58: 6.2. L’INTERFACE STANDARD IEEE 48
Page 63 and 64: 7.2. INTERFAÇAGE DES INSTRUMENTS D
Page 69 and 70: 7.4. LES APPORTS PROPRES À JINI si
Page 71 and 72: 7.4. LES APPORTS PROPRES À JINI Fi
Page 73 and 74: 8.2. IMPLANTATION D’UNE INTERFACE
Page 75 and 76: 8.2. IMPLANTATION D’UNE INTERFACE
Page 77 and 78: 8.3. CONCLUSIONS Fig. 8.2 - Instanc
Page 79 and 80: 8.3. CONCLUSIONS Fig. 8.4 - Réalis
Page 81 and 82: Chapitre 9 Conclusion et perspectiv
Page 83 and 84: Bibliographie [1] Jini forum at art

Conception et réalisation d'un syst`eme d'instrumentation ... - CoDE

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?