III.1. Le langage OWL-S
OWL-S est une extension du langage OWL. Il a pour objectif de
fournir une plus grande expressivité en permettant la description des
caractéristiques des services afin de pouvoir raisonner dessus dans le
but de découvrir, invoquer, composer et gérer les services web de
façon la plus automatisée possible.
Ainsi un service dans OWL-S est décrit à travers
les quatre zones conceptuelles suivantes (figure2.5):
Le service profile: contient la réponse à
la question: exige-t-il quoi le service d'un utilisateur ou d'un autre agent,
et lui en fournit quoi ? Ainsi, la classe service présente un
ServiceProfile.
Le Service Process Model: contient la réponse
à la question: Comment fonctionne le service ? Ainsi la classe service
est décrite par un ServiceModel.
Le Service Grounding: contient la réponse
à la question: De quelle façon le service doit-il être
utilisé ? Ainsi, la classe service supporte un
ServiceGrounding.
Service
Présents
(what it does)
Described by
How it works
Supports
How to access it
ServiceProfile
ServiceProcoss
ServiceGrounding
Le Service: il fait seulement attacher les parties
précédentes ensemble dans une seule unité qui peut
être publier et invoquer.
Figure2.5: éléments d'une
description OWL-S
III.1.1. Le Service Profile
Le << profile>> décrit ce que fait le
service, détaille les limitations de son applicabilité et sa
qualité de service et il spécifie également les exigences
que doit l'utilisateur satisfaire pour l'utiliser correctement. Ainsi un
système recherchant un service examinerait la première fois le
<< profile>> pour voir si le service fournit ce qui est
nécessaire.
Un profile OWL-S décrit le service en fonction des
trois types d'information basiques suivants: Quelle est l'organisation
fournissant le service, quelle est la fonction accomplie par le service et un
ensemble de paramètres spécifiant des caractéristiques du
service.
L'information sur le fournisseur consiste en une Contact
Information qui fournit un mécanisme de référence aux
humains ou aux individus responsables du service. Un individu peut être
soit un opérateur de maintenance qui est responsable de
l'exécution du service ou un représentant d'un client qui peut
fournir des informations additionnelles sur le service.
La description fonctionnelle du service est exprimée
selon deux aspects:
· Transformation de d'informations par spécification
des entrées (inputs) requises par le service et des sorties
(outputs) générées.
· Changement d'état produit par
l'exécution du service par spécification des préconditions
(preconditions) requises par le service et des effets
(effects) qui résultent de l'exécution du service.
Finalement, le profile permet la description d'un ensemble de
propriétés pour décrire des caractéristiques du
service. Le premier type d'information donne une classification du service ou
une catégorie (category), le second type spécifie la
qualité du service et le dernier spécifie un ensemble de
paramètres additionnels du service comme par exemple une estimation du
temps de réponse max pour une disponibilité géographique
du service.
Un profile OWL-S est ainsi organisé principalement comme
suit :
· Le nom du service, les contacts et la description du
service qui sont communément appelés propriétés non
fonctionnelles.
· La description de fonctionnalité
"IOPE" (inputs, outputs,
preconditions, effects).
· Une classification selon une taxonomie industrielle
(catégorie) et une description de qualité.
III.1.2. Le Service Process Model
Pour donner une perspective détaillée sur le
fonctionnement d'un service, celui-ci peut être vu comme un
processus. OWL-S fournit une ontologie de processus
(figure2.6) dans laquelle les processus sont vus de deux façons :
· un processus produit une transformation à partir
d'un ensemble de données d'entrée (inputs) vers un
ensemble de données de sortie (outputs).
· un processus produit une transition d'un état du
monde vers un autre. Cette transition est décrite en termes de
preconditions (preconditions) et d'effets (effects).
Dans telle ontologie, un processus peut avoir n'importe quel
nombre d'entrées représentant une information qui est sous
quelques conditions requise pour l'exécution du service. Il peut avoir
n'importe quel nombre de sorties, l'information fournie par le service
conditionnement après son exécution. Il peut être aussi
n'importe quel nombre de préconditions et d'effets. Les sorties et les
effets peuvent avoir des conditions associées à lui. OWL-S ne
permet pas pour le présent l'expression des conditions, les deux
langages principaux sont: SWRL (Semantic Web Rules Language) et DRS.
Le ProcessModel identifie trois types de processus : atomique
(AtomicProcess), simple (SimpleProcess) et composite
(CompositeProcess).
Processus atomique: directement invocable
(par le passage des messages appropriés). Ainsi, il prend un message
d'entrée, exécute et il retourne un message de sortie.
Exécutable dans une seule étape. Il représente le plus
petit processus qui sert à la création des autres processus, et
il ne contient pas de sous processus en interne. L'utilisateur n'a aucune
visibilité sur l'exécution du service.
Processus simple: n'est pas exécutable
(ou invocable) et n'est pas associé d'un grounding. Il fournit une vue
abstraite d'un processus ou d'un ensemble de processus composés.
Processus composite: sont
décomposables en autres (non-composites ou composites) processus. Sa
décomposition peut être spécifié par l'utilisation
des structures de contrôle comme séquence et
if-then-else. OWL-S définit différents types de
structures de contrôle qui régissent l'enchaînement des
composants (atomiques ou composites) d'un processus composite. Parmi nous
citons les suivantes :
Sequence: Une liste de processus
exécutés séquentiellement.
Split: Invoque les éléments d'un
ensemble de processus.
Split+join: Invoque les éléments
d'un ensemble de processus de façon synchronisée.
Unordered: Exécute tous les processus d'un ensemble
sans tenir compte de l'ordre. Choice: Choisit parmi plusieurs
alternatives et exécute l'élément.
If-then-else: Si la condition est
vérifiée alors exécute le <<then >> sinon
exécute le <<else >>. Repeat-Until:
Itère l'exécution d'un ensemble de processus tant que la
condition est vérifiée. Repeat-While:
Itère l'exécution d'un ensemble de processus jusqu'`a ce
que la condition soit vérifiée.
name
ObjectProprety DataTypeProperty
SubClassProperty
ComposedOf
xsd: boolean
Process
&expr;#condition
hasPrecondition
Perform
Result
hasResult
process
hasParticipant
Participant
xsd: boolean
Parameter
hasParameter
Input Output
actor
DisjointWith
hasInput hasOutput
hasLocal
Realizes
Simple Process
CollapsesTo ExpandsTo
RealizedBy
CompositeProcess
Atomic Process
Disjoint With
Invokable
Control Construct
Components
Sequence Split Split-Join Unorder Choice
UnionOf
Figure2.6: Ontologie de processus
| 
