• Aucun résultat trouvé

Méthodologie générale pour la composition de services

III.3 Composition de services (n-m)

III.3.1 Méthodologie générale pour la composition de services

Basé sur l’approche de sélection de services présenté précédemment, le mécanisme de réconciliation proposé dans ce manuscrit vise à améliorer les résultats fournis à l’uti- lisateur grâce à l’étude successive de profils sémantiques complémentaires.

III.3.1.1 Présentation de la méthodologie

Notre mécanisme de composition de services est basé sur une utilisation successive de la réconciliation « 1-1 » sur un ensemble de combinaisons de services potentiels. Le temps de calcul nécessaire à l’obtention de résultats de composition satisfaisants est donc logiquement plus élevé que pour la sélection de services. De plus, le choix réalisé en Section II.3.2 d’utiliser des méta-modèles de description de services utilisant l’approche ascendante implique que l’on dispose d’une description sémantique réduite au minimum, en particulier sur le contexte et le comportement de ceux-ci (pré-requis, effets). La pro- babilité de proposer un ensemble de services répondant parfaitement au besoin risque donc rapidement d’augmenter avec l’ajout de nouveaux services. Pour ces deux raisons, il est préférable de privilégier la réconciliation des plus petits ensembles possibles. Notre méthodologie de réconciliation de services, incluant les mécanismes de sélection et la composition de services, suit donc logiquement le processus suivant (voir Figure III.12) : 1. On procède à la sélection de services (réconciliation « 1-1 ») sur chacune des acti-

vités du processus.

2. Pour toutes les activités non couvertes par un service, ou du moins dont aucun service proposé n’atteint le seuil imposé par l’utilisateur, on procède à une compo- sition de service « 1-n ». On recherche donc à cette étape un ensemble de n services répondant au besoin exprimé dans la description sémantique de l’activité.

3. S’il reste des activités non satisfaites, on s’intéresse à la réconciliation « n-m » en tentant cette fois de combiner les attentes métiers d’activités consécutives afin de trouver un ensemble de services répondant au besoin de manière plus souple (i.e. en s’abstrayant des données attendues entre ces activités). S’il est nécessaire de

Chapitre III. Réconciliation de services

prendre en considération des activités déjà satisfaite lors des phases précédentes, nous chercherons à augmenter la satisfaction de l’ensemble (i.e. la moyenne des notes) et proposerons à l’utilisateur les différentes solutions.

4. Une fois toutes ces étapes réalisées, on transmet à l’utilisateur les résultats obtenus afin qu’il puisse les valider ou les invalider. Dans le cas où une ou plusieurs activités ne seraient toujours pas couvertes, plusieurs choix s’offrent à lui :

• Développer le service correspondant à l’activité et le lier manuellement à l’acti- vité (peu probable).

• Rechercher un nouveau partenaire prêt à intervenir dans la collaboration et possédant le service adéquate.

• Déclarer cette activité comme une activité métier, directement gérée par un humain lors de l’exécution. On génère alors un service graphique contenant le formulaire nécessaire au bon déroulement du processus (i.e. présentant à l’utili- sateur les données dont il a besoin pour produire les données attendues en retour par le processus). Composition de services Sélection de services Com position 1- n Couverture satisfaisante des activités ? Validation de l'utilisateur et décision

pour les activités non couvertes Couverture satisfaisante des activités ? Com position n- m Sélection de services Com position 1- n Couverture satisfaisante des activités ? Validation de l'utilisateur et décision

pour les activités non couvertes Couverture satisfaisante des activités ? Com position n- m Oui No n No n Oui No n No n oui oui Nicolas Boissel 1 of 1 07.10.2012

Figure III.12 – Méthodologie pour la composition de services

Le but principal de la composition de services, que ce soit pour la réconciliation d’une activité (« 1-n ») ou d’un groupe d’activités (« n-m »), est de proposer un ou plusieurs ensembles de services répondant au besoin. Les services proposés peuvent cependant être dépendants les uns des autres (i.e. un service attend une information qui est fournie par un autre). Il est donc nécessaire d’étudier ces dépendances afin de proposer à l’utilisateur une solution viable, composée de services dans le bon ordre. Cet ordonnancement doit permettre l’exécution de ces services de la manière la plus efficace possible tout en s’assurant que le sous-processus généré puisse être exécuté sans blocage. Pour cela, une étude du graphe d’interdépendance entre ces services est proposée dans chacune de ces activités.

Afin d’accélérer le processus de composition, un mécanisme de réutilisation de pat- terns a aussi été intégré à la composition de services. La base de patterns mise en place comprend les compositions réalisées avec succès lors des réconciliations précédentes ainsi que ceux prévus dés la conception des services (e.g. dans les descriptions de services WSMO-Lite).

III.3.1.2 Limitation de la combinatoire

Le mécanisme de réconciliation « n-m » proposé ici propose de tester différentes combinaisons de services possibles afin de trouver le résultat le plus adapté au besoin de l’utilisateur. Chaque réconciliation d’activité(s) va demander plusieurs appels au mo- teur de sélection de services, chacun s’appliquant sur l’ensemble des services concernés. Les temps de calculs pour ce mécanisme peut alors rapidement devenir un problème, principalement sur les systèmes importants ou si le nombre et la taille des processus col- laboratifs en jeu est élevé. Afin de minimiser le temps de calcul, nous pouvons agir sur deux points en dehors des performances mêmes du moteur (traitées en Section V.1.3) : • Le nombre de composition à opérer, qui est déterminé d’une part par le nombre d’activités n’ayant pas trouvé de correspondance satisfaisante et d’autre part par les associations possibles d’activités à étudier (correspondant au « n » du « n-m »). • Le nombre de services à traiter à chaque sélection de services, directement pro- portionnel au temps de calcul. Ce nombre correspond au nombre de services mis à disposition par les partenaires et pouvant être utilisés pour cette réconciliation.

Réduction du nombre de compositions. Si l’on souhaite tester l’ensemble des com-

binaisons possibles sans prendre en compte l’ordre de ces activités, cela revient à réaliser 2p−1 compositions, avec p le nombre d’activités dans notre processus. Ce nombre de com- positions est calculée à partir du coefficient binomial (Ckp = pk

= k!(p−k)!p! ) qui permet de calculer le nombre de combinaisons possibles de k éléments parmi p. Dans notre cas, nous souhaitons le calculer pour tous les k, de 1 à p. Cela donne doncPp

k=1C p

k = (2p−1)

possibilités. Cependant, ce nombre ne prend pas en compte la logique même du processus collaboratif, qui nous permet de limiter grandement le nombre de calculs. En effet, bien qu’il soit toujours possible de faire une composition « 1-n » (ce qui représente p com- positions), toutes les activités ne peuvent pas être combinées pour une réconciliation « n-m ».

Tout d’abord, l’ordonnancement des activités dans le processus ne permet pas la prise en compte de n’importe quel groupe d’activités. En effet, tenter de réconcilier des activités non consécutives dans le processus n’est pas logique d’un point de vue métier. Les activités doivent en effet être réalisées suivant une logique définie. Bien qu’il soit possible de trouver un ensemble de services répondant au besoin fonctionnel de deux activités distantes l’une de l’autre, la logique métier ne le permet pas.

Ensuite, l’utilisation d’opérateurs logiques (représentés sous la forme de gateways dans notre cas) rend difficile, voire impossible, la réconciliation de groupes les contenant. En effet, les conditions exprimées au sein de ces opérateurs logiques en BPMN ne sont pas standardisées et donc peu exploitables. De plus, la description sémantique des services ne permet pas une représentation de leur logique interne, qui est à la discrétion du développeur et qui peut être différente pour deux implémentations de la même opération. Cela implique donc qu’aucune correspondance entre les opérateurs logiques du processus et ceux des services ne peut être réalisée. Tenter de réconcilier deux activités séparées par un opérateur logique ne représente donc aucun apport par rapport à leur réconciliation

Chapitre III. Réconciliation de services

une à une. Seule l’étude d’activités en séquence a donc un intérêt.

Enfin, chaque activité du processus collaboratif est assignée à un partenaire, respon- sable de sa réalisation. Deux activités consécutives assignées à deux partenaires différents ne doivent donc pas être réconciliées ensemble, leur exécution devant être réalisées sur des systèmes (et donc des services) distincts.

Ces trois propriétés limitent donc les compositions à étudier aux activités seules (réconciliation « 1-n ») ainsi qu’aux activités consécutives en séquences réalisées par un même partenaire.

Figure III.13 – Détermination des associations possibles d’activités métier

Exemple : La Figure III.13 représente un exemple abstrait de processus collaboratif vu

uniquement sous la forme d’un médiateur. Deux partenaires sont engagées dans cette col- laboration, chacun représenté par une couleur différente. Si on applique à ce processus les trois règles proposées ci-dessus, on remarque que seules 13 compositions de services sont à réaliser (une pour chaque activité plus les deux groupes en pointillés). Si nous avions décidé de ne pas les prendre en compte, nous aurions eu 211− 1 = 2047 combinaisons

possibles à calculer, soit plus de 150 fois plus.

Réduction du nombre de services concernés. Chaque composition de services

fait appel plusieurs fois au mécanisme de sélection de services (présenté en Section III.2) qui compare le profil fourni, généralement généré depuis les informations sémantiques de l’activité recherchée, avec tous ceux correspondant aux services potentiels. Or, la liste de ces services potentiels peut être réduite simplement à l’aide de quelques critères.

Comme nous l’avons dit précédemment, chaque activité est réalisée par un partenaire de la collaboration. Il n’est donc pas nécessaire de réaliser les réconciliations de services sur tous les services disponibles mais seulement sur ceux du partenaire cible. Chaque service étant associé au partenaire correspondant au moment de sa déclaration dans notre annuaire, cette information permet un filtrage simple et efficace des services étudiés. On peut ajouter à cette liste de services potentiels ceux fournis par le médiateur, qui peut mettre à disposition un ensemble de fonctionnalités génériques aux collaborateur.

La liste des services potentiels peut aussi être réduite rapidement suivant des cri- tères non-fonctionnels. En effet, si une activité métier nécessite certaines caractéristiques non-fonctionnelles (e.g. un temps d’exécution ou un taux de réponse spécifique), il est judicieux de ne prendre seulement en considération les services y répondant. Ces cri- tères syntaxiques, standardisés au niveau des services, peuvent alors servir de filtre. Une première étude a été réalisée au cours de cette thèse [Boissel-Dallier et al., 2011]. Cette

étude a permis l’annotation sémantique des polices de services (permettant d’exprimer les aspects non-fonctionnels des services) sans pour autant permettre l’apport de cette connaissance au niveau métier. Bien que la sémantisation de ces modèles amène une certaine souplesse dans la réconciliation des polices de service au niveau technique, elle n’apporte aucune plus-value à la transformation de modèles métier vers technique. La prise en compte de ces aspects non-fonctionnels étant un sujet complexe, un sujet de thèse dédié a été initié [Zribi et al., 2012].

La réduction de cette liste de services cibles permet de diminuer le temps de calcul de chaque sélection de services dans chacune des compositions. Pour l’instant, seul le premier filtre (par partenaire) est utilisé dans notre moteur de réconciliation. Le filtre non-fonctionnel est encore en cours d’étude.

III.3.1.3 Des patterns réutilisables

La composition de services se base sur nos algorithmes de réconciliation de services et de données dans le but de fournir à l’utilisateur le meilleur résultat possible en un minimum de temps. Afin d’accélérer encore ce processus et d’en améliorer les résultats, il peut être intéressant de réutiliser les patterns qui ont fait leur preuve (i.e. qui ont été déterminés et exécutés avec succès) ainsi que ceux prévus lors de la conception des services (comme on a pu le voir dans la présentation de WSMO-Lite).

I1 I2 O 2 Internal  behaviour   O1 New Process Op3 Op7 Op12 XSLT

Figure III.14 – Représentation possible d’un pattern

Chacun de ces motifs de conception associe au profil sémantique équivalent une description technique des services et des transformations de données utilisée afin d’en faciliter l’utilisation (voir Figure III.14). Ces profils proviennent des compositions « 1-n » et « n-m » précédemment découvertes, validées par l’utilisateur et exécutés avec succès dans des processus collaboratifs antérieurs ou sont extraits des descriptions WSMO-Lite qui permettent aux concepteurs de service d’indiquer les enchainements d’opérations prévues [Vitvar et al., 2008].

Ces motifs de conception étant déjà conçu et validés, soit par leur utilisation préalable

Chapitre III. Réconciliation de services

soit par le concepteur du service, ils pourront être testés an amont de toute composition à l’aide du mécanisme de sélection de services au même titre que n’importe quel service disposant d’un profil sémantique.