Ce premier projet propose de développer une application Snackbar en utilisant les concepts de base d'OSGi. Read More...

Tags: OSGi

Évolution de l'interface VendorService

L'interface VendorService 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) de vendor.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) de customer.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 type ServiceReference,
• 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 objets LogEntry,
• LogReaderService,qui est l’interface de service permettant d’accéder à la liste des objets de type LogEntry et d’enregistrer des objets de type LogListener, objets qui seront invoqués lors de création de nouveaux objets LogEntry,
  

LogService

L'exercice consiste premièrement à remplacer les horribles System.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'enregistrer un 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 servlet HttpCustomer 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.txt décrivant les résultats obtenus (ou pas)

Note: il faut que votre navigateur :

• n'utilise pas de proxy (connexion directe) pour le serveur intranet.fil.univ-lille1.fr
• accepte les cookies en provenance de ce serveur

Tags: OSGi