Fonctionnement

Les clients emploient un service d'un vendeur pour acheter des hot-dogs ou du pop-corn selon la disponibilité de la marchandise chez les vendeurs. Le bundle vendeur de pop-corn et le bundle vendeur de hot-dog mettent en application (et fournissent) le service VendorService.
Le vendeur de hot-dog dépend de deux autres services VendorService pour acheter les ingrédients: des brioches (bun) et des saucisses. Il dépend donc du service d'un vendeur de brioche et du service d'un vendeur de saucisses (weiner).

L'interface de service VendorService

L'interface de service utilise entre les éléments de l'application SnackBar est la suivante. Elle constitue une spécification partagée entre tous les développeurs de clients et de vendeurs (via le bundle Vendor API):

package snackbar.service.vendor;

/**
* A simple service interface for the SnackBar application
* @version 1.0.0
*/
public interface VendorService {
/**
* Service registration property (String) defining the type of thing sold by the vendor.
* This property is mandatory.
*/
final static String TYPE = "type";

/**
* Get the name of the vendor
* @return the name of the vendor
*/
String getName();

/**
* Buy a thing
* @return a string representing the bought thing, null if the sale was discarded
*/
String buy();
}

L'architecture globale de l'application

A cette étape, nous allons conditionner chaque client et chaque vendeur dans un bundle indépendant. L'application est constituée des bundles suivants:

• customer.simple
• vendor.popcorn
• vendor.hotdog
• vendor.bun
• vendor.weiner

Ils dépendent tous du bundle vendor dont ils importent le package snackbar.service.vendor; version=1.0.0. Ces bundles pourront être déployer dans un ordre quelquonque ou bien être mis-à-jour de manière indépendante. L'établissement des liaisons (de service) entre les clients et les vendeurs passent désormais par le registre de service :

• chaque vendeur publie son service VendorService (en le qualifiant de la propriété type indiquant le produit vendu)
• chaque client recherche les services VendorService désirés (en fonction de la valeur de la propriété type) et réagit aux départs et aux arrivées des services VendorService.

Ces liaisons entre les bundles de l'application sont résumées sur le schéma suivant:

Rappels:
1. Selon les principes de l'Architecture orientée service (SOA), le choix d'un service parmi plusieurs est "décidé" lors de l'exécution (late binding).
2. Selon les principes du SOA dynamique, tout service est substituable en cours d'exécution par un autre si ce dernier fournit le service démandé (interface Java + propriétés d'enregistrement).

Fabrique d'instance de services

L'interface ServiceFactory permet d'implémenter le patron de conception Fabrique (Factory de E. Gamma). Cette interface comporte 2 méthodes :

Object getService(Bundle bundle, ServiceRegistration registration);
void ungetService(Bundle bundle, ServiceRegistration registration, Object service);

La méthode getService() fabrique une instance quand le bundle demandeur invoque la méthode Object getService(ServiceReference reference) sur le bundle context. Ainsi plusieurs différentes instances remplissent le même service pour des clients (requester) différents. Les utilisations possibles du ServiceFactory sont:

• Gestion de sessions multiples (comme dans des GUI avec Multi-fenêtrages, des shells à sessions multiples...),
• Contrôle d’accès en fonction du bundle Requester (le bundle réclamant le service est connu),
• Personnalisation en fonction du bundle Requester (le bundle réclamant le service est connu),
• Si le service manipule son ServiceRegistration.

Modifiez le service Bun Vendor pour refuser tous les achats venant de bundles dont le Bundle-SymbolicName contient customer ! (ce service ne sert que des revendeurs !!)

Tags: OSGi