IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Penser en Java 2nde édition - Sommaire |  Préface |  Avant-propos | Chapitre : 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 |  Annexe : A B C D  | Tables des matières - Thinking in Java

  Chapitre 15 - Informatique distribuée

pages : 1 2 3 4 5 6 7 8 9 10 11 12 

Dès lors qu'un fournisseur de service possède un enregistreur de service, le produit final du processus de découverte, il est prêt à entreprendre une jonction pour intégrer la fédération des services qui sont enregistrés auprès du service de recherche. Pour réaliser une jonction, le fournisseur de service fait appel à la méthode register( )de l' "font-weight: medium">enregistreur de service, passant en argument un objet appelé élément de service (service item), un ensemble d'objets qui décrit le service. La méthode register( )envoie une copie de cet élément de service au service de recherche, où celui-ci sera stocké. Lorsque ceci est achevé, le fournisseur de service a fini le processus de jonction : son service est maintenant enregistré auprès du service de recherche.

L'élément de service contient plusieurs objets, parmi lesquels un objet appelé un objet service, que les clients utilisent pour interagir avec le service. L'élément de service peut aussi inclure une certain nombre d'attributs, qui peuvent être n'importe quel objet. Certains de ces attributs sont des icônes, des classes qui fournissent des interfaces graphiques pour le service et des objets apportant plus de détails sur le service.

Les objects service implémentent généralement une ou plusieurs interfaces à travers lesquelles les clients interagissent avec le service. Par exemple, le service de recherche est un service Jini, et son objet service est un service de registre. La méthode register( )appelée par les fournisseurs de service durant la jonction est déclarée dans l'interface ServiceRegistrar(un membre du package net.jini.core.lookup) que tous les services de registre implémentent. Les clients et les fournisseurs de registre discutent avec le service de recherche à travers l'objet de service de registre en invoquant les méthodes déclarées dans l'interface ServiceRegistrar. De la même manière, le disque dur fournit un objet service qui implémente l'une des interfaces connues de service de stockage. Les clients peuvent rechercher le disque dur et interagir avec celui-ci par cette interface de service de stockage.

Le processus de recherche

Une fois qu'un service a été enregistré par un service de recherche grâce au processus de jonction, ce service est utilisable par les clients qui le demandent au service de recherche. Pour construire un système distribué de services qui collaborent pour réaliser une tâche, un client doit localiser ses services et s'aider de chacun d'eux. Pour trouver un service, les clients formulent des requêtes auprès des services de recherche par l'intermédiaire d'un processus appelé recherche.

Pour réaliser une recherche, un client fait appel à la méthode lookup( ) d'un service de registre (comme un fournisseur de service, un client obtient un service de registre grâce au processus de découverte décrit précédemment). Le client passe en argument un modèle de service à lookup( ), un objet utilisé comme critère de recherche. Le modèle de service peut inclure une référence à un tableau d'objets Class. Ces objets Classindiquent au service de recherche le type Java (ou les types)) de l'objet service voulu par le client. Le modèle de service peut aussi inclure un service ID, qui identifie de manière unique le service, ainsi que des attributs, qui doivent correspondre exactement aux attributs fournis par le fournisseur de service dans l'élément de service. Le modèle de service peut aussi contenir des critères génériques pour n'importe quel attribut. Par exemple, un critère générique dans le champ service ID correspondra à n'importe quel service ID. La méthode lookup( ) envoie le modèle de service au service de recherche, qui exécute la requête et renvoie s'il y en a les objets services correspondants. Le client récupère une référence vers ces objets services comme résultat de la méthode lookup( ).

En général, un client recherche un service selon le type Java, souvent une interface. Par exemple, si un client avait besoin d'utiliser une imprimante, il pourrait créer un modèle de service qui comprend un objet Class d'une interface connue de services d'impression. Tous les services d'impression implémenteraient cette interface connue. Le service de recherche retournerait un ou plusieurs objets services qui implémentent cette interface. Les attributs peuvent être inclus dans le modèle de service pour réduire le nombre de correspondances de ce genre de recherche par type. Le client pourrait utiliser le service d'impression en invoquant sur l'objet service les méthodes définies dans l'interface.

Séparation de l'interface et de l'implémentation

L'architecture Jini met en place pour le réseau une programmation orientée-objet en permettant aux services du réseau de tirer parti de l'un des fondements des objets : la séparation de l'interface et l'implémentation. Par exemple, un objet service peut permettre aux clients d'accéder au service de différentes manières. L'objet peut réellement représenter le service entier, qui sera donc téléchargé par le client lors de la recherche et exécuté localement ensuite. Autrement, l'objet service peut n'être qu'un proxy vers un serveur distant. Lorsqu'un client invoque des méthodes de l'objet service, il envoie les requêtes au serveur à travers le réseau, qui fait réellement le travail. Une troisième option consiste à partager le travail entre l'objet service local et le serveur distant.

Une conséquence importante de l'architecture Jini est que le protocole réseau utilisé pour communiquer entre l'objet service proxy et le serveur distant n'a pas besoin d'être connu du client. Comme le montre la figure suivante, le protocole réseau est une partie de l'implémentation du service. Ce protocole est une question privée prise en compte par le développeur du service. Le client peut communiquer avec l'implémentation du service à travers un protocole privée car le service injecte un peu de son propre code (l'objet service) au sein de l'espace d'adressage du client. L'objet service ainsi injecté peut communiquer avec le service à travers RMI, CORBA, DCOM, un protocole fait maison construit sur des sockets et des flux ou n'importe quoi d'autre. Le client ne porte simplement aucune attention quant aux protocoles réseau, puisqu'il ne fait que communiquer avec l'interface publique que le service implémente. L'objet service prend en charge toutes les communications nécessaires sur le réseau.

height="38" border="0">

Le client communique avec le service à travers une interface publique

Différentes implémentations de la même interface d'un service peuvent utiliser des approches et des protocoles réseau totalement différents. Un service peut utiliser un matériel spécialisé pour répondre aux requêtes clientes, ou il peut tout réaliser de manière logicielle. En fait, le choix d'implémentation d'un même service peut évoluer dans le temps. Le client peut être sûr qu'il possède l'objet service qui comprend l'implémentation actuelle de ce service, puisque le client reçoit l'objet service (grâce au service de recherche) du fournisseur du service lui-même. Du point de vue du client, le service ressemble à une interface publique, sans qu'il ait à se soucier de l'implémentation du service.

Abstraction des systèmes distribués

Jini tente d'élever passer le niveau d'abstraction de la programmation de systèmes distribués, passant du niveau du protocole réseau à celui de l'interface objet. Dans l'optique d'une prolifération des systèmes embarqués connectés au réseau, beaucoup de pièces d'un système distribué pourront venir de fournisseurs différents. Jini évite aux fournisseurs de devoir se mettre d'accord sur les protocoles réseau qui permettent à leurs systèmes d'interagir. A la place, les fournisseurs doivent se mettre d'accord sur les interfaces Java à travers lesquelles leurs systèmes peuvent interagir. Les processus de découverte, de jonction et de recherche, fournis par l'infrastructure d'exécution de Jini, permettront aux systèmes de se localiser les uns les autres sur le réseau. Une fois qu'ils se sont localisés, les systèmes sont capables de communiquer entre eux à travers des interfaces Java.

Résumé

Avec Jini pour des réseaux de systèmes locaux, ce chapitre vous a présenté une partie (une partie seulement) des composants que Sun regroupe sous le terme de J2EE : the Java 2 Enterprise Edition. Le but de J2EE est de construire un ensemble d'outils qui permettent au développeur Java de construire des applications serveurs beaucoup plus rapidement et indépendamment de la plate-forme. Construire de telles applications n'est pas seulement difficile et coûteux en temps, mais il est particulièrement dur de les construire en faisant en sorte qu'elles puissent être facilement portées sur une autre plate-formes, et aussi que la logique métier soit isolée des détails relevant de l'implémentation. J2EE met à disposition une structure pour assister la création d'applications serveurs ; ces applications sont très demandées en ce moment, et cette demande semble grandir.

Exercices

On triouvera les solutions des exercices sélectionnés dans le document électronique The Thinking in Java Annotated Solution Guide, disponible pour une participation minime à www.BruceEckel.com.

  1. Compiler et lancer les programmes JabberServer et JabberClient de ce chapitre. Éditer ensuite les fichiers pour supprimer les « buffering » d'entrée et de sortie, compiler et relancer, observer le résultat.
  2. Créer un serveur qui demande un mot de passe avant d'ouvrir un fichier et de l'envoyer sur la connexion réseau. Créer un client qui se connecte à ce serveur, donne le mot de passe requis, puis capture et sauve le fichier. Tester la paire de programmes sur votre machine en utilisant localhost (l'adresse IP de boucle locale 127.0.0.1 obtenue en appelant InetAddress.getByName(null)).
  3. Modifier le serveur de l' Exercice 2 afin qu'il utilise le multithreading pour servir plusieurs clients.
  4. Modifier JabberClient.java afin qu'il n'y ait pas de vidage du tampon de sortie, observer le résultat.
  5. Modifier MultiJabberServer afin qu'il utilise la technique de « surveillance de thread » « thread pooling ». Au lieu que le thread se termine lorsqu'un client se déconnecte, il intègre de lui-même un « pool « de threads disponibles ». Lorsqu'un nouveau client demande à se connecter, le serveur cherche d'abord dans le pool un thread existant capable de traiter la demande, et s'il n'en trouve pas, en crée un. De cette manière le nombre de threads nécessaires va grossir naturellement jusqu'à la quantité maximale nécessaire. L'intérêt du « thread pooling » est d'éviter l'overhead engendré par la création et la destruction d'un nouveau thread pour chaque client.
  6. À partir de ShowHTML.java, créer une applet qui fournisse un accès protégé par mot de passe à un sous-ensemble particulier de votre site Web.
  7. Modifier CIDCreateTables.java afin qu'il lise les chaînes SQL depuis un fichier texte plutôt que depuis CIDSQL.
  8. Configurer votre système afin d'exécuter avec succès CIDCreateTables.java et LoadDB.java.
  9. Modifier ServletsRule.java en surchargeant la méthode destroy( ) afin qu'elle sauvegarde la valeur de i dans un fichier, et la méthode init( ) pour qu'elle restaure cette valeur. Montrer que cela fonctionne en rechargeant le conteneur de servlet. Si vous ne possédez pas de conteneur de servlet, il vous faudra télécharger, installer, et exécuter Tomcat depuis jakarta.apache.org afin de travailler avec les servlets.
  10. Créer une servlet qui ajoute un cookie à l'objet réponse, lequel sera stocké sur le site client. Ajouter à la servlet le code qui récupère et affiche le cookie. Si vous n'avez pas de conteneur de servlet, il vous faudra télécharger, installer, et exécuter Tomcat depuis jakarta.apache.org afin de travailler avec les servlets.
  11. Créer une servlet utilisant un objet Session stockant l'information de session de votre choix. Dans la même servlet, récupérer et afficher cette information de session. Si vous ne possédez pas de conteneur de servlet, il vous faudra télécharger, installer, et exécuter Tomcat depuis jakarta.apache.org afin de travailler avec les servlets.
  12. Créer une servlet qui change la valeur de « inactive interval » de l'objet session pour la valeur 5 secondes en appelant getMaxInactiveInterval( ). Tester pour voir si la session se termine naturellement après 5 secondes. Si vous n'avez pas de conteneur de servlet, il vous faudra télécharger, installer, et exécuter Tomcat depuis jakarta.apache.org afin de travailler avec les servlets.
  13. Créer une page JSP qui imprime une ligne de texte en utilisant le tag <H1>. Générer la couleur de ce texte aléatoirement, au moyen du code Java inclus dans la page JSP. Si vous ne possédez pas de conteneur JSP, il vous faudra télécharger, installer, et exécuter Tomcat depuis jakarta.apache.org afin de travailler avec JSP.
  14. Modifier la date d'expiration dans Cookies.jsp et observer l'effet avec deux navigateurs différents. Constater également les différences entre le fait de visiter à nouveau la même page, et celui de fermer puis réouvrir le navigateur. Si vous ne possédez pas de conteneur JSP, il vous faudra télécharger, installer, et exécuter Tomcat depuis jakarta.apache.org afin de travailler avec JSP.
  15. Créer une page JSP contenant un champ autorisant l'utilisateur à définir l'heure de fin de session ainsi qu'un second champ contenant les données stockées dans cette session. Le bouton de soumission rafraîchit la page, prend les valeurs courantes de l'heure de fin et les données de la session, et les garde en tant que valeurs par défaut des champs susmentionnés. Si vous ne possédez pas de conteneur JSP, il vous faudra télécharger, installer, et exécuter Tomcat depuis jakarta.apache.org afin de travailler avec JSP.
  16. (Encore plus difficile). Modifier le programme VLookup.java de telle manière qu'un clic sur le nom résultat copie automatiquement ce nom dans les presse-papier (ce qui vous permet de le coller facilement dans votre email). Vous aurez peut-être besoin de revenir en arrière sur le chapitre 13 pour vous remémorer l'utilisation du presse-papier dans les JFC.

[68]Ce qui représente un peu plus de 4 milliards de valeurs, ce qui sera vite épuisé. Le nouveau standard pour les adresses IP utilisera des nombres de 128 octets, qui devraient produire assez d'adresses IP pour le futur proche.

[69]Beaucoup de neurones sont morts après une atroce agonie pour découvrir cette information.

[70]Cette section a été réalisée par Robert Castaneda, avec l'aide de Dave Bartlett.

[71]Cette section a été réalisée par Bill Venners (www.artima.com).

[72]Cela signifie un nombre maximum légèrement supérieur à quatre milliards, ce qui s'avère rapidement insuffisant. Le nouveau standard des adresses IP utilisera un nombre représenté sur 128 bits, ce qui devrait fournir suffisamment d'adresses IP uniques pour le futur prévisible.

[73]Créé par Dave Bartlett.

[74]Dave Bartlett participa activement à ce développement, ainsi qu'à la section JSP.

[75]« A primary tenet of Extreme Programming (XP) ». Voir www.xprogramming.com.

Ce livre a été écrit par Bruce Eckel ( télécharger la version anglaise : Thinking in java )
Ce chapitre a été traduit par Jean-Pierre Vidal, Alban Peignier ( groupe de traduction )
télécharger la version francaise (PDF) | Commandez le livre en version anglaise (amazon) | télécharger la version anglaise
pages : 1 2 3 4 5 6 7 8 9 10 11 12 
Penser en Java 2nde édition - Sommaire |  Préface |  Avant-propos | Chapitre : 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 |  Annexe : A B C D  | Tables des matières - Thinking in Java