Il faut ˆetre conscient qu’il s’ agit en quelque sorte d’une entorse faite au principe de portabilit´e mais la volont´e de rester compatible avec les programmes existant auparavant explique ce qui a motiv´e les concepteurs de Java `a d´evelopper cette interface native connue sous le nom de JNI (Java Native Interface).
Exploitation du code natif
Le code natif a principalement deux utilit´es : l’exploitation des ressources locales de la machine au moyen d’un code plus rapide, plus puissant et le d´esir de pouvoir mener des actions sur des ´el´ements du syst`eme qui ne sont pas repris dans la plateforme Java. A titre d’exemple, il pourrait s’ agir dans le premier cas de routines ultra-rapides de traitement digital du signal et pour le second de l’´ecriture dans les registres des cartes mat´erielles pr´esentes sur l’ordinateur.
Comme nous le verrons plus tard, cette derni`ere technique a ´et´e mise en oeuvre dans le pr´esent travail afin de permettre la prise de contrˆole du bus GPIB par un programme Java au moyen des biblioth`eques standard fournies par le constructeur de la carte. Notons que l’utilisation du langage C ou C++ standard jumel´e avec un code soign´e du point de vue de la portabilit´e, permet n´eanmoins de d´eployer assez facilement de code natif venant de pair avec une application Java. De plus, dans le cas pr´esent de l’instrumentation, des biblioth`eques fortement standardis´ees existent pour un grand nombre de plateformes natives utilisant le langage C. Ce dernier point, plus propre `a la r´ealisation pratique du syst`eme d’instrumentation sera trait´e dans la seconde partie de ce travail.
Les extensions de la plateforme Java
Une autre particularit´e de la plateforme Java est l’existence d’un grand nombre d’exten-sions, permettant par exemple l’utilisation des ports de communication s´erie ou parall`ele, le d´eploiement sur des stations mobiles l´eg`eres (PDA ou GSM), ou l’implantation de Java dans des syst`emes embarqu´es peu coˆuteux et pr´esentant des ressources m´emoire et calcul limit´ees. Ce large ´eventail d’ajouts `a la plateforme commune permet de consid´erer que l’utilisation de Java est un choix excellent et durable dans le temps, tant du point de vue de l’exploitation de l’´electronique embarqu´ee, de plus en plus pr´esente autour de nous, que du point de vue du programmeur d’applications complexes orient´ees utilisateur.
3.3 RMI
Nous avons expos´e dans le chapitre 2 le syst`eme d’objets distribu´e CORBA. Les concepts introduits par l’OMG dans le cadre de la mise en oeuvre de CORBA d´ecoulant de prin-cipes g´en´eraux relatifs `a la mise en oeuvre d’objets distribu´es, ceux-ci sont ´egalement le fondement de la Remote Methode Invocation (RMI) de Java [3]. Nous pr´esenterons dans un premier temps le mod`ele RMI, puis nous exposerons une technique de partage de classes entre le client et le serveur connue sous le nom de chargement dynamique du code mobile.
3.3.1 Le mod` ele propos´ e par Java : RMI
Comme nous l’avons ´evoqu´e, la Remote Method Invocation (RMI) de Java s’ apparente au sch´ema classique de distribution d’objets sur un bus r´eseau, `a cette exception pr`es que le but recherch´e n’ est pas ici d’interfacer tous les langages possibles mais bien de conce-voir des applications distribu´ees issues d’un mˆeme langage : Java. Ces applications seront donc amene´es `a r´esider sur des machines virtuelles [14] diff´erentes et non sur des plate-formes diff´erentes. Cette diff´erence apparaˆıtra fondamentale dans le paragraphe suivant.
La figure 3.3 pr´esente les ´el´ements d’une application ´ecrite au moyen de RMI.
Fig. 3.3 – Protocoles mis en oeuvre par RMI
Dans un premier temps, Le serveur appelle leregistry afin d’associer un nom symbolique avec l’objet qu’il met `a disposition sur le bus. Le client peut alors entamer un processus de recherche et interroger le registry sur la pr´esence ou non d’un nom de service disponible.
En cas de succ`es, il obtient alors une r´ef´erence sur l’objet correspondant et est `a mˆeme d’invoquer sur ce dernier une m´ethode particuli`ere.
L’ensemble des m´ethodes disponibles aupr`es du serveur est d´ecrite au moyen d’une interface connue du client et du serveur. Cette approche est semblable `a celle propose´e par CORBA au travers de l’IDL. Rappelons `a cet effet qu’une interface est un formalisme
´enon¸cant le comportement d’une objet, mais ne r´ealisant pas l’impl´ementation de la classe.
Il s’agit donc d’un ”contrat” que s’engage `a remplir la classe impl´ementant l’interface, dont la r´ealisation finale est discr´etionnaire.
Comme nous le verrons dans la section suivante, des serveurs Web sont ´egalement utilis´es par RMI afin de permettre le transfert de bytecode entre le client et le serveur.
Insistons bien ici sur le fait qu’il ne s’agit pas de la marshallisation proprement dite d’objets, tels que les param`etres des m´ethodes activ´ees, mais bien de transf´erer, le besoin ´ech´eant, des classes depuis un intervenant jusqu’`a l’autre. Ce m´ecanisme n’a pas d’´equivalent en CORBA et est appel´e transfert dynamique de code mobile.
3.3. RMI
3.3.2 Le transfert dynamique de code mobile
Le transfert dynamique de code mobile permet de transf´erer du bytecode, ou plus sim-plement du code Java, d’une instance d’une classe qui n’est pas d´efinie sur la machine virtuelle recevant ce code depuis la machine virtuelle qui fait r´ef´erence `a ce code. Ainsi, les interfaces, les comportements accessibles uniquement sur une plateforme sont rendus accessibles sur une autre plateforme, ´eventuellement distante.
L’exploitation de cette technique permet `a RMI la conservation d’un vrai polymor-phisme tout au long du dialogue client-serveur, ce qui n’´etait pas possible en CORBA.
On entend par vrai polymorphisme le fait que la manipulation de la classe `a travers des processus de g´en´eralisation et/ou de sp´ecialisation ne d´egrade pas son comportement. Une classe ayant subit une g´en´eralisation en un membre de sa classe m`ere peut toujours ˆetre vu comme un ´el´ement de sa classe d’origine. Ceci n’est pas possible dans d’autres langages, tels que C++.
Reprenons ici l’exemple du Chat envoy´e `a travers un ORB qui est `a mˆeme de mar-shalliser un Animal. Cette transaction est expos´ee sur la figure 3.4. Si nous effectuons cette op´eration au moyen de RMI, le comportement Chat n’´etant pas connu de la machine distante, celle-ci entamera un transfert de code mobile avec la machine d’origine de la transaction afin d’obtenir le bytecode lui permettant d’avoir une connaissance de la classe Chat. Ce transfert est totalement transparent et automatique, l’utilisateur n’ayant aucune intervention `a fournir lors de l’ex´ecution ou de la programmation.
Notons enfin que l’utilisation de la technique de transfert dynamique de code mobile permet la mˆeme flexibilit´e que l’interface d’invocation dynamique de CORBA, en ce sens que si un client d´esire invoquer des m´ethodes sur un serveur dont il n’a pas connaissance a priori, il pourra obtenir la r´ef´erence du stub du serveur aupr`es du rmiregistry et entamer un t´el´echargement du code de ce dernier (fig. 3.5). Ayant acquis le stub, il pourra alors l’utiliser tout le temps de la transaction avec le serveur. Insistons sur le fait, crucial pour la compr´ehension des m´ecanismes implant´es par Jini, que contrairement `a CORBA, il ne s’agit pas ici de construire dynamiquement le stub du cˆot´e client mais bien d’en d´eplacer une copie depuis le serveur Web de l’objet distant.
Client Server Animal
RMIbus Cat
A cat instance
Marshalling Marshalling
Client Server
Animal
RMIbus Cat
A cat instance
Marshalling Marshalling
Client Server
Animal
RMIbus Cat
A cat instance
Marshalling Marshalling
Client Server
Animal
RMIbus Cat
A cat instance
Marshalling Marshalling
Client Server
Animal
RMIbus Cat
A cat instance
Marshalling Marshalling
Client Server
Animal
RMIbus Cat
A cat instance
Marshalling Marshalling
Client Server
Animal
RMIbus Cat
A cat instance
Marshalling Marshalling
Client Server
Animal
RMIbus
Cat Cat
A cat instance
A cat instance
Marshalling Marshalling
Client Animal
Cat A cat instance
Dynamic Stub Invocation
Animal
Cat A cat instance Animal
Cat A cat instance
Server Animal
ORB
Cat Animal
A cat instance
An Animal Instance
Dynamic Skeleton Invocation
ORB IIOP
HTTP upload of Cat’ s class bytecode
Fig. 3.4 – RMI (au-dessus) conserve le comportement d’une classe marshallis´ee contraire-ment CORBA (dessous). Ceci est rendu possible par le transfert du bytecode de la classe Chat de la machine client `a la machine serveur.
Client
Web server
Server Object
RmiRegistry
Web server Client Virtual Machine Server Virtual Machine
Client
Web server
Server Object
RmiRegistry
Web server Client Virtual Machine Server Virtual Machine
Server’ s Stub
Server’ s Stub
Aks for location of the Stub
Fig. 3.5 – Une copie du stub du serveur est transf´er´ee dans un premier temps aupr`es du rmiregistry. Le client utilise alors la r´ef´erence du stub afin d’en obtenir une instance locale par t´el´echargement du bytecode.