Design Pattern : Whiteboard

Pourquoi le pattern whiteboard?

Le pattern Whiteboard [1, 2] est un pattern un peu spécifique, il à la particularité d'être intimement associé à la technologie OSGI [3, 5] et comme il était question dans ce blog de parler de ce framework, nous voici donc avec une petite introduction de ce dernier via ce pattern de conception.

Au delà du prétexte de l'écriture d’un article introductif à OSGI, ce pattern pattern à bien entendu une raison d'être qui lui est propre: proposer une alternative raisonnable au pattern listener dans la conception de logiciel à base de microservice comme le permet OSGI [4].

On entrevoit donc ici les raisons de l’utilisation du pattern mais pour etre plus precis, nous regarderons avant cela les concepts de base de OSGI afin d’en comprendre les besoins et avant de détailler plus en avant le pattern whiteboard, nous regarderons pourquoi le pattern listener n’est plus satisfaisant dans certaines situations.

Techno OSGI dans les grandes lignes

La technologie OSGI ou Open Service Gateway Initiative est un framework Java pour la construction d’application à base de composants et de services. Il s’agit d’un framework ayant pour vocation initial la réalisation d’application à taille réduite où la gestion mémoire est millimétré.

Il permet techniquement de gérer simultanément des librairies java évoluant dans des versions différentes ainsi que de charger et décharger ces librairies dynamiquement sans nécessiter le redémarrage de la JVM. Par contre, pour permettre ces capacités, OSGI “impose” (mais en fait c’est un bien) un paradigme de modélisation impliquant la construction de nos application selon une architecture un peu spécifique à base de composant (les bundles) et de services.

Avec cette petite introduction, on perçoit rapidement l'intérêt de ce framework! Nous y reviendrons plus tard, nous en avons vu l’essentiel pour l’instant. Il faut surtout en retenir que OSGI nous permet de construire des applications modulaires à base de composants et de services. Dédié initialement à l’embarqué, il est sortie rapidement de son contexte d’utilisation initial et s’est alors confronté aux méthodes et techniques de construction des architectures logiciels classiques.

Pourtant avec une architecture tel que proposée par OSGI, ce pattern comporte de nombreuses limites.

En effet, dans une architecture à composant ou les dépendances entre composant ne peuvent être forte, il est nécessaire de permettre à deux objets de communiquer sans forcément qu’ils aient connaissance de l’un et de l’autre directement.

Pattern Listener et limites

Entre autre, le cas du pattern Listener est caractéristique car dans le cadre de son utilisation dans le cadre OSGI, il comporte quelques limites.

Nous avons traité le pattern listener dans un autre article [6], je n’y reviendrais pas ici. disons simplement que ce pattern est un pattern d’architecture et comportemental permettant le découplage d’un observateur et d’un observer tout en formalisant son moyen de communication via un objet de type événement. Il s’agit en fait du pattern observateur mais simplifié.

Ce pattern est souvent utilisé pour sa nature événementielle dans le cadre de la gestion des IHM. Ainsi, par exemple, lorsque utilisateur sollicite la souris de son ordinateur, le contrôleur associé va générer des événements permettant de suivre ses déplacements. L'utilisation du pattern listener est en première approche une solution intéressante pour traiter ces événements surtout lorsque les sources possibles sont multiples. Pourtant c’est là sa limite également. Car alors si ces sources produisent de multiples événements simultanément alors le système peut être soumis à un “EventStorm” [1] amenant à une utilisation élevée de la mémoire et du CPU, perdre gravement en performance et dans le pire des cas conduire à un crash.

Whiteboard pattern

Le pattern Whiteboard est une solution apportée comme alternative au pattern listener dans le cadre du framework OSGI.

Il est intimement lié à OSGI cependant comme nous verrons ce framework par la suite il me semble plus pertinent d'éviter d’entrer dans trop de détails d'implémentation lié à cette technologie. Ainsi nous nous attacherons à une présentation d’un modèle abstrait du pattern (sous la forme d’un type PIM, Plateform Independant Model dans le MDA [7])

Ce pattern propose de découpler la source des événements du listener en introduisant un objet supplémentaire entre les deux servant de registre et transformant la relation entre les deux éléments par une relation de service et de consommateur de service.

Ce qui servait donc de listener devient un composant fournissant un service qui sera enregistrer dans un registre. La source des événements aura alors la tâche de demander au registre le service adéquat afin de pouvoir lui transmettre les événements produits.

L'intérêt de l'approche en ajoutant ce registre qui finalement réalisé la réification de la relation listener/sources des événements est de permettre de contrôler cette relation et son utilisation par la source des événements.

Il va être alors possible :

de réaliser du monitoring sur le flux d’informations voir même de le debugger
de rendre indisponible le service du listener si celui ci est trop utilisé et implique une consommation des ressources trop importante
d’adjoindre des droits spécifiques d’utilisations en ajoutant sur le registre une couche de sécurité et des permissions afin de ne pas le rendre disponible à n’importe quel consommateur du service venu
injecter des propriétés spécifique pour customiser le mapping (comme par exemple pour préciser un quota en événement par seconde à traiter ou pour proposer une taille de tampon d'événements, etc…)

Exemple

Pour illustrer ces mécanismes voici dans un contexte hors OSGI ce qu proposerait une implémentation du pattern listener (observateur) et ensuite son équivalent dans la philosophie du pattern Whiteboard. On précise ici que l’on reste dans une implémentation de type PIM afin de ne pas perturber la compréhension du pattern avec les spécificités technologiques du framework OSGI

Avec Listener

package listener

class Event{
    String message

    Event(String m){
        this.message=m
    }
}

interface IObserver{
    def update(Event e)
}

interface IObserved{
    def notifyAll(Event e)
}

class TrucQuiEcoute implements IObserver{
    def update(Event e){
        println("Reception d'un message")
        println(">>"+e.message)
    }
}

class TrucQuiFait implements IObserved{
    List obs=new ArrayList<Observer>()

    def notifyAll(Event e) {
        for( Observer o in obs){
            o.update(e)
        }
    }

    def makeSomething() {
        def e = new Event("Ceci est le message")
        println("Envoie d'un message")
        this.notifyAll(e)
    }
}


def ob=new TrucQuiEcoute()
def obd=new TrucQuiFait()
obd.obs.add(ob)
obd.makeSomething()

Avec Whiteboard

package whiteboard

interface IService{
    def serve(Event e)
}

class ServiceRegister{
    Map services=new HashMap<String,IService>()
}

class Event{
    String message

    Event(String m){
        this.message=m
    }
}

class TrucQuiEcoute implements IService{
    def serve(Event e){
        println("Reception d'un message")
        println(">>"+e.message)
    }
}

class TrucQuiFait implements IService{
    ServiceRegister register;

    TrucQuiFait(ServiceRegister register)
    {
        this.register=register;
    }

    def serve(Event serviceNameEvent) {
        def e = new Event("Ceci est le message")
        println("Envoie d'un message")
        this.register.services.get(serviceNameEvent.getMessage()).serve(e)
    }
}

def reg=new ServiceRegister()
reg.services.put("TrucQuiEcoute",new TrucQuiEcoute())
reg.services.put("TrucQuiFait",new TrucQuiFait(reg))

reg.services.get("TrucQuiFait").serve(new Event("TrucQuiEcoute"))

Conclusion

Voilà nous avons fait le tour de ce pattern un peu spécial enfin, surtout un peu spécialisé, qu’est le pattern Whiteboard. Celui-ci est très associé à OSGI mais il peut se comprendre sans et surtout mieux comprendre certains mécanisme de ce framework que nous verrons dans un prochain article.

Références

[1] https://www.osgi.org/wp-content/uploads/whiteboard1.pdf
[2] https://en.wikipedia.org/wiki/Whiteboard_Pattern
[3] https://www.osgi.org/
[4] https://enroute.osgi.org/FAQ/400-patterns.html
[5] https://www.theserverside.com/news/1363820/The-Whiteboard-Pattern-for-OSGi
[6] https://un-est-tout-et-tout-est-un.blogspot.com/2017/11/design-pattern-observateur.html
[7] https://laine.developpez.com/tutoriels/alm/mda/generalites-approche-mda/

Un est tout et tout est un

Thématiques principales

jeudi 8 novembre 2018