La gestion des liaisons de service et la communication avec la couche de gestion des
accords de niveau de service se font au niveau du conteneur du modèle à composants.
Nous partons du principe qu’un modèle à composant orienté services fournit au minimum
les fonctionnalités suivantes.
• Pour un fournisseur de service :
o Publication du service dans un annuaire ou d’une annonce de
disponibilité.
o Retrait du service de l’annuaire ou bien annonce d’indisponibilité.
o La publication et le retrait de service sont exécutées respectivement à
l’activation du composant et lorsque celui-ci est désactivé.
• Pour un consommateur de service :
o Découverte passive des fournisseurs de service.
o Injection des liaisons vers les services à consommer. Ces liaisons sont
aussi appelées dépendances de services.
o Gestion du cycle de vie du composant en fonction de la résolution de ses
dépendances de service.
Sur cette base, notre proposition étend le conteneur sur les deux plans : au niveau de la
livraison de service, et au niveau de la consommation de service. La Figure 48 décrit le
fonctionnement de la couche SLA pour gérer les liaisons de service, ainsi que les
connexions entre les parties du conteneur dédiées à la gestion des accords
(enregistrement, négociation) et celles dédiées à la gestion des services (publication,
découverte, liaison, retrait).
Le conteneur d’un composant fournisseur de service se charge, en plus de la publication
et du retrait de service, de l’enregistrement d’une offre de SLA auprès du DSLA Manager
via le service de négociation, et de son retrait. L’offre est en fait constituée des SLOs que le
fournisseur peut potentiellement s’engager à respecter pour un service donné. Les
capacités du fournisseur concernant sa disponibilité sont donc fournies au conteneur sous
forme de méta-données. Le conteneur fait ensuite appel au service du DSLA Manager
pour enregistrer cette offre si cela n’avait pas déjà été fait précédemment. Nous proposons
également d’agir au niveau de la publication du service. Les capacités peuvent être
elles-mêmes publiées avec le service en tant que propriétés extra-fonctionnelles. Le conteneur
gère de surcroît la confirmation de terminaison des accords suite aux notifications du
DSLA Manager.
Container Container
Provider
Provider
DSLA
Manager
DSLA
Manager
Container ContainerConsumer
Consumer
Service discovery and binding Publish & remove service •Negotiate SLA•Verify SLO states
•Confirm termination
•Add / remove SLA offers
•Confirm termination
binding
Figure 48. Utilisation du DSLA Manager par le conteneur pour la gestion des liaisons de service
Au niveau de la membrane d’un consommateur de service, la relation entre la gestion
des liaisons et celle des SLAs est plus étroite. En effet, la sélection d’un fournisseur doit
faire suite à la négociation d’un accord avec ce fournisseur. De plus les liaisons doivent
être supprimées, substituées ou conservées selon l’état du respect des SLOs. La partie du
conteneur concernant le rôle de consommateur utilise donc les services du DSLA Manager
pour :
1. Filtrer les prestataires lors de la phase de découverte à partir de l’expression des
besoins concernant l’intermittence de service, en plus du filtrage portant sur
d’autres propriétés extra-fonctionnelles.
2. Négocier un accord de niveau de service suite à la découverte d’un fournisseur
du service requis.
3. Prendre les décisions concernant la liaison de service à partir de l’état de validité
du SLA. Tant que le contrat n’est pas rompu par une violation de SLO, la liaison
vers le prestataire courant est conservée même si ce dernier est indisponible, et
le composant n’est donc pas désactivé/stoppé. La liaison n’est détruite ou
remplacée par une autre que lorsque les contraintes d’intermittence ne sont plus
respectées.
4. Confirmer la terminaison de l’accord suite à une annonce du DSLA Manager.
Lorsqu’un accord n’est plus respecté par le prestataire, en fonction de la configuration
du composant concernant la politique de recours à adopter, le conteneur peut en outre
mettre le fournisseur responsable sur liste noire. En pratique son identifiant est ajouté au
filtre de sélection afin de l’exclure des futures découvertes de service.
Troisième partie : Expérimentation et
Résultats
Chapitre VII
Implémentation
“ Plus vous laissez de temps à un travail pour se réaliser, et plus il a tendance à prendre ce temps qui s'allonge pour se réaliser. ” Cyril Northcote Parkinson
Afin de mettre en œuvre l’approche et l’architecture logicielle décrites dans le chapitre
précédent, nous avons fait le choix de nous appuyer sur la plate-forme dynamique à
services OSGi et le modèle à composants orientés service iPOJO.
Ces deux technologies fournissent les mécanismes nécessaires à la réalisation :
• un support des architectures dynamiques orientées services,
• et la possibilité d’étendre le conteneur des composants, notamment la partie
chargée de la gestion des liaisons.
Cependant comme ces technologies ne spécifient rien en ce qui concerne les accords de
niveau de service, il a fallu concevoir un module de gestion des SLAs en concentrant nos
efforts sur les critères de disponibilités définis dans le chapitre IV.2.3. Cette forme de SLA
est néanmoins extensible à d’autres domaines que la disponibilité, et son accessibilité
convient à une vision qui se situe au niveau du composant.
Ce chapitre décrit ce qui a motivé le choix d’OSGi et iPOJO, puis comment les
différentes couches constitutives de notre canevas ont été implémentées sur Apache Felix
(une implémentation open-source d’OSGi R4) et Apache iPOJO.
Dans le document
Politique de Liaison aux Services Intermittents dirigée par les Accords de Niveau de Service
(Page 140-144)