r´ealisent les interfaces requises par celui-ci. La terminologie Jini fait ´etat de trois transitions diff´erentes. On parlera de transition
1. no match to match lorsqu’un nouveau service, non connu jusqu’`a pr´esent, s’enregistre aupr`es du lookup et correspond aux demandes du client.
2. match to no match si un service connu venait `a disparaˆıtre, soit intentionnellement, soit par expiration du d´elai de bail de son proxy.
3. match to match portant sur un service d´ej`a existant mais dont le proxy s’est modifi´e.
Il s’agit par exemple de la mise `a disposition d’une nouvelle classe proxy ou de la modification des attributs secondaires – les Entry – associ´es `a ce proxy.
La figure 4.4 montre que l’apparition d’un nouveau fournisseur de service entraine la r´eex´ecution du sch´ema que nous avons d´etaill´e plus haut.
Consumer L Provider
Lookup Service Provider
Lookup Service Consumer
Lookup Service Consumer
discovery
discovery announcement
announcement
register lookup
S
event usage
usage
register
1 2
3 4
Fig. 4.4 – A l’apparition d’un nouveau service, le lookup g´en`ere un ´ev`enement aupr`es du client afin que celui-ci puisse b´en´eficier du nouveau proxy.
4.3. LE MOD `ELE D’INTERACTION DYNAMIQUE
4.3.2 Le concept de Leasing
Le transfert du proxy effectu´e, les comp´etences des services pr´esents sur le bus peuvent ˆetre librement exploit´ees par les clients poss´edant les proxy qu’ils requi´eraient. Mais cette distribution de code `a travers le r´eseau soul`eve la probl´ematique de la robustesse de l’ar-chitecture ainsi mise en place. La plupart des approches relatives `a la conception et `a la mise en oeuvre de syst`emes distribu´es, faisant intervenir des objets ou non, postulent que le r´eseau est transparent.
Transparent signifie ici qu’il n’est pas un param`etre critique de l’interaction entre client et serveur : la latence est faible ou inexistante, les machines sont stables et sont peu suscep-tibles de pr´esenter une panne ou de ”disparaˆıtre” soudainement du r´eseau, les m´ethodes invoqu´ees sur les objets distants n’´echouent pas. Force est de constater qu’`a long terme ces pr´eceptes se r´ev`elent ˆetre faux. L’interaction dynamique entre noeuds d’une communaut´e d’appareils h´et´erog`enes implique que ceux ci peuvent apparaˆıtre ou disparaˆıtre `a tout mo-ment. l’activation d’une m´ethode sur un objet distant peut potentiellement ´echouer ; il suffit de penser par exemple `a l’appel d’une m´ethode de mesure du potentiel dans un ca-libre largement sup´erieur `a celui que pourrait supporter le voltm`etre. Jini int`egre cette vision en offrant deux m´ecanismes afin d’assurer la robustesse des interactions.
Le premier m´ecanisme permet de traiter avec la partie relative `a l’activation des m´ethodes sur un objet serveur. En cas d’´echec de l’appel `a la m´ethode ou en cas de probl`eme lors de la r´ealisation de la m´ethode, une exception est jet´ee. Ainsi le client sera non seulement averti de l’insucc`es de l’invocation distante, mais il sera de plus oblig´e de traiter l’excep-tion ´eventuelle. En effet, les m´ecanismes syntaxiques du langage Java imposent, lorsqu’une m´ethode est d´eclar´ee comme pouvant potentiellement jeter une exception, de pr´evoir une portion de code qui sera inconditionnellement ex´ecut´ee. C’est donc la responsabilit´e du d´eveloppeur d’agir en cons´equence.
Le second m´ecanisme,plus subtil, assure une connaissance continue des objets pr´esents dans la communaut´e Jini. Fondamentalement, un Service peut quitter le r´eseau local de deux mani`eres : soit proprement, en faisant part de son d´epart, soit suite `a un impond´erable (crash mat´eriel, d´econnexion du r´eseau). Un Service quittant le r´eseau proprement le fera en annon¸cant son intention au Lookup en charge de son ou ses Proxy (Fig. 4.5). Le Lookup d´ecidera alors d’invalider les Proxy mis en d´epˆot par le Service et avertira, au moyen d’´ev`enement distribu´es, 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´etruire ou non les Proxy invalides.
Le deuxi`eme m´ecanisme est utilis´e afin de pr´evenir qu’un Service disparaisse du r´eseau local, sans avertir de son d´epart, mettant ainsi l’´equilibre de l’architecture en p´eril. Ce m´ecanisme est connu sous le nom deLeasing. Lors de la mise en d´epˆot du Proxy, le Service et le Lookup conviennent du temps pendant lequel le Proxy sera mis `a disposition ainsi que d’une fr´equence `a laquelle ils prendront r´eguli`erement contact. La transaction prend la
forme d’un dialogue au cours duquel chacun des acteurs expose ses d´esid´eratas ; la d´ecision finale revenant au Lookup seul. Pour fixer les id´ees, le service de Lookup fourni par Sun autorise qu’un Proxy soit mis en d´epˆot pour un temps infini, pour autant que le Service puisse ˆetre recontact´e au plus tard toutes les cinq minutes.
Si, le d´elai pass´e, le Service ne peut ˆetre contact´e ou qu’il ne d´esire plus renouveller le bail de son Proxy, ce dernier sera d´etruit et les clients avertis de l’invalidit´e manifeste des Proxy li´es `a ces Services. (Figs. 4.7 et 4.8).
Enfin, un dernier m´ecanisme important permet aux clients de s’assurer que le Service offre le mˆeme comportement. Si le Service venait `a changer la configuration de son Proxy – en fournissant un nouveau au lookup par exemple – ou d’une de ses Entry, un ´ev`enement sp´ecifique est envoy´e par le Service au Lookup et celui-ci le propagera `a tous les clients utilisant le Proxy.
4.3. LE MOD `ELE D’INTERACTION DYNAMIQUE
Consumer Provider
Lookup Service Provider
Lookup Service Consumer
Lookup Service Consumer
discovery
discovery unregister
lookup
L
Fig. 4.5 – Le service annonce son intention de quitter
Consumer L Provider
Lookup Service Provider
Lookup Service Consumer
Lookup Service Consumer
discovery
discovery announcement
announcement lookup
S
event
register usage
Fig. 4.6 – L’annonce est r´epercut´ee aupr`es des clients consommateurs du service
Consumer
Lookup Service Provider
Lookup Service Consumer
discovery announcement
lookup
usage ???
Fig. 4.7 – Le service disparaˆıt de mani`ere impromptue mais son Proxy vit toujours sur la plateforme du Lookup
Consumer L
Lookup Service Provider
Lookup Service Consumer
discovery announcement
lookup
S
event
Fig.4.8 – Le lookup, ne pouvant renouveler le bail du proxy, l’invalide et avertit les clients
Deuxi` eme partie
R´ ealisation d’un syst` eme
d’instrumentation distribu´ ee
Positionnement de JINI par rapport aux solutions actuelles
Sommaire
5.1 CORBA . . . 50 5.1.1 Introduction . . . 50 5.1.2 Aspects communs . . . 50 5.1.3 El´ements de distinction . . . .´ 51 5.1.4 Conclusion . . . 52 5.2 UPNP . . . 52 5.2.1 Introduction . . . 52 5.2.2 Principes . . . 52 5.2.3 El´ements de distinction . . . .´ 53 5.3 IEEE 1451 . . . 53 5.4 Conclusion . . . 54
Les chapitres pr´ec´edents ont longuement expos´e la probl´ematique des syst`emes d’ins-trumentation actuels ainsi que les diff´erentes techniques utilisables actuellement pour la r´ealisation d’applications distribu´ees exploitant les possibilit´es des langages de haut niveau.
Dans ce chapitre, nous nous efforcerons de comparer la technologie Jini, pr´econis´ee comme solution, aux technologies existantes afin d’en faire ressortir les ´el´ements novateurs et d’af-firmer l’int´erˆet de Jini dans le cadre de la r´ealisation d’un syst`eme hybride instrument de mesure–PC.