Les services abstraits

2.3.2.1 Définition et motivation

Nous définissons un service abstrait en tant que service qui a une description générique et réutilisable. L’idée derrière les services abstraits, est de faciliter la sélection et la sition des services. Ils peuvent aider à améliorer les performances et l’efficacité des compo-siteurs en diminuant le nombre de services. Un service abstrait peut être considéré comme un niveau d’abstraction intermédiaire dont le but est d’établir un pont entre les intentions des utilisateurs et les services concrets potentiels qui permettent de les réaliser. Cela rédui-rait la difficulté et le coût élevé de la tâche de la découverte et de sélection des services concrets qui couvrent les intentions des utilisateurs. Puisqu’un même service abstrait est of-fert à plusieurs circonstances correspondantes à différents utilisateurs, différentes instances

de ce service peuvent être obtenues à différents niveaux de granularité allant des proprié-tés fonctionnelles des services jusqu’aux propriéproprié-tés liées à l’exécution. Les services abstraits proposés sont motivés par les principaux aspects suivants :

— Le besoin de faciliter la mise en correspondance entre les intentions des utilisateurs et les services concrets disponibles.

— Le besoin de flexibilité dans la composition de services pour satisfaire les intentions particulières.

— L’importance de la réutilisabilité de services.

Les services abstraits sont composés pour construire des processus complexes. A priori, dans notre travail, les services abstraits sont des entités prédéfinies fournies au moment de la conception par des experts de domaine. Néanmoins, ces services sont amenés à évoluer dynamiquement à travers des méthodes d’apprentissage ou de raisonnement par cas par exemple.

L’utilisation des services abstraits présente les avantages suivants :

— Les services abstraits peuvent être définis sans connaître l’implémentation des ser-vices web car l’implémentation ne modifie pas le service, même en cas de change-ment d’interface.

— Pendant son cycle de vie, un service abstrait peut être attaché à plusieurs services web.

— La distance sémantique entre les services abstraits et les intentions est plus stable que la distance entre les intentions et les services web. En effet, les services web changent plus fréquemment que les services abstraits. Ceci provoque un re-calcul de la distance plus fréquemment dans le cas de services web.

— Un service abstrait présente un fragment de processus qui peut être utilisé par plu-sieurs compositions de services. Ainsi, un service abstrait peut encapsuler des struc-tures de contrôle complexes qui ne peuvent pas être générées automatiquement. Par conséquent, l’utilisation des services abstraits facilite la génération du schéma de composition au moment de l’exécution.

2.3.2.2 Spécification des services abstraits

Le service abstrait est décrit par son profil qui fournit les informations nécessaires pour décrire la fonctionnalité du service, notamment la fonctionnalité du service et l’ensemble des inputs et outputs. Comme [Ye et Bin, 2006], nous décrivons la fonctionnalité d’un ser-vice en tant qu’une action et un objet (l’objet de l’action). Par exemple, la fonctionnalité d’un

service qui permet la réservation d’un hôtel peut être spécifiée comme {réserver, hôtel}. Le service abstrait est composé d’une ou plusieurs activités. Un service abstrait est associé avec un type de service qui peut être atomique ou composite. Chaque service a une ou plusieurs activités qui sont utilisées pour satisfaire la fonctionnalité du service abstrait. La manière dont un service abstrait est constitué d’activités est en relation avec le type du service abs-trait. Si le service abstrait est de type atomique, il est constitué d’une seule activité. Il est considéré comme un service opérationnel car il peut être directement implémenté par un service web concret. Si le service est composite, le service abstrait est constitué de plusieurs activités. L’exécution de ces activités peut être en séquence (ordre particulier) ou en parallèle (sans ordre précis). Par ailleurs, un service abstrait composite peut représenter dans certains cas un service conditionnel qui propose des alternatives pour satisfaire sa fonctionnalité. L’introduction de la variabilité dans la conception du service abstrait est justifiée par le be-soin d’introduire de la flexibilité dans la réalisation des fonctionnalités et de l’adaptabilité dans le processus de composition de service. Au moment de la composition, une activité est sélectionnée en fonction des informations fournies par la spécification des intentions et les informations du contexte. Dans ce cas, des règles sont utilisées pour guider la sélection de l’activité adéquate.

2.3.2.3 Mise en œuvre des services abstraits avec OWL-S

Bien que OWL-S et la structure de son ontologie supportent les mécanismes d’abstrac-tion pour représenter les services, OWL-S se focalise principalement sur la définid’abstrac-tion des services web concrets. Chaque service OWL-S est associé soit à un service Web physique ou à une composition fixe d’un ensemble de services Web concrets physiques, ce qui reste en-core un seul service web concret vu de l’extérieur. Toutes les classes OWL-S, tels queProfile,

ProcessetGrounding, contiennent différentes informations sur le service concret. En réalité,

un service abstrait est aussi important qu’un service concret, et ceci est d’autant plus vrai si une ontologie de services est de taille importante. Un service abstrait généralement re-présente un ensemble de services concrets similaires, tandis qu’un service OWL-S concret correspond à un seul service Web concret.

Un service abstrait généralise les points communs d’un groupe de services concrets et fournit un certain niveau d’abstraction de ces services. Le langage OWL-S fournit des mé-canismes d’abstraction pour représenter les processus. En outre, il fournit de l’information sémantique afin que les services puissent être découverts et interagissent d’une manière au-tomatique. Pour ces raisons, nous avons exploité ce langage pour représenter et mettre en

œuvre nos services abstraits.

Nous considérons que le service abstrait est composé d’une partieProfile et une partie

Process. La partieProfiledécrit le nom, les entrées (inputs) et les sorties (outputs) du service

abstrait. Dans le Process de OWL-S, un service est modélisé comme un processus qui est classé comme un processus atomique, un processus simple, ou un processus composite. Un processus simple pourrait être réalisé par un processus atomique ou étendu à un processus composite. La partieProcessde notre service abstrait peut être mise en correspondance avec la partieProcessde OWL-S. Cependant, ceProcessne peut être qu’un processus atomique, ou un processus composite, comme le montre la figure 2.3. Dans ce dernier cas, le processus du service abstrait est composé d’autres sous-processus qui sont des processus simples. Leur composition peut être spécifiée en utilisant l’une des structures de contrôle tels quesequence

etif-then-else. Un processus simple peut servir comme une vue abstraite d’un processus

ato-mique ou composite afin qu’on puisse voir le même processus à partir d’angles différents. Les processus simples ne sont pas invocables et ne sont pas associés à un Grounding. Le service abstrait est donc conceptuellement similaire à une classe abstraite dans les langages de programmation orienté objet. Dans le cas où le service abstrait a un processus atomique, le service est associé à un ou plusieurs services concrets OWL-S à travers la relation

imple-mentableBy. L’implémentation de chaque service concret OWL-S et les détails pour accéder

à et invoquer le service réel sont spécifiés par la partieGrounding. Cet ensemble de services concrets OWL-S constitue une collection de services web ayant une fonctionnalité commune et présentant des propriétés non fonctionnelles différentes (par exemple : fournisseurs diffé-rents, valeurs de QoS différentes, etc). Ces propriétés non fonctionnelles sont spécifiées dans la partie profil de chaque service concret. Au moment de l’exécution, le service candidat ap-proprié est sélectionné et invoqué. Pour les environnements et les frameworks qui exigent une adaptation ou une auto-réparation au moment de l’exécution, l’ensemble des services candidats peuvent préparer les services pour le remplacement ou la substitution.