Projet nº2: L'application Snackbar (partie 2)
Évolution de l'interface VendorService
L'interfaceVendorService a évoluée pour inclure de
nouvelles méthodes. La méthode String
buy() est désormais dépréciée:
package snackbar.service.vendor;
/**
* A simple service interface for the SnackBar application
* @version 1.1.0
*/
public interface VendorService {
/**
* Service registration property (String) defining the type of thing sold by the vendor.
* This property is mandatory.
*/
public final static String TYPE = "type";
/**
* Get the name of the vendor
* @return the name of the vendor
*/
public String getName();
/**
* Buy a thing
* @return a string representing the bought thing, null if the sale was discarded
* @deprecated remplaced by {@link #buy(int)}
*/
public String buy();
/**
* Buy number of things
* @param number Number of things to buy
* @since 1.1.0
* @return the number of things sold, 0 if the sale was discarded
*/
public int buy(int number);
/**
* Get the stock level of things
* @since 1.1.0
* @return the current stock level
*/
public int getStockLevel();
}
Compilez et installez la nouvelle version de l'interface
VendorService en utilisant
le service de déploiement que vous avez développé.
Que se passe-t-il?
Étape nº1: La nouvelle version de vendor.popcorn
Faites évoluer la version (0.1.0 ⇒ 0.2.0) devendor.popcorn pour que le
bundle implémente la nouvelle version
(1.1.0) de l'interface VendorService.
N'oubliez pas de modifier la variable
version=0.2.0 du fichier
manifest.mf. Compilez et installez la
nouvelle version du bundle
vendor.popcorn en utilisant le service
de déploiement que vous avez développé. Que se
passe-t-il?
Étape nº2: La nouvelle version de customer.scr
Faites évoluer la version (0.1.0 ⇒ 0.2.0) decustomer.simple vers
customer.scr pour que le bundle
utilise les méthodes ajoutées à la nouvelle version
(1.1.0) de l'interface VendorService.
Bien que simple, ServiceTracker ne
permet pas cependant de réaliser simplement des
services dont l'existence est conditionnée par la
présence d'autres services. Comme nous l'avons déjà
dit le vendeur de hotdog ne peut remplir son service
que s'il existe au moins un vendeur de brioche et
s'il existe au moins un vendeur de saucisse (pour
l'approvisionner). Le spécification 4 propose un
modèle à composants orienté services (appelé
Declarative Services et aussi connu sous le
nom de Service Component Runtime (SCR)) qui
capture la dynamique des services et assujettit le
cycle de vie de l'objet usager à la présence et à
l'absence des services référencés obligatoires. Le
développement est grandement simplifié par la
description du composant au moyen d'un descripteur
déclaratif dans une grammaire XML. Ce modèle de
composant autorise l'écriture d'applications à partir
de composants orientés service mais également de
services fournis par des bundles
patrimoniaux. Modifiez le code du service customer
que vous avez développé dans la première partie pour
qu'il utilise désormais le bundle
Service Component Runtime
(SCR). N'oubliez pas d'ajouter la ligne
Service-Component:
OSGI-INF/component.xml à votre fichier
manifest.mf pour indiquer dans quel
fichier se trouve la description des composants à
déployer pour le bundle. Compilez et installez la
nouvelle version du bundle
customer.scr en utilisant le service
de déploiement que vous avez développé. Que se
passe-t-il?
Étape nº3: Le service de journalisation
Le service de journalisation LogService permet d’enregistrer des événements, des alarmes, des traces se produisant au cours de la vie d’un bundle ou d’un service. Dans la spécification OSGi release 4, la journalisation repose sur 4 types d’éléments, à savoir :LogService, qui est l’interface de service qui permet à un bundle de journaliser une information composée d’un message, d’un niveau de journalisation, d’une exception, d’un objet de typeServiceReference,LogEntry, qui est l’interface définissant une entrée d’un journal,LogListener, qui est l’interface à implanter afin de pouvoir être mis à l’écoute de la création de nouveaux objetsLogEntry,LogReaderService,qui est l’interface de service permettant d’accéder à la liste des objets de typeLogEntryet d’enregistrer des objets de typeLogListener, objets qui seront invoqués lors de création de nouveaux objetsLogEntry,
LogService
L'exercice consiste premièrement à remplacer les horriblesSystem.out.println(...) et
System.err.println(...) qui se trouve un
peu partout dans les bundles. Pour cela, il
vous faudra vous lier au service
org.osgi.service.log.LogService au moyen
d'un ServiceTracker. Attention,
n'oubliez pas d'ajouter
org.osgi.service.log dans
l'Import-Package du manifeste du
bundle.
LogListener
Ensuite, pour "écouter" les entrées d'un journal, il est nécessaire d'enregistrerun objet
org.osgi.service.log.LogListener auprès du
service
org.osgi.service.log.LogReaderService du
journal. Un exemple de LogListener est
illustré par le bundle
loglistener.console. Les entrées
écoutées sont
affichées sur la console
System.out:
import java.io.PrintStream;
import org.osgi.framework.BundleContext;
import org.osgi.service.component.ComponentContext;
import org.osgi.service.log.LogEntry;
import org.osgi.service.log.LogListener;
import org.osgi.service.log.LogReaderService;
/**
* This class implements a LogListener which displays log entries on the standart output
*/
public class ConsoleLogListener implements LogListener {
// XmlLogFormater, HtmlLogFormater, JSONLogFormater
private LogFormater logFormater=new TextLogFormater();
private PrintStream out;
public void logged(LogEntry entry) {
out.print(logFormater.getLogEntry(entry));
}
// lifecycle callback methods
public void activate(ComponentContext ctxt) {
out.print(logFormater.getLogHead());
}
public void deactivate(ComponentContext ctxt) {
out.print(logFormater.getLogTail());
out=null;
}
// binding callback methods
public void bindLogReaderService(LogReaderService logReaderService) {
logReaderService.addLogListener(this);
}
public void unbindLogReaderService(LogReaderService logReaderService) {
logReaderService.removeLogListener(this);
}}
Étape nº4: Le service HttpService
Dans le cadre de cet exercice, on souhaite compléter l'application Snackbar par un bundle permettant à un client d'acheter des produits aux vendeurs via un navigateur Web. Pour concevoir ce bundle, vous devrez développer le code source de la servletHttpCustomer contenue dans le
bundle customer.http, puis
déployer le service implémentation
HttpService sur votre passerelle, et
utiliser l’API Servlet pour mettre en oeuvre votre
bundle. Celui-ci devra être capable de
répondre à des requêtes HTTP de type
GET sur l’URL
http://localhost:8080/snackbar/customer.
Étape nº5: Le service EventAdmin (bonus)
Le service standard
EventAdmin offre la
possibilité de publier et consommer des événements
métier émis par les bundles de l'application.
Développez un bundle
AutoRefill qui consomme des
événements asynchrones de type
snackbar/vendor/OUT_OF_STOCK et
produit des événements synchrones de type
snackbar/vendor/REFILL consommés par
les bundles Vendor pour
recharger automatiquement leur stock. Seuls les
bundles publiant l'événement
snackbar/vendor/OUT_OF_STOCK doivent
consommer l'événement
snackbar/vendor/REFILL. Quand le
bundle AutoRefill n'est pas
déployé dans l'environnement d'exécution OSGi, les
bundles Vendor ne sont pas
rechargés automatiquement.
Remise du projet
Le projet (parties 1 & 2) est à rendre avant le mercredi 09 décembre 2010 à 14h00 via l'interface PROF.Contenu:
- Le code source des projets correspondant aux bundles développés
- Un fichier
readme.txtdécrivant les résultats obtenus (ou pas)
- n'utilise pas de proxy (connexion directe) pour
le serveur
intranet.fil.univ-lille1.fr - accepte les cookies en provenance de ce serveur