DECOUVERTE DES WEB SERVICES

Transcription

UFR Informatique &
Mathématiques Appliquées
LSR - ADELE
ECOLE DOCTORALE
MATHEMATIQUES, INFORMATIQUE,
SCIENCES ET TECHNOLOGIES DE L’INFORMATION
Master Mathématiques Informatique
2e année, Recherche
Spécialité Systèmes d'Information
Découverte et Sélection de Services Web
pour une application Mélusine
Projet présenté par :
Ricardo DE LA ROSA-ROSERO
Soutenu le 15 septembre 2004 à Genève (Suisse)
Sous la direction de :
Jacky Estublier
Jury :
M. Jacky Estublier
Mme Marie-Christine Fauvet
M. Michel Léonard
M. Jean Moscarola
M. Alain Spalanzani
Effectué au laboratoire Logiciels, Systèmes et Réseaux
de l’Institut d’Informatique et de Mathématiques Appliquées de Grenoble
Au sein de l’équipe Adèle
2
REMERCIEMENTS
Je tiens à remercier :
Madame Marie-Christine Fauvet Professeur à l’Université Joseph Fourier.
Messieurs Michel Léonard Professeur à l’Université de Genève, Jean Moscarola
Professeur à l’Université de Savoie, Alain Spalanzani Professeur à l’Université Pierre
Mendès France , pour avoir accepté de faire partie de mon jury.
Monsieur Jacky Estublier, Professeur à l’Université Joseph Fourier (France) et
Directeur Scientifique de l’équipe ADELE, pour m’avoir accueilli au sein de son équipe et
pour m’avoir suivi et conseillé dans mon travail.
Monsieur Jorge Villalobos, Professeur à l’Université De los Andes (Colombie),
pour m’avoir conseillé dans mon travail et par son soutien moral.
Monsieur German Vega, doctorant de l’Université Joseph Fourier (France), pour
m’avoir aidé dans mon travail et par son amitié.
Merci à Fernando De la Rosa, mon frère, par son aide professionnel et par son
soutien moral.
Merci à mon épouse Pilar par sa compagnie, son soutien moral et professionnel.
Merci au tous mes amis de l’équipe ADELE : Sonia Jamal, Kacem Guellil, Olivier
Ducas, Tam Nguyen-Thi et Laurent Francou par leur amitié.
3
4
RESUME
Actuellement, les entreprises ont commencé à utiliser la technologie de services web
pour l'intégration B2B (i.e. intégration Business to Business). Les applications qui
utilisent ces technologies, ont des liaisons fixes aux services web. Ce schéma n’a pas
en compte de l'existence d'autres services avec une meilleure qualité de service. Dans
ce travail nous proposons une architecture et une stratégie pour la découverte, la
sélection dynamique, la substitution et l’invocation de services web par une application
cliente de type Mélusine.
Nous nous appuyons pour la découverte dans un ensemble de registres UDDI. Chaque
registre UDDI fourni information des services d’un domaine particulier.
Nous utilisons un modèle de points et de poids pour un ensemble de paramètres de
QdS (i.e. Qualité de Service) pour la sélection du meilleur service web.
Les paramètres de QdS sont définis selon les besoins des applications clientes.
L’administrateur d’une application cliente choisit les paramètres de QdS qui doivent
peser le plus au moment de sélectionner le meilleur service web.
La stratégie est basée sur qu’au début on choisit le meilleur fournisseur d’un service
web. Ce fournisseur continue d’être invoqué jusqu'à ce que sa QdS diminue au-dessous
du seuil. A ce moment la, on fait un « pooling » pour déterminer la disponibilité des
autres fournisseurs de service web en question. Après, on fait à nouveau une sélection
pour choisir le meilleur parmi les candidats. Ce processus se répète comme au début.
Finalement, comme mécanisme de tolérance aux pannes, notre architecture permet la
sélection et la substitution entre services web équivalents1. Une application cliente peut
substituer un service web en panne par un autre équivalent et disponible.
1
Deux services web sont équivalents s’ils implémentent la même fonctionnalité avec des
interfaces égales ou différentes.
5
6
TABLE DES MATIERES
Chapitre 1
1.1
1.2
1.3
INTRODUCTION ....................................................................................... 11
MOTIVATION ............................................................................................................ 11
CONTEXTE ............................................................................................................... 11
ORGANISATION DU RAPPORT.................................................................................... 11
Chapitre 2
ETAT DE L'ART ET DE LA PRATIQUE................................................... 13
2.1 DEFINITION ET DESCRIPTION DE SERVICE WEB ......................................................... 13
2.2 PRINCIPALES TECHNOLOGIES DE DEVELOPPEMENT DE SERVICES WEB ...................... 13
2.2.1 XML – eXtensible Markup Language .................................................................. 13
2.2.2 SOAP : Simple Object Access Protocol .............................................................. 15
2.2.2.1 Modele d’échange de messages en SOAP ..................................................... 15
2.2.2.2 Enveloppe SOAP ............................................................................................. 16
2.2.2.3 En-tête SOAP................................................................................................... 16
2.2.2.4 Corps SOAP..................................................................................................... 17
2.2.3 Apache-Axis: Une mise en oeuvre de SOAP ...................................................... 18
2.2.4 WSDL : Web Services Description Language..................................................... 18
2.2.5 UDDI : Universal Description Discovery and Integration..................................... 19
2.3 LES THEMES DE RECHERCHE ACTUELS ..................................................................... 19
2.3.1 La sélection des services Web............................................................................ 20
2.3.1.1 Qualité de Service (QdS) liée au Temps d'exécution....................................... 22
2.3.1.2 Qualité de Service (QdS) liée au transactions ................................................. 23
2.3.1.3 Qualité de Service (QdS) liée a la gestion de la configuration et coût ............. 23
2.3.1.4 Qualité de Service (QdS) liée à la sécurité ...................................................... 24
2.3.2 La découverte des services Web ....................................................................... 24
2.3.2.1 OWL-S : Ontology Web Language - Service ................................................... 24
2.3.2.2 Web Services Dynamic Discovery ................................................................... 25
2.3.2.3 Web Service Discovery Architecture................................................................ 26
2.3.3 La substitution des services Web........................................................................ 28
2.4 CONCLUSION RECHERCHE DU SUJET........................................................................ 32
Chapitre 3
MELUSINE : LA TECHNOLOGIE DE L’APPLICATION CLIENTE.......... 33
3.1 SCHEMA DE COMPOSITION ....................................................................................... 33
3.2 MATERIALISATION DES CONCEPTS PARTAGES ........................................................... 34
3.3 CONTROLE DE LA COORDINATION ............................................................................. 35
3.3.1 Autorité commune ............................................................................................... 35
3.3.2 Contrôle de la coordination ................................................................................. 36
3.4 UN EXECUTANT VU COMME UN PARTICIPANT ............................................................. 36
3.4.1 Les sortes d’exécutants ...................................................................................... 36
3.4.2 Le concept de rôle............................................................................................... 37
7
3.4.3
Le concept d’adaptateur...................................................................................... 37
Chapitre 4
LA PROBLEMATIQUE ET NOTRE APPROCHE..................................... 40
4.1 LA DECOUVERTE ET LA SELECTION DES SERVICES WEB ............................................. 40
4.1.1 Architecture et Stratégie pour la découverte et la sélection des services Web... 40
4.1.1.1 Objectifs ........................................................................................................... 40
4.1.1.2 Hypothèses ...................................................................................................... 40
4.1.1.3 Architecture ...................................................................................................... 41
4.1.1.4 Stratégie d’Invocation par une Application Cliente........................................... 43
4.1.2 Modèle de Sélection des Services Web.............................................................. 44
4.1.2.1 La mesure de la Qualité de Service d’un fournisseur d’un service web........... 50
4.1.2.2 Fournisseur Sélectionné .................................................................................. 51
4.1.3 Exemple de Sélection ......................................................................................... 51
4.2 PROBLEME DE LA REPRISE APRES PANNES ................................................................ 52
Chapitre 5
5.1
DESCRIPTION DE L’OUTIL POUR INVOQUER UN SERVICE WEB DANS MELUSINE............ 54
Chapitre 6
6.1
6.2
REALISATION .......................................................................................... 54
BILAN ET PERSPECTIVES ..................................................................... 56
BILAN..................................................................................................................... 56
PERSPECTIVES.................................................................................................... 56
Chapitre 7
BIBLIOGRAPHIE ...................................................................................... 58
8
TABLE DES ILLUSTRATIONS
Figure 1 - Structure d’un message SOAP....................................................................... 16
Figure 2 – La spécification d’un service Web avec WSDL [1]......................................... 18
Figure 3 – Un nouveau modèle de registre et découverte de services web [9] .............. 20
Figure 4 – Niveau supérieur de l’ontologie OWL-S [42].................................................. 25
Figure 5 – Architecture de Web Services Dynamic Discovery........................................ 26
Figure 6 – Reference VISPO architecture [3].................................................................. 30
Figure 7 – Coordination comme un moyen de composition [8]....................................... 33
Figure 8 – Synchronisation par l’univers commun [8] ..................................................... 34
Figure 9 – Univers commun contrôle par l’autorité commune [8].................................... 35
Figure 10 – Depuis le coordinateur vers l’exécutant [8] .......................................................... 38
Figure 11 – Adaptateur pour un exécutant distant [8] ..................................................... 38
Figure 12 – Architecture pour la découverte et la sélection des SW .............................. 41
Figure 13 – Fonction pour transformer le temps moyen entre pannes à valeur de QdS .. 47
Figure 14 – Valeur du paramètre est directement proportionnelle à la QdS..................... 48
Figure 15 – Fonction pour transformer le temps de réponse à une valeur de QdS.......... 49
Figure 16 – Valeur du paramètre est inversement proportionnelle à la QdS.................... 50
Figure 17 – Exemple de sélection avec dix paramètres de QdS .................................... 52
Figure 18 – FedeEditor, option pour ajouter un outil de type Service Web..................... 54
Figure 19 – FedeEditor, option pour générer le mandataire ........................................... 55
9
10
Chapitre 1 INTRODUCTION
1.1
Motivation
Depuis la décennie d'eux 70s les applications d’une entreprise se communiquent avec
les systèmes d’information de ses entreprises fournisseurs ou clients. Cette intégration
s’appelle intégration B2B. Dans un sens technologique, l’intégration B2B se réfère à « la
technologie de logiciel pour connecter n’importe quel système d’information dans des
entreprises à tous ses associés de commerce sur des protocoles formels d’échange de
messages » [36]. Ces protocoles s’appellent protocoles B2B. Exemples de ces
protocoles sont EDI [37] et RossetaNet [38].
Actuellement, la technologie de services web a permis que une entreprise se peut
intégrer à ses associés de commerce de façon rapide et avec un bas coût. Par exemple,
l’entreprise amazon.com qui vend livres et autres produits sur internet. Cette entreprise
se peut intégrer a ses fournisseur en utilisant les services web [1]. Les applications qui
utilisent ces technologies, ont des liaisons fixes aux services web. Ce schéma n’a pas
en compte de l'existence d'autres services avec une meilleure qualité de service.
1.2
Contexte
Notre intérêt se focalise sur une application cliente de type Mélusine [8] qui exécute
dans l’intranet d’une entreprise. Cette application a besoin d’invoquer un ensemble de
services web fournis pour autres entreprises. Pour faciliter la découverte des services
web, il y a un ensemble de registres UDDI. Chacun de ces registres UDDI fournit les
services d’un domaine spécifique. Par exemple, on peut avoir un registre UDDI pour
services de transport aérien, et autre registre pour services de transport ferroviaire.
1.3
Organisation du Rapport
Ce document est organisé en 7 chapitres. Le chapitre 2 étudie l’état de l’art et de la
pratique. Ce chapitre débute par l’étude du concept de service web. Nous décrivons les
technologies sur lesquelles reposent les services web. De plus, nous dépeignons les
travaux de recherche principaux lies à la découverte, la sélection et substitution des
services web ; aussi à la reprise après pannes de une application client.
Le chapitre 3 montre la technologie de l’application cliente, c’est-à-dire le système
Mélusine. Nous décrivons sa architecture et ses mécanismes de coordination. De plus,
nous montrons ses mécanismes pour intégrer composants distants. Ces mécanismes
seront utilisés pour intégrer des services web.
Le chapitre 4 défine la problématique de la découverte, la sélection et la substitution des
services web. Aussi, le probléme de la reprise après pannes du application client est
étudié. Ce chapitre décrit l’architecture, la stratégie et les modèles proposés pour
aborder la problématique.
Le chapitre 5 montre la partie implémentée de la solution proposé.
11
Enfin, le chapitre 6 conclut ce mémoire. Il dresse le bilan et donne les perspectives de
ce travail autour de la découverte, sélection, et substitution des services web dans le
environnement d’une application Mélusine.
12
Chapitre 2 ETAT DE L'ART ET DE LA PRATIQUE
Avec l'essor du web qui a eu dans les dernières années, il a surgi le besoin de permettre
qu'une application client invoque un service d'une application serveur en utilisant
Internet. Ce besoin a été l'origine de ce qui se connaît comme services web. En tenant
en compte que les services web permettent de connecter des applications différentes,
l'utilité de cette technologie devient évidente et importante. Pour cette raison les activités
de recherche et développement autour du sujet services Web ont un dynamisme très
haut. Dans ce chapitre on décrit les technologies plus liés au services Web.
2.1
Définition et description de Service Web
Le groupe de W3C qui travaille sur les services Web a utilisé dans un document appelé
« Web Services Architecture » la définition de service Web suivante [11]:
« Un service web est un système logiciel destiné à supporter l’interaction ordinateur–
ordinateur sur le réseau. Il a une interface décrite en un format traitable par l’ordinateur
(e.g. WSDL). Autres systèmes réagissent réciproquement avec le service web d’une
façon prescrite par sa description en utilisant des messages SOAP, typiquement
transmis avec le protocole http et une sérialisation XML, en conjonction avec d'autres
standards relatifs au web ».
2.2
Principales technologies de développement de Services Web
Une caractéristique qui a permis un grand succès de la technologie des services web
est qu'elle est construite sur des technologies standards de la industrie. Dans cette
section il y a une description de ces technologies [18].
2.2.1 XML – eXtensible Markup Language
XML « eXtensible Markup Language » est un format texte simple, très flexible tiré du
SGML (l'ISO 8879). À l'origine conçu pour la publication électronique à grande échelle,
XML joue aussi un rôle de plus en plus important dans l'échange d'une large variété de
données sur le Web et ailleurs.
W3C recommande depuis 1998 XML en tant que standard de description de données.
XML est un méta langage permettant d’identifier la structure d’un document. Un
document est composé d’une définition de sa structure et d’un contenu. La structure
d’un document XML est souvent représentée graphiquement comme un arbre. La racine
du document constitue le sujet du document, et les feuilles sont les éléments de ce
sujet. De ce fait, XML est alors flexible et extensible, et est devenu rapidement le
standard d’échange de données sur le web [18].
Nous allons prendre un exemple simple pour visualiser graphiquement quelle serait la
hiérarchie du document XML correspondant et quelle est la structure du document.
L’exemple choisi est celui d’un CD, élément racine du document, représenté par son
titre, son artiste, sa société, le pays de la société, son prix et son année; tous les
éléments du document XML. Le pays de la société est optionnel. L’artiste est lui même
constituée d’un nom, un prénom et un site web. Le document XML devra suivre le
13
schéma décrit ci-dessus. Cet exemple de document XML définit le CD "Tournée
d’enfer", de l’artiste Renaud Létang (http://www.renaud.com), de la société française
EMI MUSIC, son prix est 11 Euros et l’année est 2004.
Le schéma XML (nommé cd.xsd) en correspondance avec la définition est la suivante(cf.
Extrait de code 1) :
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema
xmlns
:
xs
=
"http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name= "CD">
<xs:annotation>
<xs:documentation>
Un CD a un titre, une artiste, un pays, une société, un
prix et une année
</xs: documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="titre" type="xs:string" />
<xs:element name="artiste">
<xs:complexType>
<xs:sequence>
<xs:element name="nom" type="xs:string" />
<xs:element name="prénom" type="xs:string" />
<xs:element name="siteweb" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="société" type="xs:string" />
<xs:element
name
=
"pays"
type
=
"xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="prix" type="xs:string" />
<xs:element name="année" type="xs:integer" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Extrait de code 1 Schéma XML: cd.xsd
Le fichier XML (nommé cd.xml) donné dans l’Extrait de code 2, instancie le CD défini audessus:
14
<CD>
<titre>Tournée d’enfer</titre>
<artiste>
<nom>Létang</nom>
<prénom>Renaud</prénom>
<siteweb>http://www.renaud.com</siteweb>
</artiste>
<société>EMI MUSIC</société>
<pays>France</pays>
<prix>11</prix>
<year>2004</year>
</CD>
Extrait de code 2 Fichier XML: cd.xml
XML possède une galaxie de technologies. Parmi celles-ci nous pouvons citer XML
Query (langage de requêtes) [10], XSL – eXtensible Stylesheet Language (définition de
présentations de documents XML) [12] , XSLT – XSL Transformations (langage
permettant la transformation de documents XML) [12] , XPath – XML Path (langage de
requêtes permettant d’accéder à chaque élément d’un document XML) [13].
2.2.2 SOAP : Simple Object Access Protocol
SOAP est un protocole pour l’échange d’information dans un environnement repartie,
basé sur le standard XML. Ce protocole consiste en trois parties : une enveloppe qui
définit un caneva pour décrire le contenu du message et comment le traiter, un jeu de
règles de codage à exprimer les cas de types de données défini par l’application et une
convention pour représenter des appels de procédure éloignés (RPC’s) et ses réponses.
[35].
SOAP n’est pas lié à aucun système d’exploitation ni langage de programmation. Il est
indépendant du langage d’implémentation des applications client et serveur. En plus, il
peut potentiellement être utilisé avec une variété de protocoles (e.g. HTTP, HTTP
Extension Framework).
2.2.2.1 Modele d’échange de messages en SOAP
Les messages SOAP sont des transmissions fondamentalement à sens unique d'un
expéditeur à un récepteur. Lorsqu’une transmissions d’un message commence (e.g.
invocation d’un service web), un message SOAP (ou document XML) est génère. Ce
message est envoyé à partir d’une entité appèle le SOAP sender, localisé dans un
SOAP nœud. Le message est transmis à zéro ou plusieurs nœuds intermédiaires
(SOAP intermediates) et le processus fini lorsque le message arrive au SOAP receiver.
Le chemin suivi par un message SOAP est nomme message path. La figure 1 montre
les éléments qui participent au processus.
Quand un message SOAP arrive dans une entité SOAP, suivi le processus décrire cidessous :
1. Identifier toutes les parties du message SOAP destiné à cette entité.
2. Vérifiez que toutes les parties obligatoires identifiées dans le pas 1 sont soutenues
par l’entité et traitez-les en conséquence. Si ce n'est pas le cas rejeter le message.
15
3. Si l’entité n'est pas la destination suprême du message enlèvent alors toutes les
parties identifiées dans le pas 1 avant l'expédition du message.
Le traitement d'un message ou une partie d'un message exige que le processeur de
SOAP comprenne, parmi d'autres choses, le modèle d’échange étant utilisé (e.g. sens
unique, multicast), le rôle du destinataire dans ce modèle, l'emploi de mécanismes
RPC, la représentation ou le codage de données, aussi bien que d'autre sémantique
nécessaire pour traitement correct.
Figure 1 - Structure d’un message SOAP
2.2.2.2 Enveloppe SOAP
Un message SOAP est composé d’un élément obligatoire appèle le SOAP enveloppe.
L’enveloppe SOAP définit l’espace de nom (namespace : URI permettant de connaître la
provenance de chaque balise) précisant la version supportée de SOAP. Cet espace de
nom est standard et permet de différencier les éléments du schéma (e.g.
http://www.w3.org/2001/06/soap-envelope/).
L’enveloppe SOAP est constitué une en-tête facultatif (SOAP header) et d’un corps
obligatoire (SOAP body). Une description général du enveloppe SOAP et ses
composants est donnée par l’Extrait de code 3.
2.2.2.3 En-tête SOAP
L’en-tête peut avoir plusieurs fils (SOAP blocks). Ces fils sont utilisés pour ajouter
fonctionnalité au message comme l’authentification et la gestion des transactions. L’entête peut utiliser les attributs mustUnderstand et/ou SOAP actor pour indiquer comment
traiter l'entrée et par qui.
L'attribut mustUnderstand peut être utilisé pour indiquer si une entrée d’en-tête est
obligatoire ou facultative pour être traiter par le destinataire. Le destinataire d'une entrée
d’en-tête est défini par l'attribut d'acteur de SOAP (décrit dans la partie suivant). La
valeur de l'attribut de mustUnderstand est "1" ou "0". L'absence de cet attribut est
sémantiquement équivalente à sa présence avec la valeur "0".
16
Un message SOAP voyage du SOAP sender au SOAP receiver, en passant par un
groupe de SOAP intermédiaires. Un SOAP intermédiaire est une entité qui est capable
de recevoir et transmettre les messages SOAP. Les nœuds intermédiaires aussi bien
que le SOAP receiver sont identifiés par un URI. Non toutes les parties d'un message de
SOAP peuvent être traites pour le SOAP receiver du message, mais, au lieu de cela,
peuvent être traites pour un ou plusieurs des intermédiaires sur le chemin de message.
Un destinataire recevant un élément d'en-tête ne doit pas transmettre cet élément à le
suivant entité SOAP (intermédiaire ou receiver). L'attribut acteur de SOAP peut être
utilisé pour indiquer le destinataire d'un élément d'en-tête. La valeur de l'attribut d'acteur
de SOAP est un URI. Par exemple, URI "http: // schemas.xmlsoap.org/soap/actor/next"
indique que l'élément d'en-tête est destiné à la première entité SOAP qui traite le
message.
2.2.2.4 Corps SOAP
Le corps SOAP contient l’information destinée au receveur. Il doit fournir le nom de la
méthode invoquée par une requête, ou le nom de la méthode pour générer la réponse. Il
doit aussi, fournir l’espace de nom correspondant au nom du service. Le contenu du
corps SOAP est utilisé dans processus comme le marshaling d’appels RPC et le rapport
des erreurs.
Le corps SOAP peut contenir un SOAP fault. Ce bloque est utilisé pour transmettre
l’information des erreurs durant le traitement du message.
Malgré que l'en-tête et le corps sont définis comme des éléments indépendants, ils ont
une relation : une entrée de corps est sémantiquement équivalente à une entrée d'entête destinée pour l'acteur de défaut et avec une valeur d'attribut mustUnderstand de 1.
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope/">
<env:Header>
<authentication xmlns=http://myDomain/app” >
<user>delarosa</user>
<password>********</password>
</authentication>
</env:Header>
<env:Body>
<stock: getStockQuoteResponse
xmlns: stock=”http://www.acme.com/service”>
<stock_quote>
…
</stock_quote>
</stock: getStockQuoteResponse
</env:Body>
</env:Envelope>
Extrait de code 3 - Définition type d’enveloppe SOAP
17
2.2.3 Apache-Axis: Une mise en oeuvre de SOAP
Axis est essentiellement un moteur de SOAP [39]. Une structure pour construire des
processus de SOAP comme des clients, des serveurs, des « gateways », etc. La version
actuelle d'Axis est écrit en Java, mais la mise en œuvre C ++ du côté client d'Axis est
développé. Mais, Axis n'est pas juste un moteur de SOAP, il inclut aussi :
•
•
•
•
•
•
•
Un serveur autonome simple.
Un serveur que branche dans des moteurs servlet comme Tomcat.
Appui vaste pour WSDL.
L'outillage d'émetteur (i.e. WSDL2Java) qui produit des classes Java à partir du
fichier WSDL.
L'outillage d'émetteur (i.e. Java2WSDL) qui produit le fichier WSDL à partir de la
classe de l’interface Java.
Un outil pour surveiller des paquets de TCP/IP, et
Quelques programmes exemple.
2.2.4 WSDL : Web Services Description Language
WSDL est un langage qui permet de décrire les services web, et en particulier, les
interfaces des services web. Ces descriptions sont documents XML. WSDL décrit un
service web en deux étapes fondamentales : une abstraite et une concrète. Dans
chaque étape, la description utilise un nombre constructions pour favoriser la
réutilisation de la description et pour séparer les préoccupations de conception
indépendantes (Figure 2).
Figure 2 – La spécification d’un service Web avec WSDL [1]
18
Au niveau abstrait, WSDL décrit un service Web en termes des messages qu'il envoie et
reçoit; les messages sont décrits de façon indépendante d'un format spécifique de fil en
utilisant un système de types, typiquement un schéma XML. La partie abstraite est
composée de définitions de "port type" qui sont analogues aux interfaces dans les IDLs
du "middleware"
traditionnel. Chaque "port type" est une collection logique
d'opérations. Une "operation" (i.e. opération) associe un modèle d'échange de message
à un ou plusieurs messages. Un message est une unité de communication avec un
service web. Il représente les données échangés dans une unique transmission logique.
Un modèle d'échange de messages identifie l'ordre et la cardinalité des messages
envoyés et/ou reçus. Une interface groupe un ensemble d'opérations.
Au niveau concret, un "binding" indique des détails de format de transport pour une ou
plusieurs interfaces. Un "endpoint" (i.e. point final) associe une adresse de réseau à un
"binding" (i.e. attache). Finalement, un service groupe un ensemble d'endpoints qui
implémente une interface commune.
2.2.5 UDDI : Universal Description Discovery and Integration
L’objectif primaire d'UDDI est la spécification d'un canevas pour décrire et découvrir des
services Web. Le noyau d’UDDI travaille avec la notion de "business registry", que est
un service sophistiqué de noms et répertoires. Plus précisément, UDDI définit des
structures de données et APIs pour publier les descriptions des services dans le registre
et pour interroger le registre afin de chercher des descriptions publiées. Parce que les
APIs de UDDI sont aussi spécifiés en WSDL avec une attache SOAP, le registre peut
être invoqué comme un service Web (en conséquence, ses caractéristiques peuvent
être décrites dans le même registre, comme un autre service).
Les spécifications du « registry » UDDI ont deux buts principaux en ce qui concerne la
découverte d'un service: le premier, soutenir les développeurs dans la découverte
d'informations sur les services. Le deuxième, permettre la liaison dynamique et en
conséquence habiliter les clients pour interroger le registre et obtenir des références aux
services d’intérêt.
De plus pour définir un registre de services Web, UDDI aussi adresse le concept de
Universal Business Registry (UBR). En fait, le but initial du consortium a été de soutenir
des répertoires mondiaux où chacun pourrait publier des descriptions de service et où
chacun pourrait interroger ces répertoires pour trouver les services d'intérêt. L'idée était
qu'UBRS pourrait contenir chaque service déployé dans le monde.
2.3
Les thèmes de recherche actuels
Les actuels sujets de recherche dans le domaine des services web sont nombreux. Un
nombre considérable d'études tournent autour de la découverte des services et ses
sujets rattachés comme sont la sélection et la substitution. Dans cette section nous
allons analyser et décrire les travaux les plus pertinents.
19
2.3.1 La sélection des services Web
Avec la sélection des services web, on cherche à choisir le meilleur fournisseur d'un
service web, étant donné un ensemble de fournisseurs de ce service.
Il y a une proposition de base sur la Qualité de Service (i.e. QdS en anglais Quality of
Service – QoS ) [9]. La plate-forme de cette proposition est un modèle réglé qui peut
coexister avec les registres UDDI dérégulés. Les registres dérégulés actuels peuvent
fournir des services aux gens pour qui la qualité de service n’est pas importante. Les
registres réglés basés sur ce modèle peuvent servir aux applications qui ont besoin de
qualité de service.
Il y a quatre rôles dans ce modèle (Figure 3):
Fournisseur de services web.
Consommateur de services web.
Certificateur de la Qualité de Service.
Et le nouvel registre.
•
•
•
•
Figure 3 – Un nouveau modèle de registre et découverte de services web [9]
Le fournisseur du service offre le service web en publiant ce dernier dans le nouveau
registre; le consommateur a besoin du service web offert par le fournisseur ; le nouvel
registre UDDI est un lieu de stockage de services web enregistrés avec facilités de
recherche. Le nouveau rôle certificateur sert à vérifier la qualité de service du
fournisseur du service. Le nouveau registre est différent du actuel modèle UDDI en
ayant information sur la description fonctionnelle du service web, et sur la qualité de
service enregistré dans le stockage. Les interactions entre les différents rôles sont
montrées dans la figure 3.
La consultation pourrait être faite selon la description fonctionnelle du service web
désirable, avec la qualité exigée de service attribue comme des contraintes de
consultation (Voir extrait de code 4).
20
<?xml version="1.0" encoding=”UTF-8” ?>
<envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<body>
<find_service businessKey="*" generic="1.0"
xmlns="urn:uddi-org:api" maxRows="100">
<findQualifiers></findQualifiers>
<name>Stock quote</name>
<qualityInformation>
<availability>0.9</availability>
</qualityInformation>
</find_service>
</body>
</envelope>
Extrait de code 4 - Requête SOAP pour la découverte de service
Le certificateur QdS vérifie les revendications de qualité de service pour un service web
avant son registre. Les détails du registre du service web, la découverte et l'invocation
sont discutés ci-dessous.
Dans le modèle de Shuping [9], un fournisseur d'un service Web doit fournir des
informations sur la société, les aspects fonctionnels du service fourni conformément à
votre demande par le registre courant UDDI, aussi que fournir la qualité d'informations
de service liées au service Web proposé. La qualité de service doit être certifiée et
enregistrée dans le dépôt.
Le fournisseur du service Web doit d'abord communiquer son QdS revendique au
certificateur de QdS de service Web. Le certificateur vérifie les revendications et certifie
ou pas la revendication. Le résultat est envoyé en arrière au fournisseur avec des
informations d'identification de certification. Ces informations sont aussi enregistrées
dans le dépôt du certificateur identifié par un certification Id. Le certificateur fournit un
jeu de services Web pour tous les partis intéressés, avec le objectif de avoir accès à son
dépôt de revendications de QdS, principalement dans le but de vérification.
Après la certification QdS est publiée et envoyé par le certificateur, le fournisseur se fait
alors inscrire avec le nouveau registre UDDI tant avec la description fonctionnelle du
service qu'avec sa qualité certifiée associée d'informations de service. Le registre UDDI
communique avec le certificateur pour vérifier l'existence de la certification. Après la
vérification couronnée de succès, le registre enregistre alors le service dans son dépôt.
Découverte de Services Web et Invocation selon le Modèle de Shuping [9]
Un consommateur d'un service Web a certain besoin fonctionnel et de qualité de
service, comme "le temps de réponse non plus grand que 2 milli-secondes avec le coût
moins de 10 euros par invocation". Le consommateur cherche dans le registre UDDI un
service Web avec la fonctionnalité exigée comme d'habitude; il peut aussi ajouter des
contraintes à l'opération de recherche. Un type de contrainte est la qualité exigée de
service.
S'il y avait des services multiples du Web dans le registre UDDI avec des fonctionnalités
semblables, donc la qualité de service mettrait en application une recherche plus
détaillé. La recherche rendrait un service Web qui offre la fonctionnalité exigée avec le
jeu désirable de qualité de service. S'il n'y a aucun service Web avec ces qualités, on
donne des réactions au consommateur. Le consommateur peut alors réduire leur
21
contraintes de qualite de service ou le compromis de considération entre les qualités
désirables de service. Une fois qu'un service Web est trouvé, le fichier WSDL et les
informations QdS certifiées sont obtenus par le consommateur. Le consommateur peut
vérifier les revendications de QdS avec le certificateur utilisant l'identificateur de
certification. Une fois que le consommateur est heureux avec leurs découvertes, il peut
invoquer le service Web selon le modèle actuel.
Il y a beaucoup d'aspects de QdS important pour des services Web. Nous commençons
à les organiser dans des catégories QdS. Chaque catégorie doit avoir un jeu de
paramètres quantifiables ou des mesures. Plus loin la recherche est nécessaire dans ce
secteur. Pour des buts d'illustration, les catégories sont définies ici. Elles sont décrites
brièvement, suivi par une question comme un exemple pour montrer quel type de
questions le QdS particulier peut poser. Pour faciliter la description, les catégories sont
groupées dans des types différents, c'est-à-dire QdS lié à temps d'exécution, appui de
transaction, gestion de configuration, coût, et sécurité [9].
2.3.1.1 Qualité de Service (QdS) liée au Temps d'exécution
•
Passage à l’échelle: La posibilité d’incrémenter la capacité des ordinateurs du
fournisseur du service, et l’habilité du système pour traiter plus d'opérations dans un
période donné. Il est relié avec la performance.
Paramètre: Maximum nombre d'invocations par seconde que le système peut exécuter.
• Capacité: Limite de demandes concourantes pour une performance garantie.
Paramètre: Maximum nombre de connexions concourantes que le service peut
supporter.
•
Performance: Une mesure de la vitesse pour exécuter une requête du service. Elle
est mesurée par:
− Temps de réponse: Le temps maximum garanti demandé pour compléter
une requête du service.
− Latence: Temps pris entre l'arrivée de la requête du service et la réponse
émise par le service.
− Débit – capacité d’exécution: Le nombre de requêtes accomplies par le
service pendant une période de temps.
•
Fiabilité: La capacité d’un service d'exécuter ses fonctions dans des conditions
indiquées dans une période de temps spécifié [25]. Elle peut être mesurée par:
− MTBF: “Mean time between failure” - Temps moyen entre pannes.
− MTF: “Mean Time to Failure” - Temps moyen par panne.
− MTTT: “Mean Time To Transition” – Temps moyen pour la transition. Il est
très lie à la disponibilité [6].
•
Disponibilité: Elle est la probabilité que le système soit actif. Elle est lie à la fiabilité.
Elle peut être mesuré comme [6]:
A = < tempsActif > / < tempsTotal >
A = < tempsActif > / ( < tempsActif > + < tempsInactif > )
< tempsActif > est le temps total pendant lequel le système a été actif durant la période
mesurée.
22
< tempsInactif > est le temps total pendant lequel le système a été inactif durant la
période mesurée.
< tempsTotal > est le temps mesuré total, il est la somme de <tempsActif> et <
tempsInactif >.
•
Robustesse / Flexibilité: Elle est le degré dans lequel un service peut
s'exécuter correctement dans la présence des entrées inadmissibles, inachevées ou
contradictoires.
Paramètre: Question – Est-ce que le service fonctionnera si les paramètres envoyés
lors de son invocation sont invalides ?
•
Traitement des exceptions : – Puisqu'il n’est pas possible pour le concepteur
du service de spécifier tout les résultats possibles et alternatifs (particulièrement avec de
divers cas spéciaux et possibilités imprévues), des exceptions peuvent être attendues.
Le traitement des exceptions est comme le service traite ces exceptions. Il peut être
d'une manière brutale ou appropriée.
•
Exactitude: Définit le taux d'erreur produit par le service.
Paramètre: Question – Combien d’erreurs le service produit sur une période de temps ?
2.3.1.2 Qualité de Service (QdS) liée au transactions
Intégrité: Les transactions peuvent être groupées dans une unité pour garantir l'intégrité
des données opérés par ces transactions. L'unité peut être réussie si tout les
transactions dans l'unité « commit », ou tout les transactions « roll back » à l’état original
en cas d’échec de transaction. C'est décrit par les propriétés ACID: l'Atomicité (exécute
entièrement ou pas du tout), la consistance (maintient l'intégrité des données),
l'isolement (des transactions individuelles exécutées comme si aucune autre transaction
n'est présente) et la durée (les résultats sont persistantes).
Le protocole Two-Phase Commit est le mécanisme pour garantir les propriétés ACID
pour des transactions distribuées des systèmes fermement couplés comme s'ils étaient
une transaction simple.
2.3.1.3 Qualité de Service (QdS) liée a la gestion de la configuration et coût
•
Régulateur - c'est une mesure de comme le service est aligné sur des
règlements.
Q: Comment le service est-il aligné avec des règlements appropriés ?
•
Norme Soutenue - une mesure de si le service observe des normes(standards)
(par exemple. Industrie normes(standards) spécifiques). Cela peut affecter la
portabilité du service et de l'interopérabilité du service avec d'autres. Un exemple
est ISO 8583, qui est une norme pour créer et lire des messages de transaction
financiers incluant le Point de vente (POS) des transactions [ISO].
Q: Combien du service adhère-t-il aux normes(standards) applicables ? Ou quelles
normes(standards) le service se soumettent-elles ?
•
Cycle de stabilité/changement - une mesure de la fréquence de changement
lié au service en termes de son interface et-ou mise en oeuvre.
Q: Comment le service est-il stable ? combien de fois il change (l'interface et la mise en
oeuvre) ?
23
•
Coût - C'est une mesure du coût impliqué dans la requête du service.
Q: Comment le coût est basé sur (par demande ou par volume de données) ?
•
Etat complet - une mesure de la différence entre le jeu indiqué de
caractéristiques et le jeu mis en oeuvre de caractéristiques.
Q: Combien de caractéristiques indiquées sont actuellement disponibles ?
2.3.1.4 Qualité de Service (QdS) liée à la sécurité
Il mesure la fiabilité et la sécurité de mécanismes mise en oeuvre.
•
Authentification - Comment le service authentifie-t-il des principaux (des
utilisateurs ou d'autres services) qui peut avoir accès au service et des données ?
•
Autorisation - Comment le service autorise-t-il des principaux pour que seulement
eux puissent avoir accès aux services protégés ?
•
Confidentialité - Comment le service traite-t-il les données, pour que seulement
les principaux autorisés puissent avoir accès ou modifie les données ?
•
Responsabilité - le fournisseur peut-il être responsable par leurs services ?
•
Traçabilité et vérifiabilité – Est-il possible de tracer l'histoire d'un service
lorsqu'une demande a été entretenue.
•
Cryptage des données - Comment le service chiffre-t-il des données ?
Non-reniement - un principal ne peut pas nier(refuser) demander un service ou
•
des données après le fait.
J’ai une observation à la proposition de [9] dans le processus de vérification des
caractéristiques de QdS de la part de l'agent certificateur. La vérification devrait être
faite en utilisant une application de preuves de charge pour des services web. Cette
vérification exige que le service doit offrir des opérations de consultation, parce que,
pour éprouver quelques paramètres (comme le passage à l’échelle, la capacité et la
performance), les preuves sont faites en invoquant ces opérations.
2.3.2 La découverte des services Web
Dans le contexte d’une application qui a besoin d’exécuter une fonctionalité
implementée comme un service web par plusieurs fournisseurs, la découverte fait
référence au processus de recherche des services web implémentant la fonctionnalité
souhaitée. Les registres UDDI sont entités qui servent d’appui à la découverte de
services web pour les applications client. De cette façon une application interroge un
registre UDDI pour les fournisseurs d’un service web.
Dans ce sujet ils se sont trouves trois travaux pertinents : OWL-S (Ontology Web
Language - Service), Web Services Dynamic Discovery et Web Service Discovery
Architecture . Ces travaux sont décrits dans les sections suivantes.
2.3.2.1 OWL-S : Ontology Web Language - Service
OWL-S est un langage qui définit une ontologie de services web [42]. Il est basée sur le
langage OWL[43]. Il permet de réaliser les deux tâches suivantes :
1) Découverte automatique de services web : Cette tâche est possible parce que
OWL-S permet d’exprimer et de résoudre des requêtes avec contenu
sémantique. Par exemple une requête comme : « Trouver des services web qui
24
vendent des tickets d’avion entre deux villes spécifiques et qui permettent de
payer avec une carte de crédit particulière.
2) Invocation automatique de services web : OWL-S fourni un ensemble de APIs
pour que l’invocation à un service web soit automatique.
OWL-S a trois parties principales :
• Le profil du service : Pour faire de la publicité et découvrir des services.
• Le modèle du processus qui donne une description détaillé d’une opération du
service.
• Le « grounding » qui fourni les caractéristiques techniques pour établir la
communication avec le service au moyen de messages.
Figure 4 – Niveau supérieur de l’ontologie OWL-S [42]
2.3.2.2 Web Services Dynamic Discovery
Web Services Dynamic Discovery est une spécification développé par représentants de
Microsoft, Bea Systems, Intel et Canon [24]. L’architecture de cette spécification propose
une entité appelée Mandataire de Découverte (Figure 5).
L’objectif de cette entité est de maintenir l’information des fournisseurs d’un ensemble
de services Web. Cette entité est disponible sur internet. Elle est localisée de manière
indépendante, généralement éloigné, des applications client comme des fournisseurs de
services web.
Lorsqu’un service web commence son exécution, il s’enregistre par-devant le
mandataire de découverte. Avant qu’un service finis son exécution, il manifeste ce fait
au mandataire de découverte. En plus, quand une application client a besoin d’interroger
les fournisseurs d’un service, elle envoie un message multicast à un ensemble de
fournisseurs. Les fournisseurs qui donne le service répondent de une façon affirmatif à
l’application et les autres, répondent de une façon négatif.
Si dans le processus décrire avant, l’application observe un mandataire de découverte,
elle interrompt la communication avec les fournisseurs et commence une communication
directe avec le mandataire de découvert. L’application client le demande au mandataire
de découvert sur les fournisseurs d’un service web spécifique.
25
Figure 5 – Architecture de Web Services Dynamic Discovery
2.3.2.3 Web Service Discovery Architecture
Sur ce problème il y a une approche qui s’appelle WSDA [7]. WSDA (i.e. Web Service
Discovery Architecture) est une architecture ouverte pour la découverte des services
web. WSDA incorpore plusieurs standards comme XML, XML Schéma, SOAP, WSDL
et XQuery. Celle-ci définit services, interfaces (e.g. consumer ), opérations (e.g. publish )
et sa liaison avec des protocoles.
Elle fournit quatre interfaces qui composent l’information nécessaire pour le registre d’un
service web : Presenter, Consumer, MinQuery et XQuery. Une description plus détaille
est la suivante:
•
Presenter : Fourni au client la possibilité de chercher la description la plus récente
du service web. Cette interface a un identificateur qui peut être un URI ou un URL
et un mécanisme de recherche. Dans l'exemple suivant l'URL
“https://registry.cern.ch/getDesc“
est l’identificateur et
http
verb=”GET”
est
le
mécanisme
de
recherche.
En
fin,
XML
getServiceDescription est l’opération qui fourni.
<interface type= ”http://cern.ch/Presenter-1.0” >
<operation>
26
<name> XML getServiceDescription()</name>
<bind: http verb=”GET” URL=“https://registry.cern.ch/getDesc“ / >
</operation>
</interface>
Extrait de code 5 - Une définition de l'interface Presenter
La déclaration de la méthode getServiceDescription est :
XML getServiceDescription() ;
•
Consumer : Permet au fournisseur de contenu de publier le contenu du service
pour être interrogé par le consommateur. Cette fonctionnalité est fournie en
utilisant l’opération publish. Le contenu du service (i.e. la tuple de registre) peut
être la description du service ou de la qualité du service, un fichier, la localisation
d’une copie etc. Cette tuple a comme attribut un content link (e.g. URI ou URL), un
type -le sort de contenu a publier , un context –décrire le pourquoi de la publication
du contenu ou comme il peut être utilisé, quatre soft state time stamps et deux
éléments facultatifs : metadata et content (e.g. secure digital XML signature).
La déclaration de la méthode publish est :
(TS4, TS5) publish(XML tupleset) ;
•
MinQuery : Fourni un support basique d’interrogation “select all”. Cette interface a
deux opérations getTuples et getLinks. La déclaration de ces méthodes est :
XML getTuples() ;
XML getLinks() ;
•
XQuery : Fourni un support pour l’interrogation des services en utilisant XQuery
comme langage de requêtes. query est l’opération fournie par cette interface. Une
requête peut choisir le content du service, mais aussi, les attributs de la tuple (e.g.
context, type). La déclaration de la méthode query est :
XML query(XQuery query) ;
Dans les extraites de code 6, 7 et 8 apparaissent 2 requêtes en utilisant Xquery. Ce
code permet de montrer la capacité de consultation offerte par cette architecture.
Trouver tous les services qui mettent en oeuvre une interface de service de catalogue de
réplique que l'on permet aux membres de CMS d'utiliser et cela a un HTTP liant pour
l'opération de catalogue de réplique "XML getPFNs (String LFN).
LET $repcat := "http://cern.ch/ReplicaCatalog-1.0"
FOR $tuple in /tupleset/tuple[@type="service"]
LET $s := $tuple/content/service
WHERE
SOME $op IN $s/interface[@type = $repcat]/operation
SATISFIES ($op/name="XML getPFNs(String LFN)" AND
$op/bindhttp/@verb="GET" AND
contains($op/allow, "http://cms.cern.ch"))
RETURN $tuple
Extrait de code 6 – Exemple XQuery pour découverte de Services
27
Trouver tous les catalogues de réplique et retourner leurs noms de fichier physiques (PFNs) pour un
nom de fichier logique donné (LFN); supprimer PFNS pas commençant avec "ftp: //".
LET $repcat := “http://cern.ch/ReplicaCatalog-1.0“
LET $s := /tupleset/tuple[@type="service"]
/content/service[interface@type = $repcat]
RETURN
FOR $pfn IN invoke($s, $repcat,
"XML getPFNs(String LFN)",
"http://myhost.cern.ch/myFile")
/tupleset/PFN
WHERE starts-with($pfn, "ftp://")
RETURN $pfn
Trouver tout (le service d'exécution, le service de stockage) des paires où les deux services d'une
paire vivent dans le même domaine. (Le Travail veut lire et écrire localement)
LET $exeType := "http://cern.ch/executor-1.0"
LET $stoType := http://cern.ch/storage-1.0
FOR $exec IN "/tupleset/tuple[content/service/"
interface/@type=$exeType],
$stor IN /tupleset/tuple[content/service/
interface/@type=$stoType
AND domainName(@link) =
domainName($exec/@link)]
RETURN <pair> {$exec} {$storage} </pair>
Dans WSDA une caractéristique très importante est de pouvoir faire des requêtes en
utilisant le langage XQuery, puisque cela est beaucoup plus puissant que le type des
consultations permises par l'API d'UDDI. La deuxième caractéristique est la diversité et
l'utilité(profit) des consultations XQuery offertes par l'architecture. Les extraits de code 6,
7 et 8 sont exemples de cette caractéristique. La troisième caractéristique considère
comme complète, très utile et apparemment facile d'utiliser, la fonctionnalité offerte à
travers des 4 interfaces. Cependant, l'article n'a pas d'exemple de la manière comme
une application client utilise l'API offert.
2.3.3 La substitution des services Web
Il y a besoin de la substitution d’un service web par un autre dans les cas suivantes :
•
Pendant l'exécution, le service web échoue ou ne peut pas être atteint.
•
Il y a un nouveau service web qui fourni un service mieux, en ce qui concerne les
paramètres de qualité de service.
•
Une nouvelle version d'un service web choisi, offert par le même fournisseur est
disponible.
Avec la spécification d’un processus coopératif, le programmeur d'application compose
les services web disponibles, pour satisfaire les exigences données pour un processus
coopératif. Considérant les services web comme des boîtes noires, deux comportements
différents doivent être considérés pour le processus coopératif :
-
Comportement non-observable : il est lié au comportement d'une composition des
services web. Puisque on considère un service web comme une boîte noire, nous
ne pouvons pas modifier sa structure interne, mais seulement utiliser les méthodes
fournies, en utilisant ses spécifications.
28
-
Comportement observable : il est lié a la coopération existante parmi les
organisations qui participent au processus.
Avec la substitution, le but est d'être capable de substituer un service web, si c'est
nécessaire, sans affecter le comportement observable du processus coopératif.
L'approche présentée dans [3], au problème de la substitution, est basée sur l'idée que
les spécifications de services web doivent être classés pour suivre à la trace les
relations entre eux en termes de compatibilité.
Dans ce point de vue les services web sont classés dans deux types :
- Des services web spécifiques pour un district : Orientés aux processus coopératifs du
district.
- Des services web avec propos général : dèfinis pour être utilisés dans beaucoup
d'environnements.
Cette distinction est faite parce que le registre des services maniés dans le district est
contrôlé. À chaque service web du district on lui exige son information syntaxique et son
information sémantique.
La spécification des services web spécifiques de chaque district sont inscrits dans une
version améliorée du registre UDDI, appelé registre VISPO. La connaissance
sémantique de services et le contenu de l'information est organisée dans l'Ontologie de
Service du Domaine et l'Ontologie de Connaissance du Domaine. Dans cet approche
une partie de la spécification d’une méthode d’un service est la pre-condition et la postcondition. Ces deux assertions s’écrivent en utilisant de la logique de premier ordre.
29
Figure 6 – Reference VISPO architecture [3]
Deux acteurs principaux sont impliqués pendant la conception et le temps d'exécution
du processus coopératif : le programmeur de l'application et l'expert du domaine.
Pour le but de substitution, le programmeur de l'application est soutenu par le
Fournisseur de Service de Compatibilité (FSC). Le FSC est un module de l'architecture
VISPO que, dans la surveillance de l'Expert du Domaine : Permet de publier des
services web maintenant la classification nécessaire des spécifications de services web
dans le registre VISPO et dans l'Ontologie de Service de Domaine. Étant donné la
spécification d’un service web, permet de récupérer un service web compatible.
Dans cet approche, deux services web peuvent se substituer seulement s'ils sont
compatibles. D'une telle façon, étant donné un service web et utilisant ces relations il est
possible d'une façon semi-automatique, chercher le service web compatible.
Pour emmagasiner la spécification d'un service, le FSC (i.e. Fournisseur de Service de
Compatibilité) utilise des fichiers WSDL (Voir l’extrait de code 9). En plus, pour faciliter
l'analyse de compatibilité, un descripteur de service est utilisé (Voir l’extrait de code 10).
<types>
<!— needed type definition -->
</types>
<portType name= "DeliverSofa" >
<operation name="ReceiveOrder">
<input message="orderId" />
30
<input message="orderDetails" />
<input message="paymentStatus" />
<input message="numberOfSofas" />
</operation>
<operation name="Monitor">
<input message="orderId" />
<output message="status" />
</operation>
<operation name="Notification">
<output message="orderId" />
<output message="success" />
<output message="refunded" />
</operation>
</portType>
Extrait de code 9 – Exemple spécification d’un service en WSDL
SERVICE
OPERATION
INPUT
INPUT
INPUT
INPUT
OPERATION
INPUT
OUTPUT
OPERATION
OUTPUT
OUTPUT
OUTPUT
DeliverSofa
ReceiveOrder
orderId
orderDetails
numberOfSofas
paymentStatus
Monitor
orderId
status
Notification
orderId
success
refunded
Extrait de code 10 – Exemple descripteur de service
Une fois que les éléments ont eu besoin de découvrir et de stocker les relations de
compatibilité identifiés parmi des services web. Cette approche définit la classe de
compatibilité comme un jeu où tous les services web appartenant peuvent être
substitués par un autre. Tous les services identifiés sont rapprochés d'une description
abstraite qui représente tous les membres de la classe : cette description abstraite est
appelée le service abstrait tandis que les membres sont les services concrets.
Quand les problèmes liés à la substitution surgissent (par exemple un service échoue),
le service concret échoué peut être substitué avec un autre appartenant à la même
classe selon la configuration d'informations, un jeu de règles qui doit être satisfait quand
nous substituons un service web par un autre.
Approche de l’unification entre des spécifications.
Grâce à ce que le problème de la substitution de services web est très pareil au
problème de la substitution de composants logiciels, alors l'approche de [15] est
appropriée pour aborder ce sujet de recherche.
De mon point de vue, les deux formats pour enregistrer la spécification du service sont
redondants. De plus dans cet article, il n'est pas dit d'une forme précise comme
l'ensemble de règles d’équivalence, entre deux services concrets, est enregistré. Je
pense qu'il peut y avoir des cas où exprimer cette équivalence a une très haute difficulté.
Par exemple, s'il y a un service S1 avec N paramètres et ce service va être remplacé
31
par un autre service S2 avec un paramètre en ce que c'est une chaîne avec le format
XML qui a l'information sur les N paramètres dedans (à l'intérieur).
2.4
Conclusion Recherche du Sujet
Par rapport à la sélection de services web, les articles analysés s’appuient sur des
paramètres de Qualité de Service afin de choisir le meilleur candidat. De plus, ils
proposent une amélioration au registre UDDI pour gérer ces paramètres de QdS pour
chaque service web [9]. De cette façon, lorsqu'il y a une application qui cherche un
service web dans un registre UDDI, dans la requête SOAP, il envoie aussi les valeurs
minimales désirées des paramètres de QdS pour ce service. S'il y a des services web
qui accomplissent les exigences de QdS, le registre UDDI retourne le service web qui
accomplit mieux avec les paramètres de QdS.
De mon point de vue, l’agent certificateur ne peut pas vérifier les paramètres
dynamiques (e.g. le temps de réponse ou le nombre de invocations que le système est
en train d’exécuter). Par exemple, le temps de réponse d’une invocation à un service
web sur Internet est une mesure qui dépend d'un ensemble de variables parmi
lesquelles: les caractéristiques du réseau entre le client et le service web. Par exemple,
si le site du service web est à Grenoble, le temps de réponse est différent si la
application client est à Lyon, que si la application client est à San Francisco(Etats Unis).
Par rapport à la découverte de services web, la manière unique de faire la recherche et
l’invocation de façon automatique est au moyen des ontologies (par exemple, avec
OWL-S).
En plus le travail de [7] propose une plate-forme appelé « Web Service Discovery
Architecture – WSDA ». Le plus important de cette architecture est la proposition d'une
étendue au registre UDDI pour que cela offre quatre interfaces : La interface Presenter
qui permet de chercher la dernière version de la description d’un service web. La
interface Consumer qui permet de publier un service web. La interface MinQuery qui
permet de consuler l'ensemble de services web publiés dans le registre UDDI. La
interface XQuery qui implémente un ample ensemble de requêtes sur les services web
publiés. Ces requêtes sont exprimés dans le standard XQuery [10].
Par rapport à la substitution de services web, la proposition de [3] établit si deux services
sont compatibles (équivalents), c'est a dire s'ils peuvent être substitués un par autre.
Pour établir la compatibilité, il compare les signatures des méthodes, et les
spécifications des méthodes. Cette approche exige que la spécification d'un méthode
soit la pre-condition et la post-condition. Elles doivent être écrites en logique formelle de
premier ordre. De mon point de vue, cette exigence d'avoir la spécification (pre et postcondition) dans logique de premier ordre est très fort.
32
Chapitre 3 MELUSINE : LA TECHNOLOGIE DE L’APPLICATION CLIENTE
Mélusine est un système avec une architecture logicielle qui permet de construire des
applications par la composition d’éléments logiciels de diverses natures [8]. Ce système
a été construit par l’équipe Adèle (Laboratoire LSR - IMAG). Ce système s’intéresse plus
spécialement aux éléments logiciels existants afin de réutiliser au mieux les
fonctionnalités que définissent ces éléments.
Un participant est chacun des éléments a composer dans une fédération [8]. Un
participant a deux origines : (1) il est écrit pour être utilisé dans une fédération, (2) il est
un élément logiciel existant qui a été adapté pour être utilisé dans une fédération. Dans
le dernier cas, le terme exécutant est utilisé pour parler d’un élément logiciel
hétérogène qui doit être adapté pour être un participant.
3.1
Schéma de Composition
Le schéma de composition utilise par Mélusine est par coordination. Cet schéma
préserve l’autonomie et l’initiative des participants. En plus, il facilite l’évolution de
l’application globale résultante de la composition [8].
Dans une application Mélusine, il y a un Coordinateur. Ce but est d’aider les
participants à travailler ensemble pour réaliser l’application globale (Figure 7). Le
coordinateur connaît tous les participants. Il doit assurer la cohérence des concepts
partagés entre eux.
Figure 7 – Coordination comme un moyen de composition [8]
Il y a trois types des participantes : les actifs, les réactifs et les passives. Les actifs
peuvent changer leur état interne par leur propre initiative (e.g. une application
33
interactive). Les réactifs peuvent changer son état après une demande du coordinateur
(e.g. un composant de commencement d'achat), et les passifs qui réagissent toujours
comme demandés par le coordinateur (e.g. un composant de type service de traçabilité).
Pour garantir la cohérence de tous les participants après un changement de l’état, par
un participant actif ou réactif, le coordinateur peut demander aux autres participants de
faire la mise a jour de leur état. L’usage d’événements est une façon, a niveau
d’implémentation, de communiquer les changements d’état lors de coordinateur aux
participants et aussi dès participants au coordinateur.
3.2 Matérialisation des concepts partages
Les participants peuvent partager concepts. Un espace pour gérer ces concepts,
l’univers commun (i.e. UC), est fournie. Dans cet espace les concepts partagés sont
matérialsés explicitement dans un format compréhensible pour les participants. Le
coordinateur a la responsabilité de maintenir la cohérence de ces concepts. Si on
suppose que les participants P2 et P3 partagent le concept C, ce concept va être
matérialisé avec une instance ObjC de classe CC dans le UC.
En plus, le participant P1 aura un objet Obj1 de classe C1, et le participant P2 aura un
objet Obj2 de classe C2 ; Obj1 et Obj2 représentent à C. L’instance ObjC est utilisée
pour synchroniser les instances Obj1 et Obj2. Ceci est illustré graphiquement dans la
Figure 8.
Figure 8 – Synchronisation par l’univers commun [8]
La classe CC doit contenir suffisamment d’informations pour permettre d’exprimer la
manière de gérer la cohérence entre C1 et C2.
34
Désormais, la coordination entre les participants est traduite par la synchronisation de
l’état de leurs instances avec l’instance du concept partagé dans l’UC (i.e. l’instance
ObjC) et vice-versa.
La façon ci-dessus dont les participants se coordonnent autour de l’UC constitue le
paradigme de coordination « anarchique » dans lequel il n’existe aucun contrôle, aucun
règle ; les participants peuvent librement souscrire aux notifications émises par l’UC et
réagir a ces notifications.
3.3 Contrôle de la coordination
Dans Mélusine est bien connu que le paradigme « anarchique » ne permet pas d’
obtenir un résultat cohérent et correct [8] [23] [4]. Pour cette raison, il est nécessaire
d’avoir un moyen visant à contrôler explicitement la manière dont les participants se
coordonnent autour de l’UC. Ceci nous aide à garantir la cohérence entre l’UC et
l’ensemble de participants.
3.3.1 Autorité commune
L’autorité commune est l’organe qui fait partie du coordinateur et qui a pour but de
contrôler explicitement la synchronisation des participants avec l’univers commun.
Figure 9 – Univers commun contrôle par l’autorité commune [8]
Deux contrôles sont assures par l’autorité commune. Un pour déterminer ce que chaque
participant peut faire sur l’univers commun, le contrôle des accès, et l’autre pour définir
la manière dont les participants réagissent lors d’un changement de l’univers commun,
le contrôle de la coordination.
35
Dans le cas où les participants sont fortement contrôlés, c’est l’autorité commune qui
décide ce que chaque participant peut faire et ce que les participants doivent faire afin
de réaliser l’application globale. Ce paradigme de coordination est appelé le paradigme
dictatorial.
3.3.2 Contrôle de la coordination
L’autorité commune fait la coordination des participants en utilisant un contrat de
coordination. Un contrat de coordination définit explicitement la manière dont les
participants réagissent lors d’un changement de l’UC. La façon d’exprimer les réactions
potentielles d’un participant est sous forme des méthodes offertes par ce participant.
Ces méthodes représentent la contribution du participant à la réalisation de l’application
globales (celles-ci seront exprimées grâce au concept de rôle). Par conséquent, une
partie de l’autorité commun est exprimée par un ensemble de contrats de coordination.
Ci-dessus nous décrirons comme Mélusine fait la composition en faisant l’hypothèse que
les participants sont homogènes et conscients de la manière de composer. Maintenant
nous décrivons la manière de représenter et de « transformer » un exécutant
quelconque en un participant. Ceci nous permet de nous placer dans un contexte
général où les éléments à composer, appelés des exécutants, sont de nature
quelconque.
3.4 Un exécutant vu comme un participant
Un objectif important dans Mélusine est de permettre que un exécutant de nature
quelconque puisse être un participant. Pour réussir ce but nouvel éléments sont
ajoutes : une classification des exécutants, le concept de rôle, le concept d’adaptateur et
la capacité de gérer le cycle de vie des instances des participants (i.e. des exécutants et
de leur adaptateur). Avec ces concepts, nous disons qu’un participant est composé d’un
ensemble de rôles, un adaptateur et un exécutant.
3.4.1 Les sortes d’exécutants
Un exécutant peut être classifié en utilisant les concepts d’état et de localisation. A
niveau d’état, nous pouvons identifier deux types d’exécutant : application et outil.
Cette classification est utilisée dans la réalisation de l’adaptateur.
Dans le cas d’une application, son état ne peut pas être modifié depuis l’extérieur.
Autrement dit, une application a un comportement et un état interne spécifique. Par
contre, dans le cas d’outil, l’état est géré de façon externe. Par conséquent, il est
possible d’intervenir sur leur état.
Si on a un exécutant de sorte outil, les données utilisées peuvent être disponibles dans
l’application globale, mais sous un format différent. Une conversion des données est
souvent nécessaire. Ceci sera à la charge de l’adaptateur lié à l’exécutant.
La deuxième classification est basée sur le concept de localisation : les locaux et les
distants.
36
Les exécutants locaux s’exécutent sur la machine centrale du environnement. Ce type
d’exécutant ne peut avoir qu’une seule instance. En revanche, les exécutants distants
peuvent s’exécuter sur la machine centrale et aussi sur des machines clientes distantes.
De cette manière, un exécutant distant peut avoir plusieurs instances qui s’exécutent
simultanément sur plusieurs machines clientes différentes.
Il est important de noter qu’avec ces deux types d’exécutants, on est capable de définir
toutes les applications, même des applications complexes. Par exemple, une application
de type client-serveur peut être déclarée comme étant deux exécutants : un exécutant
local, avec une seule instance, représentant l’application serveur ; et un exécutant
distant, avec plusieurs instances sur des machines différentes, représentant l’application
cliente.
Le fait de déclarer une application client-serveur comme ci-dessus a plusieurs
avantages. Le cycle de vie de l’application serveur et cliente, sera complètement géré
par notre plateforme. La communication entre le serveur et les clients peut être effectuée
directement ou via notre système de communication.
3.4.2 Le concept de rôle
Dans le modèle de participants de Mélusine, le concept de rôle est utilisé pour
représenter une abstraction de la capacité fonctionnelle des exécutants.
Du point de vue de l’application globale, un rôle représente le contrat fonctionnel qu’un
exécutant jouant ce rôle doit respecter. Un exécutant peut jouer un ou plusieurs rôles, et
une rôle peut être joué par un ou plusieurs exécutants à la fois. C’est pour cette raison
que nous avons distinguée des rôles simples et des rôles multiples.
Dans ce modèle, un rôle est un uplet composée des suivants éléments (dans l’ordre) :
•
•
•
•
•
nom symbolique du rôle ;
interface qui regroupe les méthodes fournies par le rôle ;
nombre de participants pouvant jouer ce rôle ;
droit du rôle d’appeler des méthodes de l’UC et d’écouter les événements émis par
l’UC ;
événements émis par le rôle dus à son initiative. Ceci est important pour les
participants actifs ou réactifs.
3.4.3 Le concept d’adaptateur
Le concept d’adaptateur a été introduit afin de permettre à des exécutants existants de
jouer leurs rôles dans une application globale sans avoir à changer leur code source.
Concrètement, l’adaptateur aide l’exécutant à communiquer avec le coordinateur dans
les deux sens : coordinateur vers l’exécutant et exécutant vers le coordinateur.
Dans le cas coordinateur vers l’exécutant, l’adaptateur doit implémenter l’interface des
rôles joués par l’exécutant et assurer toutes les adaptations techniques entre l’univers
commun et l’exécutant. Ceci permet de surmonter l’hétérogénéité entre l’univers
37
commun et l’exécutant en ce qui concerne la représentation des concepts, la
représentation des fonctionnalités et le protocole de communication (Figure 10).
Figure 10 – Depuis le coordinateur vers l’exécutant [8]
Les adaptateurs sont composés des éléments mandataire et emballage dans le cas des
exécutants distants. Dans le cas des exécutants locaux, nous pouvons construire
seulement l’élément mandataire avec toutes les responsabilités de l’adaptateur.
Le mandataire (en anglais Proxy) est le représentant de l’exécutant auprès du
coordinateur. Il s’exécute sur la machine serveur (i.e. la machine centrale). Il doit
d’assurer la communication entre le coordinateur et l’emballage de l’exécutant.
Concrètement, le mandataire implémente l’interface des rôles joués par l’exécutant en
s’appuyant sur l’emballage. Lors de l’exécution, il transfère les appels de méthodes sur
cette interface à l’emballage. Il écoute également les changements de l’UC afin de les
envoyer à l’emballage.
Figure 11 – Adaptateur pour un exécutant distant [8]
38
Si l’exécutant est actif ou réactif, le mandataire est chargé de faire des appels de
méthodes sur l’UC afin de notifier les changements d’état de l’exécutant. Il est important
de noter que c’est l’emballage qui lui signale ces changements.
En revanche, l’emballage (en anglais Wrapper) est lié à l’exécutant. Il s’exécute sur la
machine de l’exécutant. Il doit gère le cycle de vie de l’exécutant (créer et détruire
l’instance de l’exécutant, etc.), observe l’exécutant afin de notifier au mandataire les
changements (dans le cas des exécutants actifs et réactifs), et invoquer les
fonctionnalités de l’exécutant lorsque le mandataire le lui demande.
L’emballage dépend seulement de l’exécutant ; il peut être réutilisé dans plusieurs
applications globales différentes. Par contre, le mandataire est spécifique à chaque
composition. Ceci parce que le mandataire assure le lien avec le coordinateur qui varie
en fonction de chaque composition pour construire une application globale spécifique.
39
Chapitre 4 LA PROBLEMATIQUE ET NOTRE APPROCHE
Dans ce chapitre, l’objectif est de décrire la problématique et notre approche. Dans le
contexte de la problématique il y a une application de type client Mélusine (chapitre 3)
qui a besoin de faire la découverte, la sélection et l’invocation d’un ensemble de
services web.
Le sujet de cette étude peut être divisé en deux sections : La première concerne la
découverte et la sélection des services web, tandis que la deuxième tourne autour de la
reprise après pannes de l’application et la substitution des services web.
4.1
La découverte et la sélection des services Web
Dans le contexte d’une application, de type Mélusine, qui a besoin d’exécuter une
fonctionnalité implémentée comme un service web par plusieurs fournisseurs, la
découverte fait référence au processus de recherche des services web implémentant la
fonctionnalité souhaitée. Chaque fournisseur peut implémenter la fonctionnalité avec
une interface différente. La sélection consiste à choisir, de façon dynamique, le meilleur
fournisseur du service web[3].
4.1.1 Architecture et Stratégie pour la découverte et la sélection des services
Web
Pour résoudre le problème de la découverte et de la sélection dans l’environnement de
Mélusine, on propose une architecture pour la communication avec les services web
(Figure 12). Cette architecture contient l’adaptateur d’invocation à des services web.
4.1.1.1 Objectifs
Notre architecture a les objectifs suivants :
• Utiliser un service web en accord avec les exigences du QdS du client à chaque
invocation. Ce service web n’est pas nécessairement le meilleur service web
existant.
• Suivre la structure d’un adaptateur d’une application de type Mélusine. Les concepts
de rôle et mandataire font part de cette structure. Cette structure rend transparent
l’usage de la technologie services web.
• Minimiser la non disponibilité d’un service web lors de sa invocation.
4.1.1.2 Hypothèses
Notre approche repose sur diverses hypothèses. Une hypothèse est d’avoir un
ensemble de registres UDDI (i.e. Universal Description Discovery Integration) classifiés
par domaine de service, c’est-à-dire, chaque registre UDDI a seulement les services
relatifs à un domaine particulier [26,27]. Par exemple, dans la figure 12 il y a deux
registres UDDI, un pour le transport aérien et l’autre pour le transport ferroviaire. De
cette façon, la recherche d’un service web d’un domaine spécifique est sur le registre
UDDI du domaine respectif. Par conséquent, le processus de recherche est plus précis.
40
La deuxième hypothèse est que les registres UDDI qu’on utilise sont très contrôlés.
C’est-à-dire, les registres ont une maintenance continuelle. Par conséquent, la
probabilité de trouver une entrée inconsistante est minime.
4.1.1.3 Architecture
L’architecture globale est composée de trois composants locaux :
• Un « Sélecteur de Mandataire » dont la fonction est de chercher et d’invoquer le
mandataire du service web choisi avec la fonctionnalité souhaitée.
Figure 12 – Architecture pour la découverte et la sélection des SW
41
•
Un « Sélecteur de Service Web » dont la fonction est de sélectionner un fournisseur
entre plusieurs selon la qualification définitive de QdS ( § 4.1.2.1 et § 4.1.3) de
chaque fournisseur. Ce sélecteur calcule cette qualification avec deux groupes
d’information : Les données fournies par l’administrateur de l’application cliente
forment le premier groupe. Ces données sont le limite acceptable, la valeur optimale,
le poids et la caractéristique éliminatoire de chaque paramètre ( § 4.1.2 et § 4.1.3 ).
Le deuxième groupe est formé par les valeurs des paramètres de QdS de chaque
fournisseur ( § 4.1.2 et § 4.1.3 ).
• Le « Manager de Découverte » qui assure deux fonctions :
(1) Demander l’information sur les fournisseurs des services web utilisés pour
l’application cliente locale auprès de l’ensemble de registres UDDI catégorisés. Cette
demande est fait de manière périodique (e.g. une fois par semaine ).
S’il y a des nouveaux fournisseurs de services, l’information les concernant est
enregistrée dans la Base de Données. Cette information est composée du nom du
service, le fichier WSDL et l’URL. Pour chaque nouveau fournisseur, ce Manager
essaie d’obtenir un ensemble de paramètres de QdS du nouveau fournisseur en
invoquant un service web de QdS. Si le service web de QdS n’est pas disponible, un
opérateur doit obtenir cet ensemble de paramètres de QdS en utilisant le courrier
électronique ou le téléphone.
Les paramètres de QdS que l’administrateur de l’application cliente peut avoir sans
contacter l’administrateur du service web sont :
• p1 Degré de confiance du client sur le fournisseur
•
•
p3 Temps de réponse
p 4 Https ou http utilise comme protocole de communication
Nous pensons que le paramètre p 2 (Coût par invocation) est facile d’obtenir aussi.
Dans notre exemple, si le système a ces quatre paramètres d’un service web, qui
sont les plus prioritaires (sa somme est 60), il est possible que le service web soit
invoqué (sans contacter son administrateur).
Notre logiciel génère, avec le fichier WSDL et l’URL, le code du mandataire respectif
(Par exemple, le code du Mandataire1 ou le code du Mandataire2) (voir chapitre 5).
(2) Il y a un processus P de « pooling » pour établir la communication avec le groupe de
fournisseurs d’un service web (ou d’un service web équivalent) pour vérifier la
disponibilité du service et l’état de la communication pour chaque fournisseur. C’està-dire, nous établions la communication avec chaque serveur des services web.
De plus, si les serveurs fournissent un service web avec une interface de QdS, il
demande les paramètres dynamiques (i.e. le temps de réponse de une invocation et
la charge) de QdS de chaque service web. Dans la figure 12, les fournisseurs F2 et
F4 exportent un service web de QdS.
Ce processus P est exécuté dans deux cas : Au début de l’application cliente ou
quand la QdS du fournisseur descend sous un seuil (section 4.1.1.4). Ce seuil est
initialisé pour l’administrateur de l’application cliente.
Pour éviter inonder l’Internet avec ces invocations la fréquence minimale sera de une
période T, par exemple 1 heure.
42
4.1.1.4 Stratégie d’Invocation par une Application Cliente
Au moment où l’application commence son exécution, elle invoque le processus P de
« pooling » pour vérifier la disponibilité de tous les fournisseurs. Ce disponibilité est
enregistré sur un tableau de QdS. De plus, on recalcule la qualification définitive de QdS
(§ 4.1.2.1 et § 4.1.3).
L’invocation à un service web, qui implémente une fonctionnalité, par une application
cliente, suit le processus suivant :
(1) L’application invoque une entité appelée Sélecteur de Mandataire. Ce mandataire
implémente le rôle d’adaptateur (e.g. le rôle r).
(2) Dans cette étape la variable obtenirNouveauMandataire est définie pour le
Sélecteur des Services Web . Elle indique si le Sélecteur des Services Web doit ou non
obtenir un nouveau mandataire dans l’invocation suivante. Cette variable est initialisée
avec la valeur true (i.e. le Sélecteur des Services Web doit obtenir un nouveau
mandataire dans l’invocation suivante).
(3) Le Sélecteur de Mandataire demande au Sélecteur du Service Web l’information
pour créer et invoquer le meilleur mandataire d’un service web qui implémente la
fonctionnalité souhaitée avec une interface propre.
Si la variable obtenirNouveauMandataire est égale à false l’exécution doit suivre
dans l’étape 5. Sinon le Sélecteur de Services Web choisit un ensemble de services
web disponibles qui offrent la fonctionnalité souhaitée. Ces services web offrent les
meilleurs QdS selon la politique de QdS de l’application (§ 4.1.2). Le Sélecteur de
Service Web peut accéder à la définition de la politique de QdS (i.e. Qualité de Service)
de l’application cliente. Cette politique de QdS est enregistrée sur la base de données.
L’information sur cet ensemble est retournée dans un tableau au Sélecteur de
Mandataire. Chaque élément du tableau contient le nom de la classe Java qui
représente un service web, l’adresse IP du fournisseur, le nom et les types des
paramètres de la méthode à invoquer. Le tableau est ordonné en ayant comme critère la
qualification
de
QdS
de
chaque
service
web.
La
variable
obtenirNouveauMandataire prend la valeur false.
(4) Le Sélecteur de Mandataire prend l’information du meilleur service web choisi et il
crée une instance du mandataire qui le représente.
(5) Ce sélecteur de mandataire fait l’invocation au mandataire du service web.
(6) Le mandataire fait l’invocation au service web respectif.
(7) Le service web exécute la méthode et retourne la valeur de réponse.
(8) Le mandataire reçoit cette valeur et la retourne au Sélecteur de Mandataire.
(9) Le Sélecteur de Mandataire reçoit la valeur de réponse. Il calcule ensuite le temps de
réponse de l’invocation. Après, il crée un « thread » pour appeler au Sélecteur du
Service Web.
(10) Le processus principal du Sélecteur de Mandataire retourne le résultat à
l’application cliente.
43
(11) Le « thread » appelle le Sélecteur du Service Web avec le temps de réponse
comme paramètre. Le Sélecteur de Service Web met à jour, dans la base de données,
le temps de réponse pour le fournisseur invoqué. Ce sélecteur recalcule la qualification
de QdS de ce fournisseur. Il y a deux cas pour cette nouvelle qualification :
• La QdS de ce fournisseur descend sous un seuil. Dans ce cas, le Sélecteur de
Services Web demande au Manager de Découverte d’exécuter le processus P
de « pooling ». Après, ce Manager démarre ce processus P pour mettre à jour la
disponibilité des fournisseurs du service web équivalent. Ensuite, le Sélecteur de
Services Web recalcule la valeur de QdS des fournisseurs du service web
équivalent. Ce Sélecteur donne à la variable obtenirNouveauMandataire la
valeur true. Cette affectation est faite pour obliger au Sélecteur de Services
Web de choisir un nouveau fournisseur dans l’invocation suivante.
•
La QdS de ce fournisseur est plus grande ou égale au seuil. C’est-à-dire ce
fournisseur a une bonne ou acceptable QdS. Dans ce cas, on donne à la variable
obtenirNouveauMandataire la valeur false. De cette façon, le sélecteur
des services web utilisera le même fournisseur dans la prochaine invocation.
4.1.2 Modèle de Sélection des Services Web
L’objectif de cette section est de décrire le modèle de notre approche pour sélectionner
le meilleur fournisseur d’un service web.
Nous supposons qu’il y a un ensemble de fournisseurs d’un service web :
F = { f 1 , f 2 ,..., f n }
Par exemple, si le service web fournit est un service d’achat de billets d’avion, les
fournisseurs peuvent être Air France, American Airlines et Continental Airlines.
En plus, il y a un ensemble de paramètres de QdS pour qualifier les fournisseurs
P = {p1 , p 2 ,..., p m }
Un paramètre peut être dynamique s’il change pendant l’exécution ou statique au
contraire.
On considère que les paramètres les plus importants sont :
• p1 - Degré de confiance du client sur le fournisseur. Ce paramètre est statique.
•
•
•
•
p 2 - Coût par invocation. Ce paramètre est statique.
p3 - Temps de réponse : Le temps maximum garanti demandé pour exécuter
une requête. Ce paramètre est dynamique (e.g. il peut changer pendant
l’exécution).
p 4 - Https ou http comme protocole de communication. Ce paramètre est
statique.
p5 - Mode d'exécution du service : Indique s’il est ou non transactionnel. Ce
paramètre est statique.
44
•
•
p 6 - Méthode de cryptage des données : Exprime le fait de avoir de cryptage sur
la base de données. Ce paramètre est statique.
p 7 - Temps moyen entre Pannes. Ce paramètre est statique.
•
p8 - Probabilité que le système soit actif. Ce paramètre est statique.
•
p9 - Existence ou non de traçabilité. La traçabilité sont les messages enregistre
•
dans la base de données pour permettre processus d’audit. Ce paramètre est
statique.
p10 - Nombre actuel d’invocations concurrentes que le service web est en train
d’exécuter. Ce paramètre est dynamique.
L’administrateur de l’application cliente devra définir si un paramètre est ou non
éliminatoire. Par exemple, soit p 7 (Temps moyen entre pannes) un paramètre
éliminatoire, où sa valeur minimale acceptable est 12 heures ; si un fournisseur a un
temps moyen entre pannes de 10 heures, le fournisseur va être éliminé sans prendre en
compte les autres paramètres de QdS.
Il y a une fonction de poids pour l’ensemble de paramètres de QdS. L’objectif de cette
fonction est donner l’importance respective à chaque paramètre. Sa définition est :
w : P → {n / n ∈ Ν ∧ 0 ≤ n ≤ 100}
w( p k ) = wk
pour 1 ≤ k ≤ m
Si pour l’application cliente le paramètre pi est plus important que le paramètre p j
alors w( p i ) > w( p j ) . Dans notre exemple, w(p1 )=18 . et w(p9 )=6 . C'est-à-dire le degré
de confiance du client sur le fournisseur (qui a un poids de 18) est plus important que le
fait qu’il y a un mécanisme de traçabilité (qui a un poids de 6).
m
En plus, la somme de tous les poids est 100. C'est-à-dire
∑w
k =1
k
= 100 . Cette contrainte
est pour qualifier la qualité de chaque fournisseur avec un nombre entre 0 et 100. En
plus, l’administrateur de l’application cliente utilise cette contrainte pour établir le seuil
entre 0 et 100.
La définition de la fonction w pour l’exemple est :
Paramètres de QdS
wk
Degré de confiance du client sur le fournisseur
18
Coût par invocation
16
Temps de réponse
14
p4
p5
https ou http comme protocole de communication
12
Mode d'exécution du service : transactionnel
10
p6
Existence d’une méthode de cryptage des données sur la BD
8
p7
Temps moyen entre pannes
6
p1
p2
p3
45
p8
La probabilité que le système soit actif
6
p9
Existence ou non de traçabilité
6
p10
Nombre actuel d’invocations concurrentes que le service web est en 4
train d’exécuter
Un fournisseur d’un service web est un n-uplet où chacun de ses éléments est la valeur
d’un paramètre (dans l’ordre).
f i = p1i , p 2i ,..., p mi
ou 1 ≤ i ≤ n ∧ 1 ≤ k ≤ m
Dans notre exemple, nous supposons qu’il y a trois fournisseurs :
f1 = 95 / 100,1.20,700, true, true, true,8,0.96, true,100
f 2 = 90 / 100,1.10,900, true, true, true,26,0.98, true,120
f 3 = 96 / 100,0.00,450, false, true, false,16,0.92, true,140
De plus, il y a un ensemble des fonctions de QdS :
G = {g1 , g 2 ,..., g m }
g k : ℜ → {r / r ∈ ℜ ∧ 0 ≤ r ≤ 1} et 1 ≤ k ≤ m
L’objectif d’une fonction g k est transformer une valeur d’un paramètre de QdS en un
nombre réel entre 0 et 1 qui représente le niveau de QdS. La valeur 0 représente une
QdS nulle. La valeur 1 représente la QdS optimale pour le paramètre. Selon la définition
de la fonction g k , nous avons classifié les paramètres en trois sortes : les paramètres
directement proportionnels à la QdS, les paramètres inversement proportionnels à la
QdS, et les paramètres de type booléen. Une description de cette classification est
présentée ci-dessous.
1) Les paramètres avec des valeurs directement proportionnels à la QdS.
Le temps moyen entre pannes est un paramètre ( p 7 ) de QdS qui est directement
proportionnel à la QdS du fournisseur. C’est-à-dire, plus grand est le temps moyen entre
pannes d’un fournisseur plus grand est sa QdS. Pour calculer la fonction g 7
l’administrateur de l’application cliente devra donner deux valeurs : la première est la
valeur minimale du paramètre que doit offrir un fournisseur pour être accepté. Par
exemple, on peut supposer que l’administrateur accepte 12 heures comme minimum
pour le TMEP (e.g. Temps Moyen Entre Pannes). Cette valeur a une QdS égal à 0. La
deuxième est la valeur pour le paramètre qui représente une QdS optimale. On suppose
que pour l’administrateur 72 heures est le TMEP optimal. Un TMEP égal ou plus grand à
72 heures aura une valeur de QdS égal à 1.
Avec ces valeurs minimale et maximale la fonction g k est la suivante (figure 13) :
46
Figure 13 – Fonction pour transformer le temps moyen entre pannes à valeur de QdS
Avec le même méthode la fonction g k est calculé pour les paramétres p1 et p8 , parce
que la valeur du paramètre est directement proportionnelle à la QdS. Alors la fonction
g k qui doit être utilisée est la fonction linéaire ascendante et définie de la façon
suivante (figure 14) :
Dans cette définition e est la valeur minimale acceptable. C'est-à-dire une valeur égale
ou plus petite à e aura une QdS de 0. En plus, p est la valeur optimale. Une valeur égale
ou plus grande à p aura une QdS égale à 1.
47
Figure 14 – Valeur du paramètre est directement proportionnelle à la QdS
g k est utile pour transformer la valeur des paramètres suivants :
•
p1 - Degré de confiance du client sur le fournisseur
•
p 7 - Temps moyen entre pannes
•
p8 - Probabilité que le système soit actif
2) Les paramètres avec des valeurs inversement proportionnels à la QdS.
Un autre paramètre de QdS est le temps de réponse ( p3 ). Ce paramètre est
inversement proportionnel à la QdS du fournisseur. Plus est grand le temps de réponse
plus petite est sa QdS.
Deux valeurs doivent être fournis par l’administrateur de l’application cliente pour
calculer la fonction g 3 . La première est le temps de réponse maximal qui doit satisfaire
un fournisseur pour être accepté. La deuxième est le temps de réponse qui represente
une QdS optimal. Par exemple, l’administrateur peut accepter 6000 ms comme
maximum pour le temps de réponse et 500 ms comme temps optimal. Dans ce cas, si le
fournisseur a un temps de réponse égal ou plus grand à 6000 ms, il aura une QdS égal
à 0. Par contre, s’il a un temps de réponse de 500 ms ou plus petit sa QdS sera égal à
1. La fonction g 3 qui est défini par ces valeurs maximale et optimale est la
suivante (Figure 15) :
48
Figure 15 – Fonction pour transformer le temps de réponse à une valeur de QdS
De la même façon la fonction g k est calculée pour les paramètres p 2 et p10 , parce que
la valeur des paramètres est inversement proportionnelle à la QdS. Alors la fonction g k
qui doit être utilisée est descendante et définie de la façon suivante (figure 14) :
Dans cette définition e est la valeur maximale acceptable. C'est-à-dire une valeur plus
grande à e aura une QdS de 0. En plus, p est la valeur optimale. Une valeur de p ou
plus petite aura une QdS égal à 1.
49
Figure 16 – Valeur du paramètre est inversement proportionnelle à la QdS
• p 2 - Coût par invocation.
• p3 - Temps de réponse.
• p10 - Nombre actuel d’invocations concurrentes que le système est en train
d’exécuter.
3) Fonction g k pour les paramètres de type Booléen
Pour les paramètres de QdS qui prennent des valeurs booléennes {false, true}, et si la
valeur true représente une bonne QdS, alors la fonction g k qui doit être utilisée est la
suivante :
g k (true) = 1 , g k ( false) = 0
pour k =4,5,6,9
• p 4 - https ou http comme protocole de communication
• p5 - Mode d'exécution du service transactionnel
• p 6 - Existence d’une méthode de cryptage des données sur la BD
• p9 - Existence ou non de traçabilité
4.1.2.1 La mesure de la Qualité de Service d’un fournisseur d’un service web
Pour mesurer la Qualité de Service (QdS) d’un fournisseur i d’un service web on fait la
somme suivante :
m
qi = ∑ g k ( p ki ).wk
1 ≤ k ≤ m et 1 ≤ i ≤ n
(équation 1)
k =1
C'est-à-dire pour chaque paramètre p k de QdS, on prend la valeur du paramètre pour
le fournisseur i : p ki . A cette valeur on applique la fonction de QdS g k pour obtenir
50
g k ( p ki ) . Cette valeur est une mesure de la QdS de la valeur du paramètre k pour le
fournisseur i. Cette valeur est dans l’intervalle [0,1]. Après, on multiplie g k ( p ki ) pour le
wk (i.e. le poids du paramètre k). Finalement, on somme les k valeurs g k ( p ki ) ⋅ wk . Ce
somme est appelée qualification définitive de QdS pour le fournisseur i. Les mesures
pour notre exemple sont montrées dans la figure 17.
4.1.2.2 Fournisseur Sélectionné
Le fournisseur j sélectionné sera lui qui maximise l’équation 1. C'est-à-dire le fournisseur
j qui satisfait :
n
f j : q j = max (qi )
i =1
C’est-à-dire, le fournisseur j sélectionné sera le fournisseur avec la plus grande
qualification définitive de QdS.
4.1.3 Exemple de Sélection
Pour cet exemple, il y a trois fournisseurs. L’évaluation a été faite avec dix paramètres
de QdS. La première colonne présente l’ensemble des paramètres. La deuxième,
troisième et quatrième colonnes ont les valeurs actuelles des paramètres pour les
fournisseurs. La cinquième colonne montre les valeurs limites acceptables pour le client.
La sixième colonne présente les valeurs limites optimales. La septième présente les
poids pour chaque paramètre(e.g. les wk ). La huitième, neuvième et dixième montrent
les produits g k ( p ki ) ⋅ wk . La onzième colonne dit si une valeur du paramètre inférieure à
la valeur acceptable peut éliminer le fournisseur. Les qualifications finales pour les trois
fournisseurs ont été q1=71.53, q2=67,12 et q3=49,20. Pour cette raison le fournisseur
sélectionné a été f1 . En plus le fournisseur f 3 a été éliminé.
51
Fourn. 1 Fourn. 2
p 1k
Fourn. 3
p k2
p k3
Limite
Valeur
Poids QdS F1
acceptable optimale w
QdS
F2
QdS
F3
éliminatoire
?
k
Paramètre
p1
0,95
0,9
0,96
0,85
1
18
p2
1,20
1,10
0,00
1,50
0
16
12
3,20
6
4,27
13,2
16,00
vrai
p3
1000
1500
6500
6000
500
14
12,73
11,45
0
vrai
p4
True
True
False
-
-
12
12
12
0
vrai
p5
True
True
True
-
-
10
10
10
10
vrai
p6
True
True
False
-
-
8
8
8
0
faux
12
26
16
12
72
6
0
1,4
0,4
vrai
p8
0,96
0,98
0,92
0,9
1
6
3,6
4,8
1,2
vrai
p9
True
True
True
6
6
6
6
vrai
20
40
60
4
4
3,2
2,4
vrai
p7
p10
-
100
Qualification Définitive de QdS
200
vrai
100 q1=71,53 q2=67,12 q3=49,20
Figure 17 – Exemple de sélection avec dix paramètres de QdS
4.2
Problème de la reprise après pannes
Pour les applications qui utilisent des services web et qui s’exécutent sur Internet, il y a
besoin de prendre en compte la possibilité de la présence de pannes dans le réseau ou
dans les sites qui exécutent l’application. Par exemple, une coupure dans le réseau, un
ordinateur qui tombe en panne ou l'élimination d'un service web.
Le processus de substitution d’un service web, après une panne, dépend si la méthode
s’exécute de façon transactionnelle ou si la méthode fait des modifications.
•
Si la méthode est de consultation, le client substitue le service web par autre
pendant l’exécution.
•
Si la méthode est de modification et elle s’exécute de une façon transactionnelle, il
faut arrêter l’exécution de la méthode, et attendre jusqu’à la récupération du service
web. Après, invoquer un service web qui informe si la méthode a été exécutée ou
pas. Si la méthode a été exécutée, on peut suivre l’exécution, sinon on peut
substituer le service web par autre.
•
Si la méthode est de modification et elle s’exécute d’une façon non-transactionnelle,
le client ne peut pas substituer le service web par autre. Dans une opération nontransactionnelle on ne peut pas ignorer les effets de l’invocation, et on ne peut pas
52
savoir ces effets. Par exemple, si l’opération qui a échoué est un paiement bancaire,
il n’est pas possible prendre aucune action sans savoir les effets de l’invocation.
Ce raisonnement est necessaire, parce qu’il y a plusieurs possibilités pour une
invocation à un service web :
• Le serveur tombe en panne après avoir exécuté une part de la méthode du
service web. Par conséquent, les effets de l’exécution sont partiaux.
• Le serveur tombe en panne avant de commencer l’exécution de la méthode. Par
conséquent, l’invocation n’a aucun effet.
• Le serveur tombe en panne juste après l’exécution de la méthode, c’est à dire les
effets de l’invocation sont complets mais le client n’a pas reçu la réponse.
53
Chapitre 5 REALISATION
Dans ce chapitre nous décrivons la partie de l’architecture implémentée.
5.1
Description de l’outil pour invoquer un service Web dans Mélusine.
La partie implémentée est un éditeur qui génère le code d’un mandataire (Figure 12) qui
permet la communication avec un service web existant. Cet éditeur est un sous-éditeur
de l’application FedeEditor v 3.0.
Pour générer le code du mandataire du service web, le processus est le suivant :
(1) Choisir l’option « Add a web service component ».
Figure 18 – FedeEditor, option pour ajouter un outil de type Service Web
(2) Donner un nom au nouvel outil.
(3) Choisir l’interface implémentée par le service Web et préciser son URL d’accès.
54
Figure 19 – FedeEditor, option pour générer le mandataire
(4) Presser le bouton « Generate WSDL » pour générer le fichier WSDL à partir de
l’interface Java et l’URL du service web.
L’éditeur utilise la classe
org.apache.axis.wsdl.Java2WSDL pour générer le fichier WSDL [39]. Ce fichier sera
utile plus tard pour générer deux classes qui seront utilisées par le Mandataire du
service web.
(5) Presser le bouton « Generate Stub Files » pour générer le code du Mandataire
composé par trois classes (fichiers) dont deux classes sont générées à partir du fichier
WSDL [39] utilisant la classe org.apache.axis.wsdl.WSDL2Java.
(6) Presser le bouton « Compile Stub Files » pour compiler le code généré du
Mandataire. Ce Mandataire pourra être invoqué par le Sélecteur de Mandataire.
La stratégie d’invocation d’un service Web par une application cliente a été présentée
dans la section 4.1.1.4.
55
Chapitre 6 BILAN ET PERSPECTIVES
6.1
BILAN
Dans ce travail nous proposons une architecture et une stratégie pour la découverte, la
sélection, la substitution et l’invocation de services web par une application cliente de
type Mélusine.
Cette architecture permet la sélection dynamique de services web en utilisant un modèle
de points et de poids pour un ensemble de paramètres de qualité de service (QdS). Ces
paramètres sont classés dans deux catégories : (1) Les paramètres dynamiques qui
peuvent changer dans le temps. Par exemple, le temps de réponse et le nombre actuel
d’invocations concurrentes que le service web est en train d’exécuter ; (2) Les
paramètres "statiques" qui ne changent pas ou qui changent avec peu de fréquence, par
exemple, le coût par invocation.
Les paramètres de QdS sont définis selon les besoins des applications clientes.
L’administrateur d’une application cliente choisit les paramètres de QdS qui doivent
peser le plus au moment de sélectionner le meilleur service web.
La stratégie est basée sur qu’au début on choisit le meilleur fournisseur d’un service
web. Ce fournisseur continue d’être invoqué jusqu'à ce que sa QdS diminue au-dessous
du seuil. A ce moment la, on fait un « pooling » pour déterminer la disponibilité des
autres fournisseurs de service web en question. Après, on fait à nouveau une sélection
pour choisir le meilleur parmi les candidats. Ce processus se répète comme au début.
Finalement, comme mécanisme de tolérance aux pannes, notre architecture permet la
sélection et la substitution entre services web équivalents2. Une application cliente peut
substituer un service web en panne par un autre équivalent et disponible.
Comme partie de ce travail a été développé un générateur de mandataires. Il utilise
l’interface et le URL du service web pour la génération du mandataire. Ce mandataire
permet la communication entre l’application cliente et le service web.
6.2
PERSPECTIVES
Deux lignes de recherche sont liées à notre architecture pour utiliser les services web.
La première est liée à la façon de faire la découverte, et la deuxième à la manière de
choisir un service web parmi plusieurs.
La découverte de services web dans notre architecture est faite de façon semiautomatique. La première perspective est d’avoir une découverte automatique qui
puisse être faite pendant l’exécution. Pour avoir cette caractéristique, deux
éléments sont nécessaires : un registre UDDI avec OWL-S (i.e. la gestion d’ontologies)
[41][42], et un API de recherche de services web sur un registre UDDI qui utilise les
ontologies.
2
Deux services web sont équivalents s’ils implémentent la même fonctionnalité avec des
interfaces égales ou différentes.
56
La deuxième perspective est de faire le processus de génération (et de compilation) du
code du Sélecteur de Mandataire afin d’invoquer un nouveau mandataire d’une façon
automatique et pendant l’exécution [42]. Avec cette perspective, on a l’invocation
dynamique d’un service web découvert de façon automatique et pendant l’exécution
[42].
57
Chapitre 7 BIBLIOGRAPHIE
[1] Alonso G. , Casati F., Kuno H. et Machiraju V.; “Web Services Concepts,
Architectures and Applications”; Springer-Verlag Berlin; Mars 2003.
[2] Cervantes H. et Hall R.; “Technical Concepts of Software Orientation” ; Laboratoire
LSR-IMAG, équipe Adèle, Mars 2004.
[3] De Antonellis V., Melchiori M., Pernici B., Plebani P.; “A Methodology for e-Service
Substitutability in a Virtual District Environment” ; Advanced Information Systems
Engineering, 15th International Conference, CAiSE 2003, Klagenfurt, Austria,
Juin 2003.
[4] Estublier J., Le A-T; “Design and development of Software Federation” ; 14èmes
Journées Internationales “Génie Logiciel & Ingénierie de Systèmes et leurs
Applications” – ICSSEA 2001 ; Paris, France, Décembre 2001.
[5] Foster I., Kesselman C., Nick J., and Tuecke S.; “The Physiology of the Grid: An
Open Grid Services Architecture for Distributed Systems Integration” , January
2002.
[6] Gunther N.J. ; “The practical performance Analyst”; publié par McGraw-Hill, 1998.
[7] Hoschek Wolfgang ; « The Web Service Discovery Architecture » ; Proc. of the Int'l.
IEEE/ACM Supercomputing Conference (SC 2002), Baltimore, USA, November
2002. IEEE Computer Society Press.
[8] Le A-T; “Fédération : une Architecture Logicielle pour la Construction d’Applications
Dirigée par les Modèles” ; Thèse en Informatique à l’Université Joseph Fourier
(Grenoble) – janvier 2004.
[9] Shuping Ran; “A model for web services discovery with QdS”; ACM SIGecom
Exchanges; Volume 4 ,
Issue 1
Spring, 2003; ACM Press;
http://doi.acm.org/10.1145/844357.844360
[10] W3C World Wide Web Consortium; “XQuery 1.0: An XML Query Language”; W3C
Working Draft; http://www.w3.org/TR/xquery/ ; 12 November 2003.
[11] W3C World Wide Web Consortium; “Web Services Architecture”; W3C Working
Group Note 11; February 2004; http://www.w3.org/TR/ws-arch
[12] W3C World Wide Web Consortium; “The Extensible Stylesheet Language Family
(XSL)”; Disponible à: http://www.w3.org/Style/XSL/
[13] W3C World Wide Web Consortium; “XML Path Language (XPath) Version 1.0”;
W3C Recommendation 16 November 1999 ; http://www.w3.org/TR/xpath/
[14]
W3C World Wide Web Consortium; “SOAP Version 1.2 Part 0: Primer”; W3C
Recommendation 24 June 2003; http://www.w3.org/TR/soap12-part0/
58
[15] Zaremski A.M., Wing J.M.; “Specification matching of software components” ;
Proceedings of the 3rd ACM SIGSOFT symposium on Foundations of software
engineering; ACM Press (1995) 6-17.
[16] Exolab.org; “The Castor Project”; http://www.castor.org
[17] Duclos F., Estublier J., Sanlaville R.; “Une Machine à Objets Extensibles pour la
Séparation des Préoccupations”. Journées systèmes à Composants Adaptables
et Extensibles”; Octobre 2002, Grenoble, France.
[18]
World Wide Web Consortium;
http://www.w3.org/XML/
“Extensible
Markup
Language
(XML)”;
[19] D.S. Linthicum, “EAI Application Integration Exposed”, Software Magazine, Feb/Mar
2000, http://www.softwaremag.com/L.cfm?Doc=archive/2000feb/EAI.html.
[20] T. Elrad, R.E. Filman, A. Bader. “Aspect-oriented programming: Introduction”.
Communications of the ACM. Volume 44, Issue 10 – October 2001.
[21] Dynamic Proxy Classes ;
http://java.sun.com/j2se/1.3/docs/guide /reflection/proxy.html
[22] ShaikhAli A., Rana O., Al-Ali R. et Walker D. W.; "UDDIe: An Extended Registry for
Web Services"; Proceedings of the Service Oriented Computing: Models,
Architectures and Applications, SAINT-2003 IEEE Computer Society Press.
Orlando Florida, USA, janvier 2003.
[23] Le A.T.; “Process Support for Tools Interoperability”; Symposium Doctorial – 17th
IEEE International Conference on Automated Software Engineering (ASE
2002); September 2002, Scotland, UK, ISBN 0-7695-1736-6.
[24] Microsoft Corporation Inc., BEA Systems, Canon et Intel ; “Web Services
Dynamic Discovery (WS-Discovery)”; Spécification, février 2004; Disponible à:
http://msdn.microsoft.com/webservices/community/workshops/default.aspx?pu
ll=/library/en-us/dnglobspec/html/ws-discovery.asp
[25] Institute of Electrical and Electronics Engineers ; “IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard Computer Glossaries”; New York
1990.
[26] K. Verma, K. Sivashanmugam, A. Sheth, A. Patil, S. Oundhakar, and J. Miller,
“METEOR-S WSDI: A Scalable Infrastructure of Registries for Semantic
Publication and Discovery of Web Services“, Journal of Information
Technology
and
Management,
2004;
Disponible
à:
http://lsdis.cs.uga.edu/lib/download/MWSDI.pdf
[27] Adrian Mello ; “Breathing new life into UDDI“; Tech Update, ZDNET.com, June
26, 2002.
[28]
W3C World Wide Web Consortium; “HyperText Markup Language (HTML)
Home Page”; Disponible à : http://www.w3.org/MarkUp/
59
[29] W3C World Wide Web Consortium; “CGI: Common Gateway Interface”; Disponible
à : http://www.w3.org/CGI/
[30]
[31]
W3C World Wide Web Consortium; “PHP Home Page”; Disponible à :
http://www.php.net/
Microsoft
Corporation
Inc.;
“Active
Server
Pages
”;
Disponible
à
:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/servertech.asp
[32]
Sun Microsystems; “JavaServer
http://java.sun.com/products/jsp/
Pages
Technology”;
Disponible
à
:
[33] Sun Microsystems ; “Java 2 Platform, Enterprise Edition (J2EE)“; Disponible à :
http://java.sun.com/j2ee/index.jsp
[34]
Microsoft Corporation Inc. ; “Microsoft .NET Framework Developer Center“;
Disponible à : http://msdn.microsoft.com/netframework/
[35]
W3C World Wide Web Consortium; “SOAP Version 1.2 Part 1: Messaging
Framework“; Disponible à : http://www.w3.org/TR/soap12-part1/
[36] Bussler Christoph; “B2B Integration: Concepts and Architecture“; Springer-Verlag
Berlin, 2003.
[37]
The Accredited Standards
http://www.x12.org/.
Committee
(ASC)
X12
;
Disponible
à:
[38] RosettaNet ; Disponible à: http://www.rosettanet.org/
[39] Apache Project ; “WebServices – Axis“ ; Disponible à: http://ws.apache.org/axis/
[40] Padovitz A., Krishnaswamy S., Loke S.W.; “Towards Efficient Selection of Web
Services”; Workshop on Web Services and Agent-based Engineering, WSABE;
Melbourne, Australia, July 2003.
[41] Paolucci M., Kawamura T., Payne T.R., Sycara K. ; “Importing the Semantic Web in
UDDI”; In Proceedings of Web Services, E-business and Semantic Web
Workshop 2002.
[42] 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
[43]
McGuinness D.L. and van Harmelen F. ; “OWL Web Ontology Language
Overview”; http://www.w3.org/TR/owl-features/, Août 2003, World Wide Web
Consortium - Candidate Recommendation.
60

DECOUVERTE DES WEB SERVICES

Transcription

Documents pareils

Fiche analyse fournisseurs

Web Services en Java

M. Benjamin MINKO

Discours prononcé à l`occasion de la remise du

souriez, vous aller peut-être gagner un week

Les étapes à suivre pour choisir un logiciel

Séjour Court La Rochelle

Untitled

CITROEN NOUVEAU GRAND C4 PICASSO/ 1.6