contextuel des applications
3.3.2 D´ ependances de services et de composants
D´efinition Une d´ependance est une relation mettant en jeu deux ou plusieurs ´el´ements, et o`u
le changement d’´etat d’un ou plusieurs de ces ´el´ements peut g´en´erer le changement d’´etat des autres ´el´ements. Les ´el´ements de la d´ependance peuvent ˆetre abstraits ou concrets. [60]
AxSeL introduit le niveau de d´ependances entre services dans le mod`ele de services
compo-sants. La d´ependance entre services peut ˆetre assimil´ee `a un contrat ´etabli entre deux services
o`u un service fournit une fonctionalit´e `a un autre. La figure 3.11 pr´esente une application
AxSeL. Nous mettons en ´evidence les diff´erentes d´ependances possibles, et distinguons entre le niveau des composants et le niveau des services. Cette distinction nous permet de g´erer ind´ependamment les services des composants en consid´erant leurs caract´eristiques respectives. Les services fournissent une vue de haut niveau, il est possible de leur assigner des propri´et´es non fonctionnelles telles que la confiance, la s´ecurit´e, la qualit´e de service, alors que les com-posants sont imm´ediatement li´es au d´eploiement sur la plate-forme et peuvent d´ependre de propri´et´es mat´erielles telles que la m´emoire ou l’usage processeur. Ceci nous permet ´egalement
AxSel, un intergiciel pour le d´eploiement autonome et contextuel des applications
orient´ees services 76
de porter une vue orient´ee service sans nous soucier des composants les exportant ni des d´etails d’impl´ementation.
Fig. 3.11 – Illustration d’un exemple d’application orient´ee service composant
Dans la figure 3.12 nous illustrons la classification de Keller et al. [84] qui repr´esentent les attributs des d´ependances sur six axes orthogonaux. Nous nous inspirons de cette classification pour pr´esenter chaque axe et l’´etendre avec nos propres attributs. Les attributs entour´es sont consid´er´es par notre approche.
variable
d y n a m i c
adapté de Classification and Computation of Dependencies for Distributed Management ISCC 2000
O R
dependency equivalence
A N D
Fig. 3.12 – Extension de la classification des d´ependances de [84]
Description de services AxSeL suppose qu’une description de service doit inclure les
d´ependances de celui-ci. Cette connaissance suppl´ementaire nous permet de structurer les ap-plications sans nous soucier des impl´ementations sous-jacentes et de remplacer ´egalement un service par un autre. L’expressivit´e d’un composant est fonctionnelle mais tr`es limit´ee, en effet, il n’est pas obligatoire au niveau composant de pr´eciser les services fournis et surtout requis. Sans la pr´ecision des d´ependances dans la description du service, notre connaissance se limiterait au niveau impl´ementation et d´eploiement.
Type de composant (Component type) Nous consid´erons principalement les
d´ependances entre entit´es logicielles : services et composants. Le contexte environnant peut aussi influencer le changement d’´etat des services et des composants et peut ˆetre consid´er´e comme une d´ependance. Le d´etail de cette d´ependance fait l’objet de la section 3.4.
Type de d´ependance (Space/locality/domain) Dans [84], les auteurs distinguent entre
d´ependances fonctionnelles et d´ependances structurelles. Les premi`eres sont pr´ecis´ees lors de la conception et du d´eveloppement d’un composant, les secondes apparaissent au moment du d´eploiement et de l’installation. Les d´ependances entre services et composants peuvent ˆetre de deux types, si elles sont pr´ecis´ees au d´eveloppement elles sont fonctionnelles, sinon elles apparaissent dans la phase de d´eploiement et sont structurelles. Les d´ependances entre services
sont ´egalement structurelles et sont visibles `a la phase d’ex´ecution. Ainsi nous distinguons entre
d´ependances de d´eploiement et d’ex´ecution. La satisfaction des d´ependances de d´eploiement est requise par l’intergiciel lors du d´eploiement du composant.
Obligatoire ou optionnelle (Dependency strength) La d´ependance obligatoire doit ˆetre satisfaite pour assurer le fonctionnement de l’application ou du service, alors qu’il n’est pas obli-gatoire de satisfaire une d´ependance optionnelle. Celle-ci peut apporter une am´elioration par une fonctionalit´e suppl´ementaire par exemple. Ces propri´et´es peuvent changer dans le temps, il est int´eressant pour l’utilisateur de satisfaire une d´ependance optionnelle annot´ee par un
coef-ficient fort. En effet, AxSeL assigne `a chaque d´ependance une caract´eristique non fonctionnelle
qui s’incr´emente avec la fr´equence d’usage des ´el´ements qui la composent. A travers cela, il est possible d’´evaluer des statistiques d’usage d’un service donn´e et de pr´edire des comportements
de chargement `a l’avance.
D´eterministe ou plurielle (Dependency equivalence) Nous ajoutons cet axe `a la figure
initiale. AxSeL fournit un mod`ele de d´ependances bas´e sur la collecte de l’ensemble des four-nisseurs de services susceptibles de satisfaire une d´ependance. Ainsi, une d´ependance AxSeL
peut ˆetre ´equivalente avec une autre d´ependance, dans le cas o`u un service est fourni avec
deux versions diff´erentes par exemple. Nous reposons sur une hypoth`ese simple d’´equivalence de sp´ecification. Deux services sont ´equivalents s’ils ont le mˆeme nom dans la description de ser-vices. D’autres travaux tels que [82] ont propos´e des formalismes d’´evaluation des ´equivalences entre services.
Formalisme de la d´ependance (Dependency formalization) Plusieurs travaux se sont
int´eress´es `a la repr´esentation des d´ependances logicielles comme [60] o`u les auteurs exploitent
les graphes conceptuels ou UML [45] qui est un langage formel. AxSeL repose sur un formalisme orient´e objet et bas´e sur les graphes pour garder en m´emoire la structure globale de d´ependances d’une application donn´ee, le d´etail est donn´e en section 3.3.3. Ce formalisme offre la possibilit´e de r´eutilisation et d’´evolution du mod`ele de d´ependances, et permet ´egalement d’observer sur l’´echelle temporelle les variations possibles d’une application en vue de faire des statistiques d’utilisation et de pr´edire les services favoris d’un utilisateur.
Politique de liaison (Dependency criticality) Il est possible de retrouver plusieurs types de politiques de liaison comme les d´ependances statiques et les d´ependances dynamiques. Les premi`eres sont insatisfaites lorsque le fournisseur de services disparait. Les d´ependances dy-namiques se basent sur un m´ecanisme de recherche d’un fournisseur similaire lors d’une rup-ture de liaison. L’insatisfaction d’une d´ependance influence l’´etat de l’instance des services et
AxSel, un intergiciel pour le d´eploiement autonome et contextuel des applications
orient´ees services 78
composants lui sont relatifs. Lors d’une rupture d’une d´ependance, AxSeL cherche d’´eventuels fournisseurs de service similaires.
Instances de composants (Component activity) Les ´etats d’une instance de composant
d´ependent ´etroitement du niveau de satisfaction de leurs d´ependances. Elles sont pr´esent´es
dans la figure 3.13. Le composant passe `a l’´etat install´e si toutes ses d´ependances obligatoires
sont satisfaites. Il devient ensuite actif lorsqu’il est lanc´e. D`es son activation l’instance de composant enregistre les services qu’elle d´esire fournir dans le contexte. Dans cet ´etat il est
possible de passer `a l’´etat inactif ou d´esinstall´e. La mise `a jour et la d´esinstallation de l’instance
sont possibles quand l’instance est active ou inactive. Quand une instance de composant est d´esinstall´ee les services qu’elle a auparavant enregistr´es sont retir´es du contexte.
installé
[dépendances OK] installer
lancer arrêter
inactif désinstaller
m e t t r e à j o u r [ s i n o n ]
m e t t r e à j o u r
entry/stopper les services do/retirer les services du contexte exit/retirer instance de la plate-forme
désinstallé désinstaller
m e t t r e à j o u r
entry/créer contexte do/publier les services
do/gérer les dépendances contextuelles exit/attendre action
actif
Fig.3.13 – Diagramme des ´etats transitions d’un composant
Conclusion Nous avons pr´esent´e s´epar´ement les concepts de services et de composants. En-suite, nous les avons r´euni dans un mod`ele unique de service composant qui associe l’aspect d’ex´ecution avec celui du d´eploiement. Enfin, nous avons d´etaill´e le paradigme de d´ependance entre services et composants et l’avons expos´e sous plusieurs aspects. Dans ce qui suit, nous introduisons la notion d’application et proposons notre repr´esentation expressive et flexible.