TP3 - Partie 2 - Une bibliothèque - Mobilité des canaux - Vers l'approche réactive

La communication asynchrone (sans blocage côté client) se fait traditionnellement de deux manières :

• soit la requête renvoie immédiatement côté client une promesse (de type Future), qui sera réalisée lorsque la réponse arrivera du serveur,
• soit la requête ne renvoie rien mais à la place enregistre une fonction de rappel de type InvocationCallBack, qui sera appelée lorsque la réponse arrivera du serveur, dans une tâche dédiée.

Le temps total d'exécution d'une recherche (soit la complexité en temps) dépend des latences des canaux (délais entre les requêtes et les réponses), et aussi bien sûr des durées propres à chaque calcul local. Supposons qu'on ait \(n\) canaux. On note \((L_i)_i\) les latences relatives aux canaux indexés par \(i\) (des entiers naturels pour simplifier). Dans les évaluations ci-dessous des temps d'exécution, on néglige la durée de tout calcul local. On suppose que la recherche se termine par la réponse positive du canal \(k\).

Une méthode moderne d'implémentation est d'abstraire la solution chimique (formée de l'état et des messages reçus ou à envoyer) par un observable : un observable possède un état et peut émettre des événements, correspondant à des messages envoyés ou reçus ou à des changements d'états. Un observable est habituellement implémenté par un flot, une séquence de taille indéfinie (finie ou infinie), représentée

• soit par un stream de Java 8,
• soit par un observable de la bibliothèque ReactiveX, qui existe en plusieurs langages.

On remarque que les règles chimiques correspondent fréquemment à des opérations classiques sur les flots : application d'une fonction (map), filtrage, réduction, etc. On peut aussi étendre un flot par des fonctionnalités de souscription, qui permettent d'observer les événements engendrés par le flot. C'est le choix fait par la bibliothèque ReactiveX. Pratiquement, dans le domaine des services, c'est la bibliothèque ReactiveX qui est utilisée, puisqu'elle est parfaitement adaptée à ce contexte en permettant de programmer des applications fondées sur la communication asynchrone et la gestion d'événements.

Reprenons les règles chimiques en précisant les opérations à réaliser sur le flot.

L'idée est de transformer l'ensemble des règles par une seule règle, en opérant une transformation de l'état, ici formé de la liste des liens vers les archives.

// Transformation du flot ar formé des canaux pointant vers les archives
//   pour obtenir la réponse 
- recherche(l, rep) & Liens(ar) -> rep(Transfo(l, ar)) & Liens(ar)

Déterminons la transformation Transfo paramétrée par le livre l à rechercher, à partir des règles chimiques.

// 1. Réception d'une requête et initialisation des diffusions
- Liens(ar) & recherche(l, rep) -> Liens(ar) & Diffusion(ar, l, rep)

** Observable initial émettant des canaux vers des archives (liste de canaux)

// 2. Portail non vide
// 2.1 Diffusion des requêtes
- Diffusion(h::ar, l, rep) 
    -> h(l, ret[h]) & Attente(h, rep) & Diffusion(ar, l, rep)

** Opération map(h -> h(l, ret[h])) appliquant à chaque canal 
   émis h la fonction en argument, produisant un observable formé 
   d'observables h(l, ret[h]). 
   - Un message h(l, ret[h]) peut en effet être considéré comme un observable, 
     émettant un événement correspondant à la réponse 
     ret[h](x) envoyée par l'archive distante 
     suite à la requête h(l, ret[h]).

// 2.2 Réponses

** Opération flatmap(ret[h](url) -> url) appliquant successivement 
   à chaque message reçu la fonction en argument et produisant un observable
   émettant des url 
   - L'opération flatmap appliquée à un observable dont chaque élément 
     est un observable produit un observable contenant tous les évènements 
     observables ordonnés suivant le temps, auxquels la fonction passée en argument 
     est appliquée. 
     C'est l'analogue de l'opération flatmap transformant une liste de listes en une liste,
     puis appliquant la fonction.

// 2.2.1 Réponse positive  
  // Première réponse
- Attente(h, rep) & ret[h](url) & (Reponse(rep) inactive)-> rep(url) & Reponse(rep)
  // Réponses suivantes
- Attente(h, rep) & ret[h](url) & Reponse(rep) -> Reponse(rep)
// 2.2.2 Réponse négative 
- Attente(h, rep) & ret[h](KO) -> 
// 3. Portail vide 
// 3.1 Diffusion terminée sans succès
- Diffusion(vide, l, rep) & (Attente(_, rep) inactive) & (Reponse(rep) inactive) -> rep(KO)
// 3.1 Diffusion terminée avec succès
- Diffusion(vide, l, rep) & (Attente(_, rep) inactive) & Reponse(rep) ->

** Opération : filter(url -> url != KO)
   - Le filtre élimine les réponses négatives.
** Opération : firstOrDefault(KO)
   - Cette sélection correspond au traitement différent 
     entre la première réponse positive et les réponses suivantes, 
     et au traitement de l'échec de la recherche.

Finalement, on peut exprimer ainsi la transformation Transfo(l, ar), avec une notation pointée et en utilisant des opérations classiques sur les flots.

ar 
.map(h -> h(l, ret[h]))       
.flatmap(ret[h](url) -> url)  
.filter(url -> url != KO)
.firstOrDefault(KO)

Il serait utile de typer les expressions précédentes. La documentation de la bibliothèque ReactiveX n'utilise pas de types mais s'appuie sur des diagrammes représentant les flots. Ainsi les deux points de vue se complèteraient. Cependant, il faudrait recourir à des types enrichis pour exprimer des sessions ou des interactions. Pour les curieux, voir à ce sujet une étude de 2016, Behavioral Types in Programming Languages.

Créer un nouveau projet, de type Dynamic Web Projet.

• Ajouter les dépendances suivantes dans le fichier pom.xml. On importe les bibliothèques de Jersey à la fois côté serveur et client (du fait que le portail est aussi client des archives) et la bibliothèque ReactiveX.

    <dependencies>
        <dependency>
                <groupId>org.glassfish.jersey.containers</groupId>
                <artifactId>jersey-container-servlet</artifactId>
                <version>2.28</version>
        </dependency>
        <dependency>
                <groupId>org.glassfish.jersey.media</groupId>
                <artifactId>jersey-media-json-jackson</artifactId>
                <version>2.28</version>
        </dependency>
        <dependency>
                <groupId>org.glassfish.jersey.inject</groupId>
                <artifactId>jersey-hk2</artifactId>
                <version>2.28</version>
        </dependency>
        <dependency>
                <groupId>org.glassfish.jersey.containers</groupId>
                <artifactId>jersey-container-grizzly2-http</artifactId>
                <version>2.28</version>
        </dependency>
        <dependency>
                <groupId>org.glassfish.jersey.ext</groupId>
                <artifactId>jersey-proxy-client</artifactId>
                <version>2.28</version>
        </dependency>
        <dependency>
                <groupId>org.glassfish.jersey.core</groupId>
                <artifactId>jersey-client</artifactId>
                <version>2.28</version>
        </dependency>
        <dependency>
                <groupId>io.reactivex.rxjava2</groupId>
                <artifactId>rxjava</artifactId>
                <version>2.1.7</version>
        </dependency>
  </dependencies>
  

• Dans le fichier WebContent/WEB-INF/web.xml, ajouter après l'élément welcome-file-list la référence de la servlet à utiliser.

  <servlet>
    <servlet-name>Jersey</servlet-name>
    <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
  </servlet>
  
  <servlet-mapping>
     <servlet-name>Jersey</servlet-name>
     <url-pattern>/*</url-pattern>
  </servlet-mapping>
  

Importer l'archive à partir de la racine.

Les paquets suivants sont importés :

• modele : le modèle objet,
• infrastructure : du code lié à JAXB ou JAX-RS, principalement,
• configuration : l'ensemble des configurations, en particulier toutes les constantes utilisées pour configurer le service web (classe JAXRS),
• serveur : programme permettant de déployer dix bibliothèques archives, en utilisant le serveur Grizzly.

Reprendre les annotations des méthodes des interfaces Archive et Bibliotheque de la première partie du TP. Le nom des annotations associées aux filtres et aux intercepteurs a pu légèrement changer.

Annoter les nouvelles méthodes des interfaces AdminAlgo et Bibliotheque en suivant les indications suivantes.

Remarque : pour hériter d'annotations JAX-RS, il est nécessaire de respecter certaines règles, décrites dans la spécification de JAX-RS (voir ci-dessous un extrait). En pratique, nous définissons les annotations des méthodes dans les interfaces pour les hériter dans les classes, qui n'en comportent aucune au niveau des méthodes.

Extrait de la spécification de JAX-RS, version 2, section 3.6, Annotation Inheritance

JAX-RS annotations may be used on the methods and method parameters of a super-class or an implemented interface. Such annotations are inherited by a corresponding sub-class or implementation class method provided that the method and its parameters do not have any JAX-RS annotations of their own. Annotations on a super-class take precedence over those on an implemented interface. The precedence over conflicting annotations defined in multiple implemented interfaces is implementation specific. Note that inheritance of class or interface annotations is not supported.

Annoter la méthode changerAlgorithmeRecherche de l'interface AdminAlgo de manière à vérifier les propriétés suivantes. On utilisera les constantes de la classe configuration.JAXRS.

• La méthode est qualifiée par le type idoine de méthode HTTP.
• Le chemin relatif d'accès est admin/recherche.
• Les données sont produites ou consommées au format application/xml.

Annoter la méthode chercherAsynchrone de l'interface Bibliotheque de manière à vérifier les propriétés suivantes.

• La méthode est annotée comme la méthode chercher.
• Le chemin relatif d'accès est async.
• Le paramètre supplémentaire de type AsyncResponse, dont la valeur sera fournie par l'implémentation de JAX-RS lors de chaque invocation de la méthode, représente la réponse. Il doit être annoté par @Suspended, du paquet javax.ws.rs.container.

Cette dernière méthode correspond à une communication asynchrone. Pour définir une méthode utilisant une communication asynchrone, on procède donc ainsi :

• mêmes annotations qu'une méthode utilisant la communication synchrone,
• ajout d'un paramètre supplémentaire de type AsyncResponse,
• annotation par @Suspended,
• pas de type de retour (void) ou type de retour fictif, ne servant que côté client.

Avec une telle méthode, côté client, l'appel distant n'est pas bloquant mais renvoie une promesse, soit une valeur de type Future<X>, si la réponse est initialisée côté serveur avec une valeur de type X. La promesse contient le canal de retour sur lequel la réponse arrivera. Le serveur reçoit la requête et la traite. Il envoie la réponse au client via le canal de retour. Pendant la durée du traitement, le client peut tester si la promesse est réalisée ou non. Elle l'est lorsque la réponse du serveur parvient au client. Nous avons fait le choix de typer la méthode de manière à ce qu'elle renvoie une valeur de type Future<Optional<HyperLien<Livre>>>, comme du côté client. De fait, ce sera la valeur null, puisque la réponse est transmise par l'argument de type AsyncResponse inséré automatiquement. C'est simplement une indication de typage. La solution retenue par la norme JAX-RS, celle d'un paramètre supplémentaire typé simplement, n'est pas idéale de ce point de vue. Etudier l'implémentation de la recherche asynchrone dans la classe ImplementationAppelsAsynchrones : elle concerne la recherche d'un livre dans une bibliothèque.

Annoter la classe d'implémentation ImplemNomAlgorithme et l'interface NomAlgorithme de manière à ce qu'un objet de type ImplemNomAlgorithme soit transformé en un document XML de la forme suivante.

<algo nom="..."/>

(algo est une balise munie d'un attribut nom.)

Trois filtres, AdapterServeurReponsesGETNullEn404, AdapterServeurReponsesPOSTEnCreated et AdapterServeurReponsesPUTOptionEn404OuValeur (du paquet infrastructure.jaxrs) sont fournis. Analyser la transformation des messages que ces classes réalisent.

Vérifier que les méthodes des interfaces Bibliotheque et Archive sont annotées pour utiliser ces filtres. Vérifier aussi que ces filtres sont enregistrés dans les classes de configuration des bibliothèques-archives et des portails (ServiceBibliotheque et ServicePortail respectivement, dans le paquet configuration).

Lorsque le portail interroge une archive pour chercher un livre, il peut recevoir une réponse de statut 404, ce qui signifie que la recherche a été infructueuse ; de même, il répond par une réponse 404 lorsqu'une recherche demandée par un client s'avère infructueuse, après interrogation de toutes les archives. Dans le code Java, cette possibilité se traduit par le type de retour Optional<HyperLien<Livre>> pour la méthode chercher. Il est nécessaire de traduire les options par des filtres et des intercepteurs lorsque le portail joue le rôle de serveur lors de l'envoi des réponses aux clients et lorsqu'il joue le rôle de client des archives.

Rappel : il est inutile de définir une annotation côté client pour un filtre (ou un intercepteur). En effet, pour les filtres côté client, la norme JAX-RS ne propose pas de mécanismes utilisant une annotation des méthodes. On doit configurer les cibles de type WebTarget par les filtres utilisés.

Rôle de serveur pour le portail

• Tous les filtres sont fournis.

Rôle de client pour le portail

• Un premier filtre-intercepteur est fourni : la classe AdpaterClientReponsesPUT404EnOption permet de transformer une réponse de statut 404 à une requête PUT en une option vide si le type attendu est Optional. Etudier son code, et en particulier le rôle des propriétés qui permettent de relier les filtres et l'intercepteur. Il reste à définir un intercepteur transformant une valeur en une option contenant cette valeur, lorsque le type attendu est Optional<?>.
• Définir un intercepteur AdapterClientReponsesPUTEnOption de type ReaderInterceptor, avec la priorité Priorities.HEADER_DECORATOR + 2, ce qui implique que cet intercepteur intervient après le précédent.
  • Dans la méthode aroundReadFrom, si le type de la réponse vaut Optional.class, alors convertir le type générique de la réponse en un ParameterizedType, puis récupérer son seul type argument (qui dans notre cas, sera HyperLien<Livre>) ; modifier le type de la réponse en utilisant la fonction Types.convertirTypeEnClasse du paquet infrastructure.langage de manière à spécifier que le contenu est de type HyperLien<Livre> ; enfin, renvoyer Optional.of(reponse.proceed()). Sinon, renvoyer reponse.proceed(), autrement dit la traduction du document en objet (via la fonction unmarshalling).
• Pour pouvoir utiliser cet intercepteur lorsque le portail joue le rôle de client (ou d'orchestrateur), enregistrer la classe AdpaterClientReponsesPUTEnOption dans la configuration définie dans configuration.Orchestrateur.clientJAXRS.

Définir la classe modele.ImplemPortail en suivant les instructions suivantes.

• C'est un singleton.
• Cette ressource est accessible par le chemin relatif portail (constante définie dans la classe JAXRS).
• Elle implémente Portail.
• Son état est formé
  • d'une table de type ConcurrentMap<NomAlgorithme, AlgorithmeRecherche>,
  • d'un client de type javax.ws.rs.client.Client,
  • d'un algorithme de recherche,
  • d'une liste d'hyperliens vers des bibliothèques archives.
• Son constructeur initialise ses différents champs ainsi :
  • une table de hachage, initialement vide,
  • un client de valeur Orchestrateur.clientJAXRS(),
  • un algorithme de recherche valant null provisoirement,
  • une liste d'hyperliens valant configuration.Initialisation.bibliotheques().
• La méthode chercher redirige l'appel vers la méthode chercher de l'algorithme de recherche.
• La méthode chercherAsynchrone s'implémente en appelant ImplementationAppelsAsynchrones.rechercheAsynchroneBibliotheque. Etudier (si ce n'est déjà fait) cette dernière fonction, qui peut servir de modèle pour implémenter des versions asynchrones de méthodes. Après avoir appelé la méthode chercher, elle transmet le résultat à l'objet gérant la réponse asynchrone.
• La méthode repertorier réalise la concaténation des catalogues des archives pointées par les hyperliens de la liste. Pour récupérer un proxy, on utilisera la méthode LienVersRessource.proxy (du paquet infrastructure.jaxrs). On pourra procéder ainsi :
  • créer un flot parallèle (de type java.util.stream.Stream) à partir de la liste des hyperliens vers des bibliothèques archives,
  • appliquer à chaque hyperlien la fonction calculant le catalogue de l'archive pointée par l'hyperlien, converti en liste puis flot, puis transformer ce flot de flots en un flot d'hyperliens vers des livres,
  • convertir ce flot en HyperLiens<Livre> et renvoyer le résultat.
• La méthode changerAlgorithmeRecherche(nom) procède ainsi : si la table associe à nom un algorithme de recherche, alors celui-ci devient le nouvel algorithme de recherche, sinon l'algorithme courant est conservé.

Enregistrer la classe ImplemPortail dans le constructeur de configuration.ServicePortail.

Enfin, à chaque fois qu'un nouvel algorithme de recherche est créé, il faudra l'ajouter à la table et au moins une fois initialiser l'algorithme de recherche dans le constructeur.

Exemple

// Initialisation requise au moins une fois
this.algoRecherche = new RechercheY("nom de l'algo Y");
...
// ajout dans la table, algo et nom étant des variables locales
algo = new RechercheZ("nom de l'algo Z");
nom = algo.nom();
tableAlgos.put(nom, algo);

On suit le schéma récapitulatif, en commençant par les classes abstraites puis par les huit classes concrètes. Toutes ces classes implémentent l'interface AlgorithmeRecherche. Pour suivre les exécutions concurrentes (par exemple, par des affichages dans la console), il est nécessaire de déterminer la tâche ("thread") en cours d'exécution : à cet effet, on pourra utiliser la fonction Outils.afficherInfoTache.

Pour la bibliothèque Rx (version 2), il est recommandé de consulter sa documentation, plutôt détaillée.

Dans le fichier web.xml, à l'intérieur de l'élément servlet, référencer la définition du service dans la classe configuration.ServicePortail. Bien noter aussi l'usage de la balise async-supported permettant la communication asynchrone.

<init-param>
  <param-name>javax.ws.rs.Application</param-name>
  <param-value>configuration.ServicePortail</param-value>
</init-param>
<load-on-startup>1 </load-on-startup>
<async-supported>true</async-supported>

Etudier le code de la classe ServicePortail. Cette configuration est propre à Jersey.

Déployer sur le serveur Tomcat le portail.

Lancer l'application LancementDixArchives. Elle déploie dix bibliothèques archives comptant chacune dix livres, de titre ServicesX.Y (où X et Y varient entre \(0\) et \(9\)), en utilisant le serveur Grizzly. Etudier le code de la classe ServiceBibliotheque utilisée pour la configuration des bibliothèques-archives.

Tester votre application avec votre navigateur.

Administration

• Requête : PUT
  • http://localhost:8080/Projet/portail/admin/recherche
  • Content-Type : application/xml

• Corps :

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?><algo nom="recherche async multi"/>
  

Recherche

• Requête : PUT
  • http://localhost:8080/Projet/portail/async ou http://localhost:8080/Projet/portail/
  • Accept et Content-Type : application/xml

  • Corps :

    <livre>
      <titre>Services5.6</titre>
    </livre>