[OSGi] Service model vs. extender model [Résolu]

[identifiant_bidon]

Bonjour à tous,

Voila, je me (re)mets à bosser sur OSGI. Je cherche à changer l'architecture de mon application pour en faire une application à base de plugins. Je lisais cette page :

http://felix.apache.org/site/apache-...nstration.html

Ceci dit, il y est fait mention de service model et d'extender model.

Quelqu'un peut-il m'expliquer la différence entre ces deux modèles ?

Merci beauoup

[George7]

Salut (oui encore moi )

Alors ils expliquent (très) rapidement au début de l'article la différence.
En fait pour faire une application extensible en terme de fonctionnalités :

• un bundle qui a tout un set de services différents qu'il active ou désactive à la demande (configuration, dynamiquement, ...), c'est plutôt le service model, où l'extensibilité de ton appli est pas obligatoirement basée sur différents bundles
• chaque fonctionnalité est empaquetée dans un bundle, et pour en ajouter/supprimer, il te suffit d'installer/désinstaller un bundle, c'est plutôt le extender model

Ceci dit c'est du vocabulaire uniquement, il faut surtout analyser ses besoins avant et déterminer ce qui a un sens dans la séparation des services. En général tu as un mélange des deux : plusieurs bundles qui ont chacun plusieurs services, qui peuvent être déployés ou non.
La séparation des fonctionnalités et services entre bundles est plutôt compliquée et chacun a sa vision des choses, la question à se poser est : quelles sont les services et fonctionnalités dont j'aurai toujours besoin ensemble, alors il peut être sensé de les mettre dans les mêmes bundles.
Mais bon y'a pas de réponse universelle et vaut mieux résoudre au cas par cas.
Je dévie de la question un peu mais pour résumer : te casse pas trop la tête avec ce vocabulaire pour l'instant et réfléchis plutôt à ce qui est sensé pour ton application, comme savoir si ton appli est un bundle ou si tu préfères embarquer le framework, et ensuite de quelle modularité as-tu besoin (en terme de granularité, et de séparation des fonctionnalités). Trop de modularité n'est pas non plus souhaitable en général, car ça rend l'architecture complexe a comprendre et maintenir, pour des choses dont tu n'auras jamais besoin.
De toute façon quelle que soit la solution que tu choisiras, tu devras sûrement séparer ou rassembler par la suite des choses que tu avais pas prévues

[Nemek]

Je rajouterai également qu'il est plus facile de gérer le cycle de vie des bundle que des services. A moins qu'il y ait des listener sur les services ?

[identifiant_bidon]

Ok, j'y vois un peu plus clair, merci George7 (content d'avoir de tes nouvelles )

[George7]

Envoyé par Nemek

Je rajouterai également qu'il est plus facile de gérer le cycle de vie des bundle que des services. A moins qu'il y ait des listener sur les services ?

Certes les bundles sont gérés automatiquement par le framework. Mias c'est aussi plus lourd à mettre en place un bundle par service, il faut trouver le juste milieu
Pour écouter et gérer les services, je trouve souvent le ServiceTracker mieux que les listeners (ils permettent notamment de détecter les services déjà en place lors du déploiement du tracker)

[Nemek]

Après consultation de la Javadoc il est effectivement possible d'être notifier de "l'arrêt" d'un service.
J'avoue n'avoir utiliser le ServiceTracker uniquement pour récupérer la liste des services actifs sans savoir si je pouvais "écouter" l'ajout ou la suppression d'un service.