4.3. emit meter
Ce dossier correspond aux services qui permettent de retrouver les données des instruments. Les différentes servlets et leurs rôles ont déjà été présentés dans le chapitre 3. Le code de ce dossier est découpé en trois dossiers, un pour chaque instrument disponible actuellement.
L'architecture pour chaque instrument est globalement identique. On retrouve les servlets correspondant à:
- data, pour renvoyer les données
- meta, pour renvoyer le type d'informations reçues (volt, puissance...)
- type, pour indiquer si la servlet est présente ou non (pour le test)
- start, pour lancer une acquisition
- stop, pour l'arrêter
Ces 5 classes sont de simples servlets qui se contentent d’appeler les procédures correspondantes et de renvoyer les résultats au client.
Il y a une classe servlet qui est héréditaire et sert à définir les méthodes d'initialisation nécessaires aux autres servlets notamment la création de l'objet meter, qui contient les procédures qui nous intéressent.
La classe meter contient les procédures qui sont appelés pour les services stop, start, et retrieve (les autres envoient toujours le même résultat et sont plutôt informatives. Ici pour les trois instruments le code est un peu différent.
Pour ce cas, tout ce que fait cette classe c'est appeler des services identiques écrits en PHP sur le serveur. Ces services déclenchent l'écriture des données dans un fichier .csv à un endroit déterminé et un autre service PHP récupère ce fichier et l'envoie au programme java. Ici on a donc deux services doubles, un en java qui se contente d'appeler le service en PHP, et de transférer les résultats au client.
Cet instrument fonctionne d’après l'ancien paradigme (il faut le changer). Il y a dans cette classe de nombreuses méthodes qui servent juste à la lecture du flux d'information envoyé par l'instrument. Ici cette classe est implémentée en "runnable" ce qui veut dire que l'on peut lancer la procédure de cette classe appelée run() en parallèle du tread principale (un tread est une ligne de tâche).
Cette ligne d'exécution est lancée à la fin de la procédure doStart. Cette procédure sert à initialiser le lecteur de port série et à lancer l’acquisition.
La méthode run enregistre les informations au fur et à mesure dans un fichier jusqu'à ce que l'utilisateur stoppe l’acquisition. L'arrêt se fait avec la méthode doStop qui interrompt le thread.
Une fois cette acquisition stoppée l'utilisateur peut lancer doRetrieve qui restituera le fichier enregistré. Avec cette méthode le problème est que l'information est enregistrée caractère par caractère et les lignes de début et de fin d’acquisition sont souvent coupées ce qui complique l'exploitation du résultat.
L'autre problème concerne l'utilisation de la bibliothèque de lecture du port série qui part en boucle infinie régulièrement et cela empêche toute interruption de l'exécution et bloque le service. De plus il n'existe pas de méthode pour vider la mémoire de la librairie qui est donc intégralement restituée à chaque expérience.
Pour régler le problème le fonctionnement de l’acquisition, on a basculé en local et on se contente maintenant d'aller chercher les informations dans le flux géré par la messagerie. Ici on reçoit les informations ligne par ligne, qui sont ensuite enregistrées dans un string au fur et à mesure des réceptions de message. La gestion de la lecture des ports séries se fait en local. Pour le code que l'on a utilisé, il est en grande partie expliqué dans la documentation de RabitMQ côté client.
Consumer consumer = new DefaultConsumer(channel){
String message = "";
// on écrase les méthodes de DefalltConsummer dont on a besoin pour récupérer les résultats.
@Override
public void handleDelivery(String consumerTag, Envelope envelope,
AMQP.BasicProperties properties, byte[] body)
throws IOException {
message = message + new String(body, "UTF-8")+"\r\n";
}
@Override
public String toString(){
return message;
}
};Comme dans la documentation, ici on crée un objet "consumer". Cet objet créer la méthode asynchrone qui va récupérer les données de la messagerie. On y écrase la méthode handleDelivery à la création (on peut aussi le faire par héritage) pour qu'elle traite la livraison comme on le souhaite. Ici on a rangé les lignes reçues dans un string et on a écrasé la méthode "toString" pour récupérer cette variable.