La gestion des accords de niveau de service est assurée par le DSLAAdmin. Afin que ce
composant puisse créer les accords et fixer les objectifs de niveau de service, les parties
identifiées de manière unique doivent lui fournir les informations nécessaires, celles-ci
étant définies par le développeur du composant. Et pour être en mesure de superviser le
respect de ces accords, le DSLAAdmin exploite l’historique des interruptions relevées par
le DisruptionLogger.
VII.2.1 Identification unique et persistante
En premier lieu les fournisseurs de service sont identifiés par un PID (Persistent
IDentifier) pour répondre au besoin d’identification unique et persistante des parties. La
spécification OSGi définit dans ce but une propriété service.pid associée à une chaîne de
caractères qui peut être renseignée pour chaque composant fournisseur de service.
Lorsque le développeur spécifie un identifiant pour une partie prestataire de service, cet
identifiant sert de PID au service publié faisant l’objet de l’accord. Par exemple, dans le
cas de services UPnPDevice, de la spécification UPnPBaseDriver d’OSGi, c’est la propriété
GUID qui est utilisée, et dans le cas d’équipements Bluetooth, le PID pourra être forgé à
partir d’une adresse MAC.
VII.2.2 Des méta-données aux objectifs de niveau de service
Les SLOs sont générés par le composant de négociation à partir de l’intersection de
l’offre d’un fournisseur et des besoins d’un consommateur. Ces derniers sont injectés dans
le conteneur des composants consommateurs et fournisseurs de service à partir de leurs
méta-données de configuration iPOJO.
Les méta-données d’un fournisseur vont servir à construire l’offre d’accord tandis que
celles des consommateurs serviront à la négociation des offres. Les méta-données
consistent en :
• des informations sur les parties : identifiant, nom et description ;
• la spécification de service (le nom de l’interface de service fournie) pour un
fournisseur ;
• le champ de la dépendance de service pour un consommateur, avec un filtre
optionnel pour la sélection ;
• la durée de l’accord ;
• les objectifs de niveau de service définis par les attributs suivants : nom, valeur,
description, unité, relation d’ordre et extensions ;
A partir de ces informations, d’autres seront générées pour construire l’objet
représentant l’accord. Par exemple la date de début de l’accord est fixée à l’issue de la
négociation et la date de fin calculée d’après la durée ; l’identifiant de l’accord combine
ceux des parties, etc.
VII.2.3 DSLA Admin
Le gestionnaire d’accords de niveau de service DSLAAdmin (qui remplit le rôle du
DSLAManager présenté dans le chapitre précédent) est un composite iPOJO. Il est
composé d’un composant singleton fournissant un service de négociation et d’un autre
composant (DSLM) chargé de la supervision du niveau de service concernant les
interruptions de service.
Le composant de négociation fournit un service permettant :
• d’enregistrer une offre composée d’informations sur le prestataire, de la
spécification de service, de la durée de l’accord et d’une proposition de SLOs;
• de retirer une offre en précisant l’identifiant du fournisseur de service dont il
faut supprimer l’annonce ;
• de négocier un accord en passant les besoins en termes de SLOs, le nom de la
spécification de service concernée, une liste optionnelle de fournisseurs (leurs
identifiants) avec lesquels le consommateur souhaiterait collaborer, et les
informations du consommateur (nom, identifiant, description) afin de remplir le
SLA en cas de négociation réussie.
Les accords négociés sont ensuite gérés par le DSLAAdmin. Les objets SLAs sont
sauvegardés après la négociation. Ainsi, les accords déjà établis peuvent être chargés au
démarrage du DSLAAdmin. Ensuite, l’état de l’accord est maintenu à jour selon le respect
des SLOs. Et lorsqu’une partie (consommateur, fournisseur ou SLM) demande la
terminaison de l’accord le DSLAAdmin passe le SLA dans l’état « terminé » et envoie une
notification de terminaison via le service d’EventAdmin
7aux parties impliquées. L’accord
n’est effectivement supprimé que lorsque le DSLAAdmin a reçu confirmation de la
terminaison de la part de toutes les parties.
Le composant de supervision du respect des SLOs est assigné au suivi d’un SLA en
particulier. Il y a en effet une instance de composant DSLM par accord. Les instances sont
créées configurées et gérées par le DSLAAdmin. A la fin de la phase de négociation d’un
accord, le composant de supervision est instancié via sa fabrique et ses informations sont
intégrées dans la partie du SLA relative au contexte et à la partie tierce.
Ce composant requiert le service du DisruptionsLogger puisque durant toute la durée de
l’accord, le DSLM utilise le DisruptionLogService pour suivre le fournisseur de service
engagé dans l’accord. A partir de l’historique des interruptions du fournisseur, il est
capable de détecter la violation des trois clauses « temps maximum d’interruption »,
« temps d’interruption cumulé maximum », et « temps de fonctionnement minimum
entre interruptions ».
Une fois le SLA terminé, quelque soit la raison, le DSLAAdmin détruit l’instance de
DSLM attachée à l’accord.
VII.2.4 DisruptionsLogger
Le DisruptionsLogger est un composant iPOJO fournissant le service de suivi des
interruptions. Il permet aux objets implémentant l’interface DisruptionListener:
• de s’abonner afin de demander le suivi d’un fournisseur et d’être notifié des
interruptions et retours d’interruption de ce dernier ;
• de se désabonner ;
• d’accéder à l’historique des interruptions d’un fournisseur de service identifié
d’après son PID.
A l’instar des autres composants proposés ici, le service (la spécification) et son
implémentation sont livrées dans deux bundles indépendants.
L’historique des interruptions d’un fournisseur se présente sous la forme d’une liste
dont chaque entrée est un tableau contenant les dates de début et de fin d’une
interruption, par ordre chronologique. De la même manière que le DSLAAdmin rend les
accords persistants, le DisruptionsLogger sauvegarde les historiques d’interruptions, et
peut pour ceci reposer sur des services de journalisation standards (LogService) ou de
persistance fournis par la plate-forme hôte. La sauvegarde des interruptions permet de
prendre en compte les interruptions passées d’un fournisseur malgré les arrêts possibles
de la plate-forme OSGi.
Dans le document
Politique de Liaison aux Services Intermittents dirigée par les Accords de Niveau de Service
(Page 146-149)