Supervision des services candidats

La supervision des services (on parle aussi de “monitoring”) est l’étape de notre approche par laquelle des informations non-fonctionnelles que l’on considère comme cruciales aux prises de décision

de liaison ultérieures sont recueillies et exposées. Il s’agit donc de répondre ici à deux questions diffuses concernant cette supervision : le “comment ?” puis le “quand ?”, et ce dans notre contexte SSOA à faible couplage.

5.5.1 Mise en œuvre de la supervision

Nous présentons ci-dessous trois alternatives concrètes pour la réalisation de la supervision au sein de la composition active de services :

1. Une participation volontaire des fournisseurs de services, où l’on dispose éventuellement d’un tiers de confiance. Dans ce cas de figure, ce sont alors les services eux-mêmes qui vont fournir en continu les valeurs courantes de chacune de leurs propriétés de QoS.

2. Une supervision réalisée au niveau de l’intergiciel SSOA et de son bus de services (dans le cadre

de SemEUsE, il s’agirait de Petals¹³), en supposant effectivement que le processus métier client

s’exécute sur le même bus que celui où les services candidats seront enregistrés. Les données ainsi recueillies pourraient aussi être capitalisées et partagées à plusieurs niveaux : par exemple entre les processus métiers qui s’exécutent sur un même bus, entre plusieurs clients ayant chacun plusieurs processus métiers à exécuter, entre de très nombreux processus métiers dans le cas d’un bus s’exécutant sur une grappe de machine de type “cloud”, etc.

3. Une supervision effectuée par le processus métier lui-même, qui accumule des données lors de chaque appel de services, en suivant donc une approche d’apprentissage en ligne. Il s’agit donc moins dans cette option de QoS courante que de valeurs résultants d’un calcul effectué à partir des valeurs obtenues depuis le début de l’exécution du processus.

Obtenir un visuel du sinistre 1 Obtenir un visuel du sinistre 1 Résolution = 1024x768 Supervision Résolution = 640x480 Résolution = 1920x1200 Publi. Publi. Publi. Requête de QoS

Figure 5.9 – Participation volontaire des drones à la supervision.

C’est la première des trois options qui a été retenue dans notre approche, elle est illustrée schéma-tiquement par la figure 5.9 où les drones rendent volontairement disponibles leurs valeurs courantes

de QoS en terme de résolution d’image, via un canevas de supervision, à partir duquel les valeurs courantes de QoS sont ensuite récupérées pour effectuer une décision de liaison de service. Il faut cependant noter qu’elles ne sont pas antinomiques et pourraient conjointement faire partie d’une approche plus globale, bien que probablement redondante, de la supervision. Cette participation vo-lontaire est viable car nous partons du constat qu’un service donné aura avantage à publier sa Qualité de Service courante si cette dernière est bien meilleure que celle portée comme extremum dans son contrat non-fonctionnel précédemment annoncé. Ce qui sera le cas si le fournisseur a pris de grandes marges dans le contrat afin de ne pas avoir à payer de pénalités en cas de violation des garanties, mais qu’il fourni habituellement en pratique une bien meilleure QoS. Dans ce contexte, concurrence entre services aidant, ses semblables suivront si les consommateurs de services plébiscitent les fournisseurs qui fournissent ces valeurs courantes.

Bien que cette option puisse malgré-tout sembler avant-gardiste compte tenu de l’état actuel du déploiement de ce type de technologies dans le monde de l’entreprise, elle risque de devenir inévitable, à plus ou moins courte échéance, si les besoins actuels et bien réels en termes de certification des activités liées aux technologies non-fonctionnelles de services se concrétisent au niveau industriel. De fait, quand les fournisseurs de services chercherons à obtenir des certifications de type ISO-900X, fort est à parier que la possibilité de vérifier la qualité du service rendu (ou perçu) fera partie intégrante de ces certifications ; la capacité à s’auto-évaluer en est le plus souvent une caractéristique essentielle. Ce modèle économique, fondé sur la crédibilité des fournisseurs de services, ne peut alors que renforcer la pertinence de la participation volontaire de ces derniers au processus de supervision. Ainsi, une hypothèse centrale à notre approche est que les contrats non-fonctionnels, “signés” par les fournisseurs de services suite aux négociations effectuées lors du précédent filtrage, expriment les propriétés de QoS qu’il est possible de superviser tout au long de l’existence des services. Cependant, si la supervision des services est effectivement un moyen particulièrement adapté à l’obtention des valeurs pertinentes de QoS pour la prise de décision de liaison, une alternative sensiblement dégradée consisterait à toujours considérer lors de la décision la “pire” valeur possible de QoS selon les bornes définies dans le contrat statique. Cette approche pessimiste, qui n’a pas été retenue pour nos travaux, pourrait néanmoins y être utilisée comme mécanisme de secours en cas de défaillance technique du canevas de supervision.

5.5.2 Un ensemble de contraintes spécifiques

L’approche générale pour la supervision des services étant fixée, il subsiste un ensemble de contraintes, propre à la prise de décision dynamique, qui s’y applique. Ces contraintes portent sur : – la cohérence des données. En effet, la comparaison entre plusieurs services étant le plus souvent effectuée sur la base des valeurs courantes de multiples propriétés de QoS, les données relevées doivent exhiber un certain degré de cohérence sur le plan temporel. Cette cohérence doit se retrouver aussi bien entre les différentes propriétés d’un même service (cohérence interne), qu’entre les services considérés (cohérence externe). Par exemple, selon notre cas d’utilisation, on doit être en mesure d’obtenir à tout moment la valeur courante de la bande passante B et de la résolution d’image R d’un drone de surveillance donné. Lors de la comparaison entre drones dans l’optique d’une décision de liaison, il s’agit alors d’une part de ne pas mettre sur

un pied d’égalité deux drones D₁ et D₂ dont le degré d’obsolescence des valeurs obtenues ne

que D₂, mais que B₂, bien qu’inférieure, est beaucoup plus récente donc pertinente pour la décision) ; et, d’autre part, de s’assurer de la proximité temporelle interne des valeurs sur B

et R au sein de D₁, D₂ et tous les autres drones ;

– la flexibilité de l’accès aux données. Pour une même propriété de QoS, chaque fournisseur de services peut utiliser son propre “vocabulaire”, matérialisé dans le contexte SSOA par des concepts ontologiques (voir des ontologies) distincts, ou ses propres unités de mesure. Nous avançons que c’est au canevas de supervision de gérer ces discordances, tout en les masquant à ses clients (en l’occurrence le processus de composition active de services). Toujours selon notre cas d’utilisation, de telles différences subtiles pourraient apparaître entre les offres de services issues des pompiers et des gendarmes pour un même type de matériel : par exemple, des camions citernes dont la vitesse est caractérisée par le concept ontologique Vitesse et

mesurée en Km/h d’un côté, et le concept Speed en mph¹⁴ de l’autre.

– la performance dans l’accès aux données. Le processus décisionnel, client des valeurs fournies par le canevas de supervision, ne doit pas pâtir d’éventuels délais dans l’accès au valeurs de QoS. Ces délais proviennent essentiellement des contraintes techniques liées à la transmission des valeurs numériques depuis les services ainsi qu’à leur éventuelle conversion. Or, dans les cas usuels, les délais de transmission vers les clients sont proportionnellement importants (par exemple de l’ordre de plusieurs milli-secondes) par rapport à celui de la décision effectuée en local.

Le canevas de supervision M4ABP (“Monitoring for Adaptive Business Process”), mis au point par Le Duc et al. [Le Duc et al., 2009] dans le cadre du projet SemEUsE et de travaux connexes à cette thèse apporte de nombreux éléments de réponse à ces contraintes en mettant en œuvre différentes techniques telles la mise en cache des valeurs de QoS obtenues des services pour en augmenter la performance d’accès, ainsi que leur marquage temporel (“timestamp”) pour assurer une certaine cohérence temporelle des données. Il repose par ailleurs sur l’obtention des valeurs courantes de QoS que chaque service s’engage à fournir volontairement au travers d’une interface dédiée. C’est ce canevas qui sera intégré à l’implantation de la composition active des services.

5.5.3 Intégration au processus de composition active

Si la réponse aux contraintes précédemment définies est en partie fournie par l’implantation du canevas de supervision, son utilisation habile et ciblée constitue un second vecteur d’optimisation en termes de performance globale du processus de composition de services. En effet, du point de vue externe de ce dernier, les interactions avec le canevas de supervision vont être séparées en deux étapes distinctes :

– Tout d’abord l’initialisation de la supervision, qui entraîne son déclenchement. Elle doit être effectuée le plus tôt possible (en amont de l’exécution du processus métier) afin de ne pas en influencer le bon déroulement.

– Vient ensuite le recueil des informations de supervision en tant que telles (c’est-à-dire celui des valeurs courantes de QoS des services supervisés) qui sera effectué dans cette approche au moment ultime de la sélection de service avant invocation, de manière à obtenir les valeurs de QoS les plus fraîches possible (cf. section 5.6).

P3 (S1) P2 (S1) Supervision (initialisation) 2 S1 S3 Contrats non-fonctionnels statique P1 (S1) P3 (S2) P2 (S2) P1 (S2) Sondes ("Probes") déployées sur les services

utilisées dynami-quement

Figure 5.10 – Initialisation de la supervision des services ayant été filtrés.

Nous proposons donc, comme optimisation dans l’usage du canevas, d’effectuer son initialisation de manière précoce, dans la foulée de l’étape de filtrage des services, ce qui permet aussi de la restreindre aux seuls services exhibant les propriétés non-fonctionnelles contractuelles nécessaires. L’initialisation et le déclenchement de la supervision seront donc, tout comme le filtrage, effectués de manière statique au chargement du processus (en t2 sur la figure 5.8), avant l’exécution de sa partie métier.

Par la suite, le coût du recueil des informations non-fonctionnelles est en grande partie minimisé par ce déclenchement préalable en t2 du canevas de supervision. En effet, à sa suite, des sondes ont été déployées sur la base des informations techniques contenues dans les contrats non-fonctionnels, tel qu’illustré sur la figure 5.10. Le rôle de ces sondes est de s’abonner aux interfaces de super-visions locales à chaque service de manière à faire remonter, de manière asynchrone à l’exécution du processus métier, les valeurs courantes de Qualité de Service pour consultation ultérieure. Cette asynchronicité permet de s’affranchir, lors de la prise de décision de liaison dynamique à l’exécution du processus, des délais relatifs à la demande, puis l’obtention via le réseau des valeurs courantes de QoS des services.