Modélisation formelle de OWL-S

Nous passons à la modélisation interne des Process Models non moins ambitieux ni moins complexe. Le projet des Web services sémantiques est d’ajouter de la sémantique aux Web services, comme nous l’avons précédemment mentionné. Des Web services sémantiques se-raient intuitivement des programmes dont les effets sur leur environnement sese-raient connus et dont les données manipulées possèderaient aussi une sémantique.

Afin de modéliser, la représentation interne du Process Model OWL-S nous permettant de réduire le temps d’exécution, nous faisons appel aux théories de graphes et matrices. Mais avant cela revenant sur ce qu’est OWL-S. L’OWL-S est un langage permettant de décrire les services Web de façon non ambiguë et interprétable par des programmes. Ce langage est basé sur le langage d’ontologie du Web (OWL). OWL-S est aussi une ontologie OWL particulière. OWL-S s’applique à accomplir la composition automatique des services Web. L’accomplissement d’une tâche complexe implique la sélection, la composition automatique des services Web. Par exemple, l’utilisateur peut vouloir faire tout le nécessaire pour son voyage à une conférence. Il veut acheter un billet mais aussi il veut réserver un hôtel proche du lieu de la conférence. Il peut également ajouter des contraintes de coût minimal. Afin qu’un agent puisse exécuter ce type de tâche, OWL-S fournit une spécification des pré-requis et des conséquences de l’exécution de chaque service individuel ainsi qu’un langage pour décrire les services composés et le flux de données. Pour atteindre ces objectifs, OWL-S définit une ontologie supérieure pour la description, l’invocation et la composition des services Web. Celle-ci est présentée dans ce qui suit L’ontologie supérieure d’OWL-S. La structuration de l’ontologie supérieure de OWL-S est motivée par la nécessité de fournir trois types d’information essentiels pour un service, à savoir :

— Comment utilisons-nous le service : Cette information est fournie dans le Service Model qui est utilisé pour, entre autres, composer les services. OWL-S modélise les services en tant que processus et celui-ci est défini par ses entrées/sorties. Trois types de

processus existent : les processus atomiques (AtomicProcess ), simples ( SimpleProcess ) et composites (CompositeProcess ). Un processus atomique représente le niveau le plus fin pour un processus et correspond à une action que le service peut effectuer en une seule interaction avec le client. Les processus composites sont décomposables en d’autres processus (composés ou non) ; leur décomposition peut être spécifiée en utilisant un ensemble de structures de contrôles tels que : Sequence , Split , If-Then-Else etc... Un processus atomique est utilisé pour fournir une vue d’un processus atomique ou une représentation simplifiée d’un processus composite.

Le Service Profile fournit des informations sur le domaine d’application du service Web. Chaque service Web est rangé dans une taxonomie facilitant la recherche du service Web pour les clients potentiels. Le Service Profile fournit également des éléments sur les conditions d’exécution du service telles que les pré-conditions et les effets du service Web au sens de OWL-S, ainsi que la description des entrées/sorties. L’ensemble de ces conditions d’exécution est proche de l’ensemble des pré-conditions et post-conditions de la planification. De plus, ces informations sont liées au Service Model. Ce dernier décrit les fonctionnements des services Web en les décomposant en Processus atomique, Processus simple ou Processus composite. Les Processus atomiques correspondent à des actions qu’un service Web peut effectuer. Les Processus atomiques ne comportent pas de sous-processus et n’exécutent qu’une seule étape consistant à interroger un service Web. Ils prennent un message d’entrée puis font quelque chose et renvoient un message. Pour chaque Processus atomique, le service Web correspondant doit être défini dans le ServiceGrounding. Les Processus simple ne peuvent pas être appelés directement comme les Processus atomique et ne sont pas associés à des services Web dans le ServiceGrounding. En revanche, ils sont vus comme des procédures ne comportant qu’une seule étape et pouvant être réalisées par un Processus atomique ou un Processus composite. Ils sont en fait une vue alternative des deux autres procédures. Les structures de contrôle proposées par OWL-S sont :

— Séquence : la séquence est une liste de processus qui doivent être exécutés dans l’ordre ; — Split : appelle des sous-processus de façon concurrente ;

— Split+join : consiste à lancer différents processus de façon concurrente mais de les synchroniser en attendant que toutes les sous-procédures du split+join soient achevées pour les joindre ;

— Any-order : définit l’exécution d’un ensemble de tâches dans un ordre quelconque ; — Choice : le choix consiste à choisir entre plusieurs sous-procédures équivalentes ; — If-Then-Else : correspond au if-then-else habituel, c’est-à-dire si la condition du if est

réalisée, alors la sous-procédure du then est exécutée, sinon la sousprocédure du else est exécutée ;

— Iterate : boucle continuellement avant d’être interrompu par whileCondition ou until-Condition ;

— Repeat-While et Repeat-Until : sont des boucles conditionnelles qui répètent une sous-procédure tant que (Repeat-While) la condition de la boucle n’est pas satisfaite ou jusqu’à ce que (Repeat-Until) la condition de la boucle soit réalisée. Enfin le Service-Grounding définit les entrées et les sorties du service Web ainsi que les informations nécessaires pour appeler le service Web. Il permet de lier les AtomicProcess avec des

services Web existants.

Les composants principaux du modèle de processus (Process Model) sont l’ontologie du processus (Process Ontology) et l’ontologie de contrôle du processus (Process Control Onto-logy).

— L’ontologie du processus (Process Ontology). Cette ontologie décrit un service en termes de paramètres d’entrée et de sortie, de pré-conditions, des actions du service et dans le cas approprié, des sous-processus. Cette ontologie peut être utilisée afin de supporter l’invocation et la composition automatique de services Web.

— L’ontologie de contrôle du processus (Process Control Ontology). Cette ontologie de contrôle du processus décrit chaque processus comme étant un état, en prenant en compte son activation, son exécution et sa terminaison.

Le but est de stocker le flux de contrôle reliant les processus atomiques les uns aux autres. Pour cela, on va parser chaque Service Web touristique présents dans le registre UDDI afin d’extraire sa matrice d’adjacence en décomposant le Process Model. Ces matrices d’adjacence sont pré-calculés et stockés dans le même registre afin de pouvoir les invoquer à tout moment pur une éventuelle composition dynamique.

Sur cette base, la matrice d’adjacence AP M est une matrice booléenne carré qui repré-sente l’intra-dépendance des processus atomiques AP et ce en analysant le comportement complet du Process Model P M , AP M = [AP_ij]_{n timesn} où N désigne le nombre de pro-cessus atomiques explicités dans le process Model P M où ses éléments AP_ij ne peut être que "0" ou "1". Si deux sommets sont interconnectés par le constructeur de séquencement de

APi à AP_j i.e., seq (AP_i, AP_j) est définis dans E (PM), alors AP M [APi, APj] = 1 sinon

AP M [AP_i, AP_j] = 0.

La matrice d’adjacence AP M généré et stocker dans le registre UDDI est une matrice non diagonale dont tout les coefficients diagonaux sont nuls impliquant ainsi l’indépendance de chaque Processus atomique sur sur lui-même et formant une dépendance acyclique. Enfin les Processus composites sont des procédures complexes regroupant plusieurs étapes pour être réalisées et définis l’intra-dépendances entre le processus atomiques AP . Elles sont décomposables en Processus atomique, Processus simple et Processus composites.. Cette décomposition peut être spécifiée à l’aide de structures de contrôle telle que if-then-else ou les séquence

On s’intéresse principalement à l’interconnexion définie entre l’ensemble des processus atomiques présents dans chaque processus. Pour cela nous avons élaboré quelques règles nous permettant d’extraire l’intra-dépendance des processus atomiques pour chaque Process model en termes de structure de contrôle de séquence plus simple, concrètement, dans ce cas, on parse le Process Model de la racine des processus composites, puis on procède récursivement jusqu’à atteindre les processus atomiques, le résultat est stocké dans une matrice carré.

— Seq(S₁, S₂), L’ordre d’exécution des deux processus atomiques est séquentiel i.e., S₁ doit s’exécuter suivi de S₂impliquant que S₂est le successeur de S₁⇒ AP M [S₁, S2] = 1 — Seq(S₁, α(S₂, S₃)) = Seq(S₁, S₂) ∧ Seq(S₁, S₃) Un processus atomique S₁ est suivi d’un processus composite qui définit deux processus atomiques conditionnels (If-then-Else) ou concurrentiels (Split), ce qui revient à avoir deux flux de séquence entre (S₁ et S₂ ) et/ou (S₁ et S₃) ⇒ P M [S₁, S₂] = 1 ∧ AP M [S₁, S₃] = 1

Figure 5.6 – Présentation des constructeurs du process model en constructeur de séquence-ment

où α = IfthenElse k Split and If T henElse(S₂, S₃)

— Seq(α(S₁, S₂), S₃)) = Seq(S₁, S₂)∧Seq(S₁, S₃) Un processus composite qui définit deux processus atomiques aux choix (Choice) ou concurrentiels (Split-join), est suivi d’un processus atomique ce qui revient à avoir deux flux de séquence entre (S₁ et S₃ ) et/ou (S₂ et S₃) ⇒ AP M [S₁, S₃] = 1 ∧ AP M [S₂, S₃] = 1 où α = Choice k Split-join.

Considérons le service EventReservationService présenté en haut, il définit quatres pro-cessus atomiques inter-reliés entre eux par un séquencement de trois propro-cessus SelectEvent (E1), SignInEvent (E2) et le processus composite de choix entre BankTransferPayement (E3) and creditcardpayement (E4). Le service ainsi illustre une séquence de nœds partant de E1 vers E2 à partir duquel on peut basculer soit vers E3 ou E4. En conclusion, la matrice d’ad-jacence inclus E(P M ) = {Seq(E1, E2), Seq(E2, E3), Seq(E2, E4)}. Basé sur la description énoncée ci-dessus, nous présentons la matrice d’adjacence du service événement dans la figure 5.5.1: