Courtage sémantique de services de calcul

Descriptions possibles et méthodes de comparaison associées

Différentes approches existent pour la description et le courtage de services. Une étude pour la réutilisation de code a été effectuée dans [MMM98]. Dans ce chapitre, nous reprendrons certaines des descriptions étudiées dans cet article, mais nous en décrirons également d’autres. En effet, cet article date de 1998 et de nouvelles techniques ont vu le jour depuis. Notamment, l’apparition des web services a fait naître de nouveaux besoins et de nouvelles solutions. Un web service est un composant réalisé dans un langage quelconque, déployé sur une plate-forme quelconque et enveloppé dans une couche standard exprimée en XML. Il peut être découvert et invoqué dynamiquement par d’autres services. Afin que cette découverte et cet appel soient réalisables, une description doit être ajoutée à ce web service. L’ensemble s’intègre dans le web sémantique. Cette description se fait initialement à l’aide de WSDL4 (Web Services Description Language) qui est une approche basée sur les signatures, et/ou RDF5 (Resource Description Framework) [LS99] et UDDI6 qui sont des approches par mots-clés. Pour pallier le manque de précision de ces descriptions, des ontologies ont été développées pour exprimer la signification des mots-clés et des relations 4http://www.w3.org/TR/wsdl 5http://www.w3.org/RDF/ 6http://www.uddi.org 4 Introduction qui les lient. DAML+OIL7 et OWL8 [MvH04] sont des langages utilisés pour décrire ces ontologies. Nous retrouvons cette approche par signature dans les approches classiques des langages de programmation, des composants, des types abstraits, des modules, … Cette information peut également être enrichie de mots-clés pour apporter une information complémentaire. Il existe d’autres descriptions plus formelles comme les spécifications algébriques, la logique de Hoare, qui permet d’exprimer la sémantique par des relations logiques entre les paramètres et les résultats. Nous nous intéresserons plus particulièrement à la description par spécifications algébriques, qui est celle que nous avons adoptée. Les différentes descriptions seront développées sur l’exemple suivant, où les lettres majuscules désignent des matrices et les lettres grecques des scalaires. Les services disponibles seront : – serv1(matrix A,matrix B) = A + B – serv2(matrix A,matrix B) = A ∗ B – serv3(matrix A,matrix B,matrix C,matrix D) = A ∗ B + C ∗ D – serv4(real α,matrix A) = α ∗ A 

Les signatures et isomorphismes de types

 Les caractéristiques des services les plus faciles à obtenir sont le nombre et le type des entrées (paramètres) et sorties (résultats). La plupart des langages de programmation proposent de définir les signatures des méthodes dans une interface. En Corba9 , par exemple, les interfaces sont exprimées en IDL10 (Interface Definition Language) et des mécanismes d’introspection d’interfaces (DII et DSI [GGM99]) permettent la découverte des signatures des services disponibles. La signature des services est une information importante que doit contenir la description d’un service. En effet, si le service est invoqué avec des types incompatibles avec la signature, il y aura une erreur. 

Technique de description 

 IDL (CORBA) En IDL, l’interface décrivant les services de notre exemple s’écrit de la façon suivante : matrix serv1(in matrix A, in matrix B) ; matrix serv2(in matrix A, in matrix B) ; matrix serv3(in matrix A, in matrix B, in matrix C, in matrix D) ; matrix serv4(in real alpha, in matrix A) .

 Technique de description : WSDL (Web Services) 

Dans le cas des web services, un fichier WSDL (Web Services Description Language) est utilisé pour décrire les types des paramètres d’entrée et de sortie. Le fichier suivant est un extrait du fichier WSDL engendré à l’aide d’Axis11 pour décrire les entrées et les sorties des services 1 et 2. Pour simplifier le fichier et ne pas avoir à gérer le mapping des données, les matrices ont été remplacées par des entiers. … Les noms des services et des paramètres sont présents dans des balises de la forme : Les types des paramètres sont présents dans des balises de la forme : … Le type de retour est présent dans une balise de la forme : 11http://ws.apache.org/axis/ 6 Introduction Les types possibles sont ceux définis à l’aide des balises « simpleType » et « complexType » de XSD (XML Schema Definition)

Technique de comparaison : Isomorphismes de type 

De nombreux travaux ont été réalisés pour trouver un nom de service dans une librairie à partir de la signature du service recherché. Citons par exemple [Rit89, RT89, ZW93]. Ces travaux soulignent l’importance de ne pas se limiter à une correspondance exacte des types. En effet, la fonctionnalité du service est la même si l’ordre des paramètres du service est permuté. Mais, il peut également être intéressant de proposer des services dont la signature se rapproche de celle recherchée sans être, pour autant, exactement identique. Dans le cas de systèmes polymorphes, il peut aussi être intéressant de renvoyer des signatures plus générales que la requête. Les travaux existants permettent par exemple de retrouver le service 4 à partir des recherches des signatures suivantes : – (real,matrix) → matrix – (matrix,real) → matrix – matrix → (real → matrix) – real → (matrix → matrix) – . . . Dans [ZW93], une procédure pour rechercher des modules représentés sous la forme d’un ensemble de services est proposée. Elle est, elle aussi, relaxée pour pouvoir trouver une sous partie du module. Dans [DPR05], les auteurs proposent de retrouver une interface dans le contexte d’un langage objet. Ils se placent donc dans le cadre de types récursifs avec sous-typage et d’un produit cartésien associatif et commutatif. Cette recherche des types isomorphes est réalisée à partir d’un ensemble figé d’équations sur les types. Des propriétés telles que la commutativité dans les paires pourront être décrites, mais si un nouveau type est ajouté (comme les triplets), l’intégralité de l’algorithme de comparaison doit être reconstruit