Blog Informatique

Specification et Recherche Sémantique de Services WEB

hazem.nasri | 10 septembre 2008

I. Introduction

De nos jours les entreprises ont adopté définitivement les Web Services comme instrument nécessaire à l’intégration de leur métier dans la sphère de l’e-commerce. Les progrès rapides dans ce domaine sont dus à l’intérêt permanent des industriels en de tels services mais aussi à la disponibilité immédiate d’outils et de standards permettant l’invocation automatisée des fonctions métiers via un échange de messages informatisés (SOAP, UDDI, WSDL). Cependant ces mêmes standards, largement utilisés actuellement, ne permettent de décrire les fonctionnalités des Web Services que de manière syntaxique. Il est impossible de donner un sens à ces descriptions. En réalité, seul un humain sait déduire et classifier le service en fonction de sa description. Ces standards requièrent de la part des programmeurs de coder en dur les informations nécessaires à l’interaction des parties, depuis la séquence de messages à échanger jusqu’à leur interprétation. Dans la plupart des cas, les Web Services offrent au mieux une interface permettant leur invocation, avec des métadonnées décrivant ce que le service accomplit et le fournisseur qui le publie (par exemple les descriptions UDDI). Les applications sont ensuite capables d’invoquer de tels services en utilisant un langage commun (SOAP). Il manque cependant une description sémantique compréhensible par un programme qui permettrait l’automatisation du processus de découverte puis d’invocation des services publiés sur le Web. Par description compréhensible, on entend une certaine quantité d’information que le programme peut traiter en se référant a un vocabulaire établit et commun à tous les Web Services : une ontologie.

II.    Les web services sémantiques
1    Introduction
Les web services sémantiques se situent à la convergence de deux domaines de recherche importants qui concernent les technologies de l’Internet : le web sémantique et les web services. Le web sémantique s’intéresse principalement aux informations statiques disponibles sur le web et les moyens de les décrire de manière intelligible pour les machines. Les web services, quant à eux, ont pour préoccupation première l’interopérabilité entre applications via le web en vue de rendre le web plus dynamique.
La notion de «web service» désigne essentiellement une application (un programme) mise à disposition sur Internet par un fournisseur de service, et accessible par les clients à travers des protocoles Internet standards. Des exemples de services actuellement disponibles concernent les prévisions météorologiques, la réservation de voyage en ligne, les services bancaires ou des fonctions entières d’une entreprise comme la mise en œuvre de la gestion de la chaîne logistique.
Le consortium W3C (http://www.w3.org/2002/ws/) définit un web service comme étant une application ou un composant logiciel qui vérifie les propriétés suivantes :
Il est identifié par un URI,
ses interfaces et ses liens (binding) peuvent être décrits en XML,
sa définition peut être découverte par d’autres web services,
Il peut interagir directement avec d’autres web services à travers le langage XML et en utilisant des protocoles Internet.
L’objectif ultime de l’approche web services est de transformer le Web en un dispositif distribué de calcul où les programmes (services) peuvent interagir de manière intelligente en étant capables de se découvrir automatiquement, de négocier entre eux et de se composer en des services plus complexes. En d’autres termes, l’idée poursuivie avec les web services, est de mieux exploiter les technologies de l’Internet en substituant, autant que possible, les humains qui réalisent actuellement un certain nombre de services (ou tâches), par des machines en vue de permettre une découverte et/ou une composition automatique de services sur l’Internet. L’automatisation est donc un concept clé qui doit être présent à chaque étape du processus de conception et de mise en œuvre des web services. L’automatisation est essentielle pour intégrer les facteurs suivants :
Passage à l’échelle : il faut être capable de traiter un nombre important de web services (annuaire de services au niveau mondial).
Forte réactivité dans un environnement hautement dynamique.
Réduction des coûts de développement et de maintenance des web services.
On peut de plus rajouter les facteurs suivants:
Forte adaptabilité facilitant la maintenance et l’évolution des web services : il est vraisemblable que vu l’enjeu que représente leur réussite et de par leur orientation métier, les web services créés seront amenés à être modifiés fréquemment.
Prise en compte de critères de qualité de services aussi bien d’un point de vue qualitatif que quantitatif : il est clair que la plupart des critères de qualité de services proposés actuellement (e.g. le prix) ne prennent pas en compte des aspects qualitatifs (e.g. la notion de réputation d’un fournisseur).
Or la plupart des travaux existants qui s’intéressent à l’intégration fonctionnelle évitent le problème fondamental de l’automatisation des différentes étapes liées à la fourniture d’un web service (par exemples, découverte et composition) puisqu’ils limitent l’usage des web services aux utilisateurs humains plutôt qu’aux machines. En effet, de nombreuses connaissances, indispensables pour l’automatisation des services, sont soit absentes, soit décrites pour être interprétées et exploitées par des humains. Il en résulte un rôle prédominant pour le programmeur humain. Il semble donc nécessaire de tendre vers des services intelligibles pour des machines : c’est le concept de web service sémantique.
Le besoin d’automatisation du processus de conception et de mise en œuvre des web services rejoint les préoccupations à l’origine du web sémantique, à savoir comment décrire formellement les connaissances de manière à les rendre exploitables par des machines. En conséquence, les technologies et les outils développés dans le contexte du web sémantique peuvent certainement compléter la technologie des web services en vue d’apporter des réponses crédibles au problème de l’automatisation. Par exemple, la notion d’ontologie peut jouer un rôle prépondérant pour permettre d’expliciter la sémantique des services facilitant ainsi les communications hommes-machines, d’une part, et les communications machines-machines, d’autre part.
De manière générale, l’objectif visé par la notion de web services sémantiques est de créer un web sémantique de services dont les propriétés, les capacités, les interfaces et les effets sont décrits de manière non ambiguë et exploitable par des machines et ce en utilisant les couches techniques sans pour autant en être conceptuellement dépendants. La sémantique ainsi exprimée permettra l’automatisation des fonctionnalités suivantes qui sont nécessaires pour une collaboration interentreprises efficace :
Processus de description et de publication des services;
Découverte des services;
Sélection des services;
Composition des services;
Fourniture et administration des services ;
Négociation des contrats.
2    Méthodes, techniques, outils existants sur lesquels on peut s’appuyer
Les web services tendent à devenir un domaine de recherche à part entière qui suscite beaucoup d’intérêt de la part de chercheurs de communautés très variées. On peut citer à titre d’exemple, le génie logiciel, les workflows, les bases de données, la modélisation d’entreprises, la représentation des connaissances ou les multi-agents. Cependant, on constate aujourd’hui que la littérature scientifique traitant des web services est trop dispersée. Il en résulte une absence d’unification et d’intégration de ses concepts rendant, tout au moins actuellement, difficile une appréhension globale et synthétique de ce domaine. Ce phénomène est accentué par la diversité (et parfois l’inconsistance) des visions proposées par les différentes communautés de recherche. En effet, à l’exception du consensus constaté autour de l’infrastructure de base qui ne concerne que les couches basses de la pile des web services (descriptions techniques pour assurer l’interopérabilité), des divergences de vues sur le rôle et le contenu des couches hautes de la pile (e.g., les relations entre les web services, les business processes et les workflows) apparaissent clairement dans la littérature. Ce point est important car il interpelle directement les problèmes d’intégration de processus d’entreprises. Ce type d’intégration constitue un des apports les plus prometteurs de l’approche web services. C’est la raison pour laquelle, dans la suite de cette section, je présente d’abord l’infrastructure de base des web services. J’aborde ensuite, à travers la notion de pile conceptuelle des web services, les différents problèmes liés à la définition et la modélisation des contenus des couches hautes de cette pile.
Techniquement, un web service peut donc être perçu comme étant une interface décrivant une collection d’opérations accessibles via le réseau à travers des messages XML standardisés. D’un point de vue technique, la description d’un web service inclut tous les détails nécessaires à l’interaction avec le service comme, par exemples, le format des messages, les signatures des opérations, le protocole de transport et la localisation du service. Les web services s’appuient sur des mécanismes et des protocoles standards et sont donc indépendants des langages de programmation (Java, J#, C++, Perl, C#, etc.), du modèle objet (COM, EJB, etc.) ainsi que des plates-formes d’implémentation (J2EE, .NET, etc.).
2.1    Architecture de référence
Les efforts de recherche et de développement récents autour des web services ont conduit à un certain nombre de spécifications qui définissent aujourd’hui l’architecture de référence des web services. Cette architecture vise trois objectifs importants (http://www.w3.org/2002/ws/): (i) identification des composants fonctionnels, (ii) définition des relations entre ces composants, et (iii) établissement d’un ensemble de contraintes sur chaque composant de manière à garantir les propriétés globales de l’architecture.
L’architecture de référence des web services (cf. figure X1) s’articule autour des trois rôles suivants :
Le fournisseur de service.
Correspond au propriétaire du service. D’un point de vue technique, il est constitué par la plate-forme d’accueil du service.
Le client.
Correspond au demandeur de service. D’un point de vue technique, il est constitué par l’application qui va rechercher et invoquer un service. L’application cliente peut être elle-même un web service.
L’annuaire des services.
Correspond à un registre de descriptions de services offrant des facilités de publication de services à l’intention des fournisseurs ainsi que des facilités de recherche de services à l’intention des clients.

Client
Recherche/localisation
Lier(bind)/connecter
Invocation service/méthodes
1- Publier (WSDL)
4- invoquer (SOAP)
3- Lier/connecter
2- Rechercher WSDL

Annuaire de services
(e.g., UDDI)
Fournisseur de services
Implémentation
Déploiement
Description et publication
Figure X1- Architecture des web services.

Les interactions de base entre ces trois rôles incluent les opérations de publication, de recherche et de liens (bind) d’opérations. Je décris ci-dessous un scénario type d’utilisation de cette architecture : Le fournisseur de services définit la description de son service et la publie dans un annuaire de service. Le client utilise les facilités de recherche disponibles au niveau de l’annuaire pour retrouver et sélectionner un service donné. Il examine ensuite la description du service sélectionné pour récupérer les informations nécessaires lui permettant de se connecter au fournisseur du service et d’interagir avec l’implémentation du service considéré.
Pour garantir l’interopérabilité des trois opérations précédentes (publication, recherche et lien), des propositions de standards ont été élaborées pour chaque type d’interactions. Je cite, notamment les standards émergents suivants :
SOAP définit un protocole de transmission de messages basé sur XML.
WSDL introduit une grammaire commune pour la description des services.
UDDI fournit l’infrastructure de base pour la publication et la découverte des services.
L’infrastructure de base autour de ces standards répond aux problèmes d’intégration technique des applications. En effet, contrairement aux approches d’intégration classiques qui ne sont pas exemptes d’inconvénients (e.g., les EAI qui sont des applications propriétaires), les web services proposent une approche flexible et ‘universelle’ pour l’intégration de systèmes hétérogènes en s’appuyant sur un modèle d’intégration basé sur un couplage faible des composants (peer-to-peer) et en exploitant de manière intensive les standards du web. Ceci a pour effet de permettre une intégration des applications plus rapide et moins coûteuse et avec des perspectives d’évolution et de réutilisation réelles pour les entreprises.
Cependant, cette infrastructure n’est pas suffisante pour permettre une utilisation effective des web services dans les domaines dont les exigences vont au-delà de la capacité d’interactions simples via des protocoles standards. Par exemple, dans le domaine du e-business, cette utilisation est motivée par les possibilités de coopération et de coordination entre des entreprises telles qu’on peut les percevoir dans la mise en œuvre de la gestion d’une chaîne logistique ou celle de la gestion des relations clients. Le challenge est alors d’être capable de spécifier et de mettre en œuvre des business processes intra ou inter entreprises. Ceci pose donc fondamentalement un problème d’intégration fonctionnelle des activités d’entreprises qui dépasse la simple capacité d’interactions via des protocoles standard. Pour des raisons de cohérence du discours, J’introduis dans la section suivante la problématique de l’intégration inter-organisationnelle ainsi que ses concepts sous-jacents proposés dans la littérature.
2.2 Problématique de l’intégration
Actuellement, les solutions pour résoudre les problèmes d’intégration technique d’entreprises s’appuient beaucoup sur la technologie EAI. Or, les solutions EAI sont, par essence, des solutions propriétaires, c’est-à-dire dédiées à la résolution de problèmes spécifiques, complexes à utiliser et qui ne peuvent pas bien interopérer les unes avec les autres. Par exemple, quand plusieurs entreprises intègrent des systèmes qui sont eux-mêmes intégrés en utilisant des EAI, les développeurs sont confrontés au problème récursif d’intégrer des solutions elles-mêmes intégrées. Dans un environnement très versatile où les intégrations fonctionnelle et technique doivent quasiment être réalisées au fil de l’eau, il est évident que la technologie EAI ne peut prétendre avoir l’ambition de s’imposer, ne serait-ce que parce qu’elle exige une forte composante humaine avec des temps de réaction très longs. Contrairement aux web services qui intrinsèquement peuvent être conçus pour être indépendants des technologies hétérogènes des partenaires d’une organisation virtuelle.
On comprend alors mieux pourquoi l’infrastructure de base des web services n’est pas suffisante pour répondre de manière satisfaisante à cette problématique de l’intégration. Cette dernière, en effet, exige, par essence, la définition d’un protocole qui permet aux activités intra et/ou inter entreprises composant un processus, d’être cohérentes relativement à une organisation afin d’atteindre l’objectif visé. Il s’avère donc nécessaire d’étendre l’architecture de base des web services comme présenté dans la section suivante.
2.3 Architecture étendue
Différentes extensions de l’architecture de référence ont été proposées dans la littérature. Le groupe architecture du W3C travaille activement à l’élaboration d’une architecture étendue standard.
Une architecture étendue est constituée de plusieurs couches se superposant les unes sur les autres, d’où le nom de pile des web services. La figure X2 décrit un exemple d’une telle pile. La pile est constituée de plusieurs couches, chaque couche s’appuyant sur un standard particulier. On retrouve, au-dessus de la couche de transport, les trois couches formant l’infrastructure de base décrite précédemment. Ces couches s’appuient sur les standards SOAP, WSDL et UDDI.
Comme mentionné précédemment, l’infrastructure de base définit les fondements techniques permettant de rendre les business processes accessibles à l’intérieur d’une entreprise et au-delà même des frontières d’une entreprise. Dans ce contexte deux types de couches permettent de la compléter : (i) les couches dites transversales (e.g. sécurité, administration, transactions et qualité de services (QoS)) rendent viable l’utilisation effective des web services dans le monde industriel ; (ii) une couche Business processus permet l’utilisation effective des web services dans le domaine du e-business. Dans la suite, on va s’intéresser qu’à la couche business processes pour laquelle, on peut relever dans la littérature, les problèmes sous-jacents suivants :
Comment les business processes peuvent-ils être représentés comme des web services ?
Nécessité de décrire comment les web services sont utilisés pour implanter les activités d’un business process.
Les problèmes de composition de service, i.e., quel(s) partenaire(s) va (vont) exécuter quelle(s) partie(s) d’un business process ?

Figure X2- Pile des web services

Différents auteurs de la communauté de recherche s’accordent sur la nécessité de spécifier le comportement externe de chaque partie impliquée dans le protocole d’intégration de processus (partie publique) sans pour autant révéler leurs implémentations internes (partie privée). Deux raisons justifient cette séparation :
Les entreprises ne tiennent pas forcément à révéler leurs prises de décisions internes et souhaitent préserver la confidentialité de leurs données.
La séparation publique-privé permet de modifier la partie privée indépendamment de la partie publique.

3 Conclusion
Le Web sémantique est le Web de demain dans lequel les métadonnées sémantiques jouent un rôle très important. On peut utiliser ce type de données pour enrichir des pages Web existants. Avec la technologie des Ontologies pour la représentation des connaissances, l’annotation des Web et des services pose plusieurs avenues de recherches. C’est un nouveau domaine de recherche et il reste encore beaucoup d’obstacles qu’ils faut résoudre: par exemple les outils pour la réalisation et l’utilisation des ontologies, les langages, les méthodes de modélisation sémantique pour les Web services. Dans un avenir proche, je crois que nous pouvons former un Web interactif et intelligent grâce à l’intégration avec les technologies des services Web. Donc, les services Web sémantique sont un début prometteur parce que nous pouvons mieux exploiter les services sur Web en automatisant, autant que possible, les différentes tâches liées au cycle de vie d’un service.

III. Description sémantique de services Web

1 Introduction

Malgré une large acceptation par la communauté des technologies de l’information, la pile de protocoles standards des services Web n’a pas été initialement développée pour satisfaire aux exigences de l’échange sémantique. Aussi, le langage de modélisation de processus métiers WS-BPEL reste concentré sur le côté syntaxique, sans considérer les aspects sémantiques mis en jeu durant la composition. Les problèmes d’hétérogénéités sémantiques sont par conséquent gérés de manière manuelle durant la phase de conception d’un processus métier. Pour atteindre l’interopérabilité sémantique, c’est-à-dire pour être en mesure de prendre en charge la signification des données qu’ils échangent, les services Web doivent être capables:

1. d’interpréter correctement la sémantique des données qu’ils envoient et reçoivent,

2. de décrire les fonctionnalités qu’ils fournissent en utilisant une sémantique explicite et compréhensible par les machines.

Afin de répondre à ces exigences, la communauté du Web sémantique propose des solutions reposant sur des ontologies de référence pour fournir une description explicite de la sémantique des services Web, lesquels sont ensuite appelés services Web sémantiques.

L’objectif des services Web sémantiques est de faciliter les tâches liées à leur utilisation, telles que la découverte, la sélection, l’orchestration et l’invocation, par le biais de leurs descriptions qui rendent la sémantique explicite et compréhensible par les machines. Ainsi, le domaine des services Web sémantiques se situe au croisement du Web sémantique et des services Web. De nombreux langages et architectures sont proposés afin de décrire les services Web sémantiques. Je propose ci-dessous une classification des approches existantes, qui structure ma présentation des approches de description sémantique pour les services Web.

2 Classification et présentation des approches

La réalisation des conditions qui élèvent les services Web au rang de services Web sémantiques peut suivre deux approches.
La première approche consiste à développer un langage complet qui décrit les services Web ainsi que leur sémantique d’un seul bloc.

La deuxième approche consiste à annoter les langages existants avec de l’information sémantique. L’avantage principal de ce genre de solutions réside dans la facilité pour les fournisseurs de services d’adapter leurs descriptions existantes aux annotations proposées.

Je vais essayer de classifier ces approches de la manière suivante : dans un premier temps, j’étudie les langages de description sémantique, puis dans un second temps je détaille les annotations de langages existants.

2.1 Langages de description sémantique

a) Web Ontology Language for services Web (OWL-S)

Le < Web Ontology Language for Web services > (OWL-S) est un sous-ensemble du langage < Web Ontology Langage > (OWL) dédié à la description sémantique de services Web. Il est compatible avec des formats de description syntaxiques tels que WSDL. OWL est le langage de référence dans le domaine des langages reposant sur la logique de description. Ce langage est construit à partir de RDF qui est un modèle conceptuel permettant la description formelle des ressources du Web sous la forme de triplets : ressource, propriété, aussi appelée prédicat, et valeur. Par exemple, (< Michael >;< est >;< un homme >) est un triplet qui a pour ressource < Michael >, pour prédicat < est > et pour valeur < un homme >.

OWL est une extension de RDF Schema, c’est-à-dire qu’à l’instar de RDF Schema, OWL définit un vocabulaire permettant de décrire des ontologies, tout en offrant des possibilités de description plus riches. Parmi les notions importantes apportées par OWL, citons les propriétés d’équivalence, d’identité de deux ressources, de différences entre deux ressources, de contraire, de symétrie, de transitivité et de cardinalité. Ces propriétés permettent l’utilisation de raisonneurs afin de déterminer des relations d’équivalence ou de subsomption entre des concepts de domaines de connaissances (signifie que l’un des concepts est un sous concept de l’autre, c’est-à-dire que les attributs du premier concept forment un sous-ensemble des attributs du deuxième.) , et d’évaluer automatiquement la compatibilité entre différentes représentations sémantiques.

Une description OWL-S se compose de trois éléments : le service profile, le process model, et le grounding, qui décrivent respectivement , et :

– Le service profile décrit les fonctionnalités des services Web, il est utile pour leur découverte et leur sélection.
– Le process model détaille la sémantique des données échangées, au niveau des messages échangés entre services Web.
– Le grounding spécifie l’encodage des données échangées, les protocoles de communication, ainsi que tous les détails concrets nécessaires à l’invocation du service.

OWL-S recommande la séparation entre les vues de haut et de bas niveau concernant la description des données échangées entre services Web.

La vue abstraite, dite de haut niveau, attache le service Web à des descriptions conceptuelles en OWL, décrites dans des ontologies. La vue concrète, ou de bas niveau, décrit la représentation physique du service Web, c’est-à-dire les types de données et les protocoles utilisés. Cette séparation permet différentes représentations physiques du même concept, et renforce le rôle des ontologies dans la représentation abstraite de la sémantique des données.

Suivant les idées développées par les auteurs d’OWL-S, de nombreux travaux de recherche ont été proposés. Notamment, ODESWS est une architecture de description et composition de services Web reposant sur les méthodes de résolution de problèmes, ou < Problem-Solving Methods > (PSM). Dans cette architecture, une fonctionnalité est représentée comme un problème, et la description des fonctionnalités offertes par les services permettent d’évaluer les possibilités de résolution du problème.

b) Web Service Modeling Ontology (WSMO)

L’architecture Web Service Modeling Ontology (WSMO), est une architecture conceptuelle, ou méta modèle, visant à expliciter la sémantique des services Web. Elle est organisée autour de quatre éléments principaux :

– Les services Web sont définis comme des < entités computationnelles > qui fournissent une fonctionnalité. Une description est associée à chaque service, dans le but de décrire sa fonctionnalité, son interface, et ses détails internes.

– Les Objectifs servent à décrire les souhaits des utilisateurs(trices) en terme de fonctionnalités requises. Les objectifs sont une vue orientée utilisateur(trice) du processus d’utilisation des services Web, ils sont une entité à part entière dans le modèle WSMO. Un objectif décrit la fonctionnalité, les entrées/sorties, les pré conditions et post conditions d’un service Web.

– Les Médiateurs sont utilisés pour résoudre de nombreux problèmes d’incompatibilité, telles que les incompatibilités de données dans le cas où les services Web utilisent différentes terminologies, les incompatibilités de processus dans le cas de la combinaison de services Web, et les incompatibilités de protocoles lors de l’établissement des communications.

– Les Ontologies fournissent la terminologie de référence aux autres éléments de WSMO, afin de spécifier le vocabulaire du domaine de connaissance d’une manière interprétable par les machines. Contrairement à OWL-S, WSMO inclut les médiateurs comme des composants centraux de son architecture. Les hétérogénéités rencontrées lors de l’utilisation de services Web sont gérés par les types de médiation suivants :
–> La médiation de données résout les incompatibilités de représentation des données.
–> La médiation de processus est relative à la logique applicative de la composition.
–> La médiation de protocoles adapte les différents protocoles de communication utilisés.

Ces types de médiation sont pris en charge par quatre familles de médiateurs :
–> Les GG-médiateurs permettent d’effectuer la médiation entre deux objectifs, GG signifiant < goal-goal >. Cela signifie qu’ils permettent d’établir des correspondances entre objectifs, en se servant des ontologies d’objectifs disponibles dans le cadre de WSMO.
–> Les WG-médiateurs, avec WG pour < Web service-goal >, établissent les correspondances entre les fonctionnalités offertes par les services Web et les requêtes des utilisateurs(trices), qui sont toutes les deux définies comme des objectifs. L’intérêt de ce type de médiateurs est d’aider la découverte et la sélection de services Web.
–> Les WW-médiateurs, avec WW pour < Web service-Web service >, établissent les correspondances entre services Web. Leur tâche est de résoudre les conflits au niveau des données, du protocole, et du processus de composition. Ils sont mis en œuvre lors de l’orchestration des services Web au sein d’une composition.
–> Les OO-médiateurs, avec OO pour < ontology-ontology >, sont destinés à résoudre les conflits entre ontologies. Les autres types de médiateurs énoncés ci-dessus, mais aussi n’importe quel élément de l’architecture WSMO qui pourrait utiliser les ontologies, peut utiliser un OO-médiateur pour résoudre un conflit sémantique. Le travail des OO-médiateurs consiste à établir des correspondances entre les terminologies contenues dans les différentes ontologies pour les intégrer en une représentation homogène des données. Cette représentation homogène permet de résoudre les hétérogénéités sémantiques et de répondre aux requêtes soumises par les composants de l’architecture WSMO.

c) DIANE Elements (DE) et DIANE Service Description (DSD)

Les langages DIANE Elements (DE) et DIANE Service Description (DSD) sont des langages orientés objet construits à partir d’une analyse des conditions requises pour la description des services Web sémantiques, et des difficultés de OWL-S et WSMO à remplir ces conditions.
Les langages DIANE Elements (DE) et DIANE Service Description (DSD) utilisent les notions d’ensembles configurables et de logique floue pour améliorer la découverte sémantique de services Web. DE est un langage général d’ontologie qui contient des caractéristiques spécifiques visant à améliorer la description de services Web sémantiques.

Ce langage orienté objet hérite de la F-logique pour décrire les concepts d’attributs, de types de données primitifs (empruntés à XML Schema), et d’élément restreints (seulement huit types primitifs). La F-logique est un langage déductif orienté objet de représentation des connaissances, qui combine la sémantique déclarative et l’expressivité des langages déductifs avec les capacités de modélisation du modèle orienté objet. La séparation entre schéma et instances est aussi empruntée à la logique de description.
Le langage DSD quant à lui, utilise les constructions fournies par DE afin de décrire les services Web. Il est construit autour des notions de description de requête et d’offre de service : la description d’un service constitue une offre et une demande utilisateur constitue une requête. L’approche proposée fournit une architecture globale pour la description de services Web sémantiques, avec un fort support de raisonnement, qui emprunte de nombreux avantages apportés par les approches OWL-S et WSMO.

2.2 Annotation des langages existants

Contrairement aux langages précédents, plusieurs travaux proposent d’étendre les normes existantes par une annotation, soit en utilisant les éléments d’extensibilités prévus à cet effet, soit en modifiant les fonctionnalités initiales des normes. Ces extensions sont détaillées ci-dessous.

a) Annotation du processus métier

SEmantic Service MArkup (SESMA). Le langage SESMA est un autre format de description pour services Web sémantiques, qui a été conçu pour fournir un langage simple à utiliser, avec une syntaxe compacte et une forte intégration avec les langages existants WSDL, SOAP et WS-BPEL. SESMA a été construit avec les objectifs suivants :

– une syntaxe reposant sur le langage XML, pour une distribution du langage à large échelle,
– une sémantique précise qui clarifie la signification des descriptions,
– une forte complémentarité avec les langages existants,
– des possibilités d’extension permettant une évolution vers d’autres langages éventuels.
Son principal avantage est d’être un langage léger, et sa sémantique n’est pas construite à partir de OWL. De plus, il fournit un support pour la description de services composites, sous la forme d’annotations de processus métiers WS-BPEL.

b) Annotation du langage de description

Exploitation des éléments d’extensibilité de WSDL. Avec WSDL-S, on peut annoter WSDL avec plusieurs extensions relatives aux opérations et messages d’entrée/-sortie des services Web. Ces extensions contiennent des références aux concepts décrits dans les ontologies de description du domaine de connaissance associé au service Web, afin de spécifier la sémantique des messages, mais aussi les prés conditions et effets des opérations. WSDL-S vise à fournir une approche < allégée > d’annotation sémantique de services Web.

Extension de WSDL avec SAWSDL. Le World Wide Web Consortium propose avec les Semantic Annotations for Web Services Description Language (SAWSDL) un moyen d’annoter les descriptions WSDL 2.0 tout en supportant WSDL 1.1. SAWSDL est un ensemble d’attributs d’extension permettant de décrire la sémantique des éléments contenus dans les documents WSDL. L’objectif de SAWSDL est de définir comment une annotation doit être réalisée, tout en laissant le choix du langage utilisé pour la description sémantique. SAWSDL fournit les mécanismes permettant d’attacher des concepts décrits dans des ontologies aux annotations des descriptions WSDL. Cette proposition étend WSDL-S, elle peut être considérée comme une continuité de ce langage. Elle vise à apporter la valeur ajoutée de la sémantique non seulement lors de l’invocation des services Web, mais aussi durant la phase de découverte. Trois attributs d’extensibilité sont définis par défaut : l’attribut permet l’association entre un composant WSDL et un concept d’une ontologie, et les attributs < liftingSchemaMapping > et < lowering-SchemaMapping > sont ajoutés aux définitions de types pour spécifier les correspondances entre les éléments du schéma des données et l’information sémantique de l’ontologie.

c) Annotation des registres

Extension sémantique de UDDI. Paolucci et coll. présentent une approche visant à améliorer la publication et la découverte de services Web dans les registres UDDI. Ils étendent les descriptions UDDI avec l’information sémantique nécessaire pour décrire les capacités des services Web, en utilisant le langage DAML-S, prédécesseur de OWL-S. Ils soutiennent que la découverte des fonctionnalités de services Web ne peut être effectuée qu’au niveau sémantique. En effet, sans sémantique explicite, deux descriptions équivalentes peuvent être interprétées différemment, selon les circonstances de leur utilisation.

Ainsi, l’automatisation de la découverte des services Web passe par la description explicite de leurs capacités. Les auteurs décrivent une méthode pour effectuer la traduction de la représentation DAML-S vers la représentation UDDI. De plus, ils proposent un algorithme de correspondance sémantique des fonctionnalités offertes par les services Web, sur la base de leur représentation UDDI modifiée. Ainsi, la découverte de services Web tire avantage des descriptions sémantiques qui ont été insérées dans le standard UDDI.

Extension sémantique d’ebXML. Dogac et coll. [2] proposent aussi un enrichissement des registres avec de la sémantique, mais leur proposition concerne le standard ebXML. Leur motivation est similaire à celle de Paolucci et coll., cependant les mécanismes développés sont différents en raison de la structure d’ebXML qui possède de nombreuses différences par rapport à UDDI. En effet, ebXML permet de stocker la description sémantique d’un service Web directement dans le registre, alors que UDDI doit faire référence à un document extérieur. Aussi, ebXML fournit la possibilité de définir des correspondances vers des concepts sémantiques directement dans le fonctionnement du registre. Ainsi, les auteurs utilisent les possibilités d’ebXML pour insérer les ontologies directement dans les registres. Ils proposent une table de correspondance entre le vocabulaire de OWL et les structures de description offertes par ebXML, lesquelles sont étendues pour atteindre la richesse de description offerte par OWL. Grâce à cette solution, les registres ebXML sont capables de contenir des descriptions sémantiques de services Web, qui peuvent être découvertes par les applications clientes à l’aide de modèles de requêtes spécifiques aux descriptions sémantiques proposées par les auteurs.
3 Conclusion

Dans ce chapitre, j’ai présenté les propositions de description sémantique des services Web. En effet, comme le montrent la multiplicité et l’évolution rapide des langages et annotations proposés, la résolution des conflits sémantiques, principalement par la description explicite des données, peut clairement constituer la prochaine étape vers l’interopérabilité entre systèmes distribués. Ainsi, les approches de description sémantique des services Web suivent un objectif commun : décrire de manière explicite et gérer la sémantique associée aux services Web, car cette sémantique reste absente de leur pile standard de protocoles. Malgré cet objectif commun, deux orientations complètement différentes caractérisent les approches étudiées :
– Les langages sémantiques tentent de s’imposer comme de nouvelles normes de description. Ils souhaitent remplacer les langages actuels comme WSDL, et inscrire les services Web dans le cadre du Web sémantique. Ces langages apportent les nombreux avantages liés à la description sémantique, et bénéficient des critiques apportées sur les langages précédents. Cependant, ils nécessitent des descriptions plus complexes qui demandent des connaissances importantes lors de la conception d’une description.

– Les annotations enrichissent les langages existants afin de décrire la sémantique des services Web. Ces approches sont avantageuses dans la mesure où elles exploitent les éléments d’extensibilité des langages existants, et restent compatibles avec ces derniers. En effet, il est contraignant de devoir renoncer aux normes existantes afin de bénéficier des avantages apportés par les approches proposées.
Notons que la plupart des approches décrites, excepté WSMO, se concentrent sur la découverte et la correspondance de concepts. Cela suppose que les services Web découverts ont adhéré à une ontologie commune, et adoptent la représentation des données de cette ontologie. Cela suppose aussi une adaptation de la sémantique locale des services Web à la sémantique de l’ontologie partagée. Autant de suppositions difficiles à soutenir dans le contexte des services Web et d’Internet.
IV. Une architecture pour la découverte et l’orchestration de services Web sémantiques

1 Introduction

De par son métier d’intégrateur de systèmes civils et militaires, Thales est amené à concevoir et manipuler des systèmes d’information à forte hétérogénéité : se pose alors le problème du maintien de l’interopérabilité entre les composants de ces systèmes.
Cette problématique est traditionnellement traitée au niveau syntaxique : en ce sens, l’interopérabilité reste superficielle et ne peut être maintenue qu’en imposant de fortes contraintes aux utilisateurs du système. Cela reste particulièrement difficile à maintenir, notamment lors du passage à l’échelle. De plus, la multitude de solutions ad hoc déjà existantes amène Thales à penser que la mise au point d’une approche unificatrice et aisément transposable à chaque domaine d’application permettra d’améliorer significativement l’interopérabilité et d’en diminuer les coûts associés.
Dans le cadre des activités de recherche et développement de Thales, ils cherchent à mettre en œuvre une application concrète des modèles formels de partage de connaissance et choisissons les ontologies comme support de cette formalisation.
Cette réalisation pose les bases d’un cadre général pour le support de l’interopérabilité fonctionnelle au niveau sémantique dans les architectures orientées services : elle a pour but de permettre l’interopérabilité des composants dans les environnements SOA (Service Oriented Architecture) hétérogènes, distribués et hautement dynamiques. Dans ces architectures, les services Web peuvent apparaître et disparaître à tout moment pendant l’exécution.
Pour ce type de systèmes, un niveau élevé d’interopérabilité entre producteurs et consommateurs de services est requis car les décisions de liaison ne peuvent être prises avant le déploiement ou l’exécution du système d’information. En effet, les services sont majoritairement découverts dynamiquement, à l’exécution.
Ce genre de caractéristiques pourrait se retrouver dans les systèmes d’intégration et d’information à visées militaires (Systèmes Terre et Interarmées) et civiles développées par Thales. Par exemple :
• Le besoin, sur le terrain, de déployer un système de commande et contrôle partagé par les différents alliés d’une coalition internationale (par ex. OTAN). Dans ce type de système de commande, les processus métiers correspondent à des procédures militaires qui pourraient être définis à l’avance et s’adapter à l’éventuelle indisponibilité des services utilisés.
• La nécessité, dans les systèmes civils de gestion de crise, de découvrir et coordonner les secours dans un temps contraint et de choisir les bons scénarios d’action en fonction des équipements disponibles sur le réseau.
En fonction de ces contraintes, le cadre de travail a été défini comme suit :
• Les SOA : de ce fait, ils manipulent des services Web et des processus Web.
• Des domaines « métiers » spécifiés formellement : une certaine connaissance du domaine sera partagée sous forme d’ontologie(s) par les protagonistes du système.
• Des environnements hétérogènes : des différences pourront survenir aux niveaux sémantique et syntaxique entre la demande de service du consommateur et la déclaration du producteur de service.
• Des environnements dynamiques : les consommateurs de service, sous forme de processus métiers, seront liés dynamiquement lors de l’orchestration aux services disponibles dans le système.
Le reste de ce chapitre s’organise comme suit : dans un premier temps je présente la solution logicielle développée par Thales, ensuite les concepts fondamentaux traités par cette solution, nommément : la spécification des connaissances, des propriétés fonctionnelles, la publication et la recherche sémantique de service, ainsi que l’orchestration sémantique de services.

2 Le framework SETHA

Afin d’apporter une solution simple et efficace au problème de l’interopérabilité dans les architectures SOA hétérogènes et dynamiques, Thales a mis au point un ensemble de composants réunis au sein d’un framework nommé SETHA (SEmanticTHAles). Cette réalisation industrielle regroupe un ensemble extensible de fonctionnalités et technologies pour permettre :

• La spécification :

- des connaissances sous forme d’ontologies,
- des propriétés fonctionnelles des services Web à partir de leur déclaration de service et d’ontologies,
- des contraintes fonctionnelles des processus Web par une méthodologie similaire à celle employée pour les services.

• La publication et la découverte sémantique de services via un annuaire.

• L’orchestration sémantique des processus Web à partir des informations syntaxiques et sémantiques disponibles au moment de l’exécution des processus. Cela inclut :

- L’appariement entre consommateurs de services et les meilleures offres des producteurs grâce à la notion de conformité sémantique.
- La gestion de l’adaptation de données nécessaire à l’appel de services.

La particularité de ce framework réside donc dans ses facultés d’abstraction des contraintes syntaxiques pour se focaliser sur le sens réel des informations exprimées par les composants et utilisateurs du système.
Ces informations sémantiques permettent de définir un système d’information par composition sans avoir à se soucier des contraintes telles que l’adresse des services à appeler, le nom des opérations, le type des données : cette abstraction est d’autant plus importante, qu’obtenir une correspondance syntaxique parfaite entre offre et demande est très improbable dans un système hétérogène.
Ce framework est essentiellement constitué de technologies standardisées, ou en cours de standardisation, et issues de travaux relatifs au Web Sémantique : comme le langage SAWSDL (Semantic Annotation for WSDL), BPEL (Business Process Execution Language), OWL (Ontology Web Language) et la spécification d’annuaires de service UDDI (Universal Description, Discovery and Integration).
Ceci devrait assurer la pérennité du développement et de ses futures mises à jour.
Nous verrons dans les sections suivantes comment ces technologies sont misent en œuvre pour obtenir les fonctionnalités souhaitées.

3 Spécification des connaissances

Lors de la mise au point d’un système d’information reposant sur une architecture SOA, il n’existe traditionnellement pas de modèle commun des connaissances portant sur le domaine d’application du système. L’entente entre les différents intervenants se situe alors au niveau syntaxique et ne fait l’objet d’aucune réflexion poussée avant son déploiement : un client ne peut qu’extrapoler le fonctionnement effectif d’un service à partir de la description syntaxique de son interface (par ex. le nom des opérations ou le type des paramètres). Mais producteurs et consommateurs de services attribuent-ils la même signification aux lexèmes qu’ils utilisent ?
3.1 Une approche formelle : les ontologies

Cet état de fait constitue un frein majeur à l’adoption des architectures SOA dans les environnements à forte hétérogénéité. En effet, comment mener à bien des processus Web complexes si l’on n’est pas en mesure de sélectionner de manière effective les fonctionnalités nécessaires à leur exécution parmi le vaste ensemble de services offerts par des tiers ?
C’est pour répondre à cette problématique que le framework SETHA supporte la spécification formelle des concepts significatifs dans un ou plusieurs domaines d’application. Pour s’assurer qu’il n’existe pas de différences d’interprétation entre fournisseurs et consommateurs de service, SETHA leur demande de faire référence à une sémantique connue et distribuable.
En fonction de leur degré de formalisation, les méthodes formelles peuvent être utilisées à des fins diverses :
• Pour spécifier les propriétés d’un système. Une méthode formelle peut donc être utilisée pour décrire les propriétés fonctionnelles des composants d’une architecture SOA.
• Pour prouver que certaines propriétés sont valides dans le système.
• Pour raisonner sur les connaissances et d’effectuer des calculs d’inférence. On peut alors effectuer automatiquement certains types de raisonnement sur les propriétés fonctionnelles, par exemple pour calculer les correspondances entre offres et demandes de service.
Dans le cadre de ce framework, cette spécification formelle sera effectuée au moyen d’ontologies. Une ontologie est un modèle des entités et relations dans un domaine spécifique ou « universe of discourse » (UoD). Elle se distingue d’une taxonomie (connaissances avec une hiérarchisation minimale ou une structure parent-enfant), d’un thésaurus (mots et synonymes) dans la mesure où elle représente un modèle conceptuel (avec des connaissances plus complexes) voir même une théorie logique. Une ontologie dispose d’une sémantique formelle, c’est à- dire une théorie de modèle pour son langage. De ce fait, elle supporte l’inférence via son modèle formel, et peut être est décidable et soluble en fonction de son expressivité.
3.2 Un langage de spécification d’ontologies : OWL

OWL est le langage de spécification d’ontologies qui a été retenu dans le framework SETHA. Il fournit les moyens pour définir des ontologies Web structurées. Ce langage est basé sur les recherches effectuées dans le domaine des logiques de description. De plus, une description OWL d’ontologie présente l’avantage d’être « sérialisable » sous une forme XML.
Il existe trois variantes du langage OWL à l’expressivité croissante : lite, DL et full. OWL-DL à l’avantage de rester décidable tout en présentant une expressivité suffisamment étendue pour la plupart des applications, c’est donc lui qui va être utiliser pour la définition d’ontologies. De plus il existe de nombreux raisonneurs logiques capables de traiter cette classe d’ontologies .
OWL est adéquat pour les travaux relatifs au « Web sémantique », car il offre une syntaxe définie strictement, une sémantique formelle et selon le niveau peut permettre des raisonnements automatisés par inférence sur les connaissances. Il est donc possible de profiter de ce format pour structurer, partager et échanger des connaissances. Il existe déjà de nombreuses ontologies modélisées à l’aide de OWL.
4 Ontologies et spécification des propriétés et contraintes fonctionnelles
Il s’agit de la spécification des propriétés fonctionnelles offertes par les services Web publiés dans l’architecture SOA ainsi que de la spécification des contraintes fonctionnelles portant sur ces services et définies dans les processus Web. Dans les deux cas, les ontologies sont mises à contribution pour apporter la « connaissance » sémantique du domaine métier considéré.
Par « fonctionnel », on entend tout ce qui est directement lié au métier du service et aux fonctionnalités offertes, et non à la qualité du service rendu (temps de réponse ou de traitement, latence, …).

Offre de service, la spécification SAWSDL

Dans l’architecture qui a été défini, les services web possèdent une description syntaxique et sémantique de leurs propriétés fonctionnelles (les fonctionnalités exposées par le service) :
• La description syntaxique regroupe les informations telles que les noms d’opération, types de données, protocoles réseau et point d’accès.
• La description sémantique augmente les descriptions de service avec des concepts extraits d’une ontologie afin d’en préciser le sens.
De ce fait, ce framework est à ma connaissance l’une des premières réalisations industrielles à présenter une application concrète de la recommandation W3C.
Cette extension de WSDL 2.0 permet à un fournisseur de service de définir des déclarations améliorées sémantiquement qui viennent s’ajouter au niveau syntaxique d’une spécification WSDL classique.
SAWSDL permet l’annotation de certains éléments d’une déclaration de service par des concepts sémantiques référencés grâce à une URL unique. Dans le cadre de cette réalisation industrielle, les développeurs ont choisi les ontologies OWL comme moyen de définition de ces concepts sémantiques, les URL désigneront donc des classes ontologiques. Ainsi, SAWSDL qui permet de tracer un lien direct entre une déclaration de service et la spécification sémantique du domaine considéré.
5 Publication, recherche et orchestration sémantique de services
Les services Web correspondent à des entités dynamiques de cette architecture :
Ils peuvent devenir disponibles à tout moment au cours de l’exécution du système et parallèlement être découverts dynamiquement par leurs clients (ce sont les processus Web). Fournisseur et consommateurs de services doivent donc disposer d’un moyen commun et fiable pour effectuer la publication et la recherche de services.
Dans l’architecture de SETHA, ces actions sont effectuées de manière centralisée par le biais d’un annuaire. Ce dernier implémente la spécification UDDI d’un annuaire de services multi-usages. UDDI est une recommandation OASIS qui permet aux clients des services d’effectuer des recherches sur les déclarations de services Web publiées dans un annuaire donné (privés ou publiques) et aux développeurs de publier leurs services en spécifiant toute information relative à leurs interfaces (opérations, pré-requis, conformité à une spécification).
L’implémentation jUDDI2 de la fondation Apache a été retenu pour sa faible charge réseau, sa facilité de déploiement et son adoption dans le milieu industriel.
SETHA utilise l’annuaire jUDDI pour stocker les informations non-seulement syntaxiques, mais aussi sémantiques, liées aux services disponibles sur le réseau (d’une entreprise, d’un champ de bataille, …). Ces informations sémantiques étant alors exprimées par le biais de déclarations de services au format SAWSDL et d’ontologies de référence liées en partie au domaine d’application du service.
Il s’avère malheureusement que la spécification UDDI ne prévoit aucune facilité pour le stockage d’informations sémantiques dans l’annuaire. Pour pallier cette déficience, les développeurs de SETHA ont utilisé les capacités d’extensions du modèle de données UDDI pour mettre au point une correspondance (ou « mapping ») entre les déclarations au format SAWSDL et les structures de données de l’annuaire. Écrire une correspondance entre un domaine A et un domaine B signifie alors que l’on définit un procédé pour représenter toutes les structures de donnée du domaine A dans les structures de donnée du domaine B. Il doit être aussi possible de reconstituer tout ou partie des données de type A à partir des données mappées dans le type B.
Cette correspondance va permettre d’effectuer la transition d’une gestion des services basée uniquement sur la syntaxe et mise en œuvre avec WSDL et UDDI à une gestion basée principalement sur la sémantique et mise en œuvre grâce à SAWSDL et une couche de compatibilité sémantique pour UDDI.
6 Conclusion
Dans son état actuel, cette implémentation constitue la première étape vers la réalisation d’un framework complet de support des SOA sémantiques qui pourrait être réutilisé au sein des activités civiles et militaires du groupe Thales. À maturation, il aurait pour vocation d’être adopté par le plus grand nombre à l’intérieur et à l’extérieur du groupe. Les choix technologiques relatifs à cette plateforme ont été faits dans ce sens : les solutions libres (« opensource » ) et standardisées.
Mais, comme on a pu le voir, certains points demandent à être approfondis, notamment dans le domaine de l’adaptation des données et du raisonnement sur ontologies : les évolutions possibles passent essentiellement par la mise au point de techniques plus puissantes de raisonnement ontologique (inférence logique, alignement d’ontologies, utilisation de logiques plus évoluées comme les logiques floues) et la couverture d’un ensemble plus étendu de situations (des appariements (matching) plus pertinents, une adaptation de données plus robuste). Ces points précis se doivent d’être étudiés avant d’entrer en phase finale d’exploitation du framework SETHA.
Une autre possibilité d’évolution fait parallèlement l’objet de recherches : elle consiste à définir un framework générique de gestion des contraintes fonctionnelles et non-fonctionnelles (telles que la Qualité de Service, QoS) dans les SOA. Le principe étant de garder une approche extensible capable de supporter différents types de raisonnements interchangeables et complémentaires sur ces propriétés et contraintes tout en s’inspirant des travaux déjà réalisés dans le domaine.

V.    Conclusion
Aujourd’hui, les web services sémantiques constituent une voie prometteuse permettant de mieux exploiter les web services en automatisant, autant que possible, les différentes tâches liées au cycle de vie d’un service. Ils apparaissent donc indispensables pour permettre une utilisation effective des web services dans des applications industrielles. Ils posent aujourd’hui un certain nombre de problèmes qui interpellent différentes communautés de recherche aussi bien théorique qu’appliquée. Le nombre de nouvelles revues, le volume important de publications et de projets dédiés à ce thème dénotent une vitalité réelle de ce domaine de recherche émergent.
Cependant, on remarque que la tendance actuelle des communautés de recherche s’intéressant aux web services sémantiques est de ne pas tenir compte explicitement des caractéristiques fondamentales des web services et de l’environnement dans lequel ils doivent s’intégrer. A mon avis, le succès de cette voie de recherche dépendra étroitement de sa capacité, entre autres, à tenir compte des facteurs suivants :
·    Les travaux de recherche devront intégrer le plus possible les caractéristiques des futurs standards actuellement en cours d’élaboration, les éditeurs de logiciels (e.g. IBM, Microsoft…) étant fortement impliqués dans cette tâche. Ils doivent donc s’efforcer d’exploiter/compléter ces futurs standards et non pas ignorer leur existence ou les concurrencer. De la même manière, il est important de bien identifier les contraintes imposées par les fonctions d’entreprise afin de resituer les problématiques de recherche.
·    La volonté d’automatiser n’est certainement pas une voie réaliste. Certains travaux de recherche semblent faire abstraction de la complexité du contexte de l’intégration de par les hypothèses simplificatrices fortes qu’ils imposent dans leurs solutions. En effet, le contexte de l’intégration fonctionnelle est tel que de nombreuses tâches doivent rester à la charge d’humains. Il est, par exemple, illusoire de vouloir automatiser complètement la gestion d’une chaîne logistique.
·    Le concept de sémantique tel que défini dans le contexte du web sémantique, i.e., décrire la sémantique de manière à la rendre intelligible pour les machines, semble trop restrictif. En effet, il est également très important d’expliciter la sémantique des web services en vue de faciliter leur utilisation par les humains, même pour les situations où l’automatisation ne semble pas réaliste. Il est notoire que dans le domaine des bases de données par exemple, les modèles sémantiques (e.g., le modèle Entité/Association) ont été proposé à l’origine pour faciliter la compréhension de la sémantique des données d’un système d’information par les humains. Ces modèles se sont avéré très utiles par la suite pour automatiser partiellement le processus de conception d’une base de données.

GLOSSAIRE

.NET    Microsoft .NET Framework
BPEL    Business Process Execution Language
C#    C Sharp
COM    Component Object Model
DAML    DARPA Agent Markup Language
DARPA    Defense Advanced Research Projects Agency
DIANE    DIstributed ANalysis Environment
EAI    Enterprise Application Integration
ebXML    e-Business XML
Ecrm    Electronic Customer Relationship Marketing
EJB    Enterprise JavaBeans
J#    J Sharp
J2EE    Java 2 Entreprise Edition
Juddi    Java implementation of the Universal Description, Discovery, and Integration
ODESWS    A Toolset for Design and Composition of Semantic Web Services
OWL    Web Ontology Language
OWL-S    Semantic Markup for Web Services
QoS    Quality of service
RDF    Resource Description Framework
RDFS    Resource Description Framework Schema
SAWSDL    Semantic Annotations for WSDL
SESMA    Special Event Search and Master Analysis
SETHA    Semantic THALES
SOAP    Simple Object Access Protocol
UDDI    Universal Description Discovery and Integration
URI    Uniform Resource Identifier
W3C    World Wide Web Consortium
WS-BPEL    Web Services Business Process Execution Language
WSDL    Web Services Description Language
WSMO    Web Service Modeling Ontology
XML    Extensible Markup Language

BIBLIOGRAPHIE
1. B. Benatallah , M-S. Hacid, C. Rey & F. Toumani (2003). Semantic Reasoning for Web Services Discovery, WWW Workshop on E-Services and the Semantic Web, Budapest, Hungary.

2. Burstein M., Ankolenkar A., Paolucci M., Srinivasan N. et al.; “OWL-S: Semantic Markup for Web Services”; http://www.daml.org/services/owl-s/1.0/owl-s.pdf

3. ebXML : Enabling a global electronic market http://www.ebxml.org/geninfo.htm

4. McGuinness D.L. and van Harmelen; “OWL Web Ontology Language Overview”; http://www.w3.org/TR/owl-features/, Août 2003, World Wide Web Consortium - Candidate Recommendation.

5. McGuinness DL., van Harmelen F. et al, OWL Web Ontology Language Overview, W3C Recommendation, 2004.

6. Sabri Boutemedjet (2004).Web sémantique et eLearning. Cours IFT6251 Université de Montréal

7. SAWSDL Working Group. Semantic Annotations for WSDL. W3c working draft, The World Wide Web Consortium (W3C), Sept. 2006. http://www.w3.org/TR/2006/WD-sawsdl-20060928/.

8. Une architecture pour la découverte et l’orchestration de services Web sémantiques Thales Communications France, Laboratoire d’Informatique de Paris VI (LIP6). Pierre Châtel.

9. W3C recommandation, « Recommandation Web Services Description Language (WSDL). Part 1 : Core Language » : http://www.w3.org/TR/wsdl20

10. W3C World Wide Web Consortium; “SOAP Version 1.2 Part 1: Messaging Framework“; Disponible à : http://www.w3.org/TR/soap12-part1/

11. WSDL4J Project Homepage. Web Services Description Language for Java Toolkit (WSDL4J) v. 1.5, 2005. http://sourceforge.net/projects/wsdl4j.

Catégories: Web 3.0

Specification et Recherche Sémantique de Services WEB

Navigation

Recherche