UP | HOME

Examen - Un automate doublement réparti

Table of Contents

1 Les architectures REST

Q ? Donner les cinq principes caractérisant les architectures REST.

Q ? Quelles sont les deux propriétés permettant de déterminer la méthode HTTP à utiliser pour une requête ?

Q ? Définir ces deux propriétés.

  • Une requête est dite … si …
  • Une requête est dite … si …

Q ? Classer chaque méthode HTTP suivant qu'elle vérifie ou non chacune des deux propriétés ci-dessus. Indiquer par oui/non si la propriété est vérifiée ou non.

  Propriété 1 Propriété 2
GET    
PUT    
POST    
DELETE    

Légende :

  • Propriété 1 = ?
  • Propriété 2 = ?

Q ? Quelles sont les cinq composantes d'une URI ?

Q ? Donner le nom de la norme utilisé pour développer des services Web en Java dans le style REST.

2 Introduction : la répartition de l'automate

Comme dans le premier TP, on cherche à décrire un service proposant la reconnaissance de langages réguliers fermés par préfixe : ce sont les langages reconnus par des automates dont tous les états sont finals. Précisément, on s'intéressera au langage régulier \((ab)^\ast + (ab)^\ast a\) formé d'une succession, éventuellement vide, de mots \(ab\), suivi possiblement d'un \(a\). Par exemple, les mots \(ab\), \(aba\) et \(abab\) sont reconnus alors que le mot \(abaa\) n'est pas reconnu. Pour reconnaître ce langage, on utilise un automate à deux états, UN et DEUX, l'état initial étant UN.

../medias/soc_automata_ab-star.svg

Automate reconnaissant le langage ((ab) + (ab) a)

Contrairement au premier TP, l'automate va être réparti en trois services au lieu d'un seul :

  • un service pour l'initialisation,
  • un service pour l'état UN,
  • un service pour l'état DEUX.

Avec une telle répartition, l'état des sessions devient doublement réparti : à tout moment, il est formé de l'ensemble des URI pointant vers les services et manipulées par les clients.

Cette pratique a une valeur paradigmatique, car l'état de nombreux services peut être modélisé par un automate. Elle permet d'obtenir un service "stateless" et d'appliquer le principe dit "Hateoas" ("Hypermedia As The Engine Of the Application State").

3 Automate : spécification par des règles chimiques

On spécifie les services et les clients à l'aide de règles chimiques. Ce modèle permet une spécification non seulement concise mais aussi précise des échanges de messages.

3.1 Services "stateless"

3.1.1 Service 0

Etat

  • Néant

Canal

  • initier(ar) : renvoie sur le canal ar le canal du service 1.

Règles

- initier(ar) -> ar(accepterUN)

3.1.2 Service 1

Etat

  • Néant

Canal

  • accepterUN(ar, c) : suivant la valeur de c, accepte le caractère c et renvoie sur le canal ar le canal du service 2, ou refuse le caractère c et renvoie KO sur le canal ar.

Règles

- accepterUN(ar, 'a') -> ar(accepterDEUX)
- accepterUN(ar, x) & (x != 'a') -> ar(KO)

3.1.3 Service 2

Etat

  • Néant

Canal

  • accepterDEUX(ar, c) : suivant la valeur de c, accepte le caractère c et renvoie sur le canal ar le canal du service 1, ou refuse le caractère c et renvoie KO sur le canal ar.

Q ? Donner les règles chimiques décrivant le comportement du service 2 (correspondant à l'état DEUX).

3.2 Client des services "stateless"

Etat

  • quatre états internes : Debut, EnCours, Succes, Echec
  • Mot(tab) : tableau de caractères tab formant le mot à transmettre à l'automate

Etat initial

Debut & Mot(['a', 'b', 'a', 'b'])

Canaux

  • rep(x) : reçoit en réponse un canal ou un message d'erreur KO.

Règles

- Debut -> initier(rep) & EnCours
- EnCours & rep(k) & Mot([tete, reste]) & (k != KO) -> k(rep, tete) & Mot(reste) & EnCours 
- EnCours & rep(k) & Mot([]) & (k != KO) -> Succes
- EnCours & rep(KO) & Mot(m) -> Echec

4 Automate : implémentation

On cherche à implémenter l'automate précédent par des services Web de style Rest.

4.1 Implémentation de l'automate et de ses états

Le modèle objet contient deux interfaces et trois classes d'implémentations, correspondant aux trois services à déployer en trois adresses distinctes (adresses qui pourraient être associées à trois machines distinctes).

Interfaces

  • Automate
  • EtatAutomate

Classes d'implémentation

  • A_B_point_Etoile
  • EtatUn et EtatDeux

Q ? Annoter la méthode initier par la méthode HTTP qui convient.

Q? Annoter la méthode initier de manière à garantir que le format utilisé pour représenter un hyperlien est JSON. On notera JSON la constante javax.ws.rs.core.MediaType.APPLICATION_JSON.

interface Automate {
  // TODO
  HyperLien<EtatAutomate> initier();
}

class A_B_point_Etoile implements Automate {
  private final URI adresse; // adresse du serveur hébergeant l'état UN
  public A_B_point_Etoile(URI adresse) {
    this.adresse = adresse;
  }
  @Override
  public
    HyperLien<EtatAutomate> initier(){
      return new HyperLien<EtatAutomate>(adresse);
  }
}

Q ? Annoter la méthode accepter par la méthode HTTP qui convient.

Q ? Annoter la méthode accepter de manière à ce que le chemin d'accès soit "suivant/a" si a est la valeur de x.

Q ? Compléter l'implémentation de EtatDeux.

interface EtatAutomate {
  // TODO
  HyperLien<EtatAutomate> accepter(char x) throws WebApplicationException;
}

class EtatUn implements EtatAutomate {
  private final URI adresse; // adresse du serveur hébergeant l'état DEUX
  public EtatUn(URI adresse) {
    this.adresse = adresse;
  }
  @Override
  public
    HyperLien<EtatAutomate> accepter(char x){
      if(x == 'a') {
        return new HyperLien<EtatAutomate>(adresse);
      }else{
        return null;
      }
  }
}

class EtatDeux implements EtatAutomate {
  private final URI adresse; // adresse du serveur hébergeant l'état UN
  public EtatDeux(URI adresse) {
    this.adresse = adresse;
  }
  @Override
  public
    HyperLien<EtatAutomate> accepter(char x){
      // TODO
  }     
}

4.2 Implémentation des hyperliens

Voici un squelette de la classe HyperLien.

// TODO
class HyperLien <T>{
  private URI uri;
  public HyperLien(URI uri){
    this.uri = uri;
  }
  // TODO
  public URI getUri() {
    return this.uri;
  }
  public T proxy(){
    ...
  }
}

Q ? Annoter la classe de manière à ce qu'un hyperlien puisse être traduit en un document XML de la forme <hyperlien uri="…"/>.

Q ? Dans quelle norme ces annotations sont-elles définies ?

5 Automate : test

5.1 Implémentation d'un client

Q ? Compléter la fonction tester(automate, mot) en suivant le scénario suivant.

  • Récupérer un hyperlien vers l'état initial de l'automate.
  • Tester si le mot passé en argument est accepté ou non.
  • Si c'est la cas, afficher dans la console : mot reconnu : X, où X est le mot passé en argument.
  • Sinon, récupérer l'exception de type WebApplicationException correspondant à une erreur de statut 404 pour afficher la chaîne mot non reconnu : X.

Indications : pour transformer un hyperlien en un proxy, utiliser la méthode HyperLien.proxy, qui renvoie un proxy vers l'état de l'automate pointé par l'hyperlien ; on pourra utiliser le typage implicite en déclarant les variables par "var x = …*.

static void tester(Automate automate, Character[] mot) {
  // TODO
}

5.2 Messages échangés

Q ? Décrire les deux requêtes successives permettant de déterminer si le mot "aa" est accepté ou non. On supposera que la ressource correspondant à l'état UN est à l'adresse A1 et celle correspondant à l'état DEUX est à l'adresse A2.

Requête 1

  • URI :
  • méthode HTTP :
  • statut de la réponse :
  • réponse (format XML) :

Requête 2

  • URI :
  • méthode HTTP :
  • statut de la réponse :
  • réponse (format XML) :

Author: Hervé Grall
Version history: v1: 2016-04-20; v2: 2017-04-21[update]; v3: 2017-12-12[update]; v4: 2020-10-21.
Comments or questions: Send a mail.
The webpage content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.