Le nombre de sites Web et de serveurs Web a grimpé rapidement jusqu’à plus de 644 millions de sites Web le mois de Novembre 2015 [5].
Premièrement, la communauté du web vise une extension sémantique du web actuel syntaxique en augmentant les informations existantes sur le web avec des descriptions formelles de leurs significations en utilisant des descriptions formelles à base de logiques. Cette annotation sémantique sera appréhendable par la machine et permettra donc un accès et une intégration plus faciles de la quantité énorme d’information disponible par rapport à ce qui a été réalisé avec la recherche basée sur les mots clés. En second lieu, le web change d’une collection de pages web statiques en un environnement dynamique avec l’arrivée de la technologie des servicesweb qui rend les composants logiciels accessibles via des protocoles web [6].
Dans cet article, nous avons exposé trois approches pour la description sémantique des servicesWeb, à savoir : OWL-S, SAWSDL et WSMO. Ces approches constituent une bonne base pour le SWS malgré qu’il reste beaucoup de travail afin qu’elles soient utilisables. Toutes ces approches sont en soumission auprès du W3C [W3C 07]. Mais dernièrement le groupe de travail de SAWSDL a pratiquement atteint son objectif à propos de SAWSDL. Ce dernier tirera profit des mécanismes d’extension de WSDL 2.0 pour établir un soutien simple et générique consistant à ajouter des descriptions sémantiques pour les services de Web. Le W3C vient de finaliser WSDL 2.0, le 27 juin 2007 [W3C 07]. Il est le langage de description de servicesWeb qui prend en compte le principal protocole Web, HTTP, ainsi que le protocole de servicesWeb le plus couramment utilisé, SOAP. WSDL 2.0 intègre les correctifs apportés à WSDL 1.1. Les spécifications de SAWSDL développées par ce groupe de travail sont devenues une proposition pour une recommandation le 5 juillet 2007 [W3C 07].
pour l’extraction d’une solution, on ne fait que multiplier les chemins des propositions du but. En combinant cela avec le processus de minimisation (qui nécessite plus d’une phase), on réduit le temps d’exécution de la composition comme indiqué dans le chapitre de la validation(Chapitre 5).
Le travail [Zheng & Yan (2008)] est basé sur l’idée d’un graphe de planification, qui modélise le problème de composition du service Web et fournit une solution triviale au problème. Les auteurs n’utilisent pas de recherche en amont pour trouver la solution, mais proposent de supprimer les servicesWeb redondants contenus dans le graphe de planification. Cependant, cette approche ne tient pas compte de la QoS dans le problème de composition du service Web. De plus, la solution obtenue est une solution réalisable qui peut contenir certains servicesWeb redondants. Sachant que la suppression des servicesWeb redondants n’affecte pas les valeurs fonctionnelles et QoS de la solution. En outre, les stratégies d’élimination des services redondants proposées dans le cadre de ce travail, d’autres travaux intéressants ont également été envisagés : l’élimination des services redondants [Yan et al. (2012); Rodriguez-Mier et al. (2015)], ou même se concentrer uniquement sur l’élimination des services redondants, tels que [Chen & Yan (2012)]. Les résultats présentés dans ces travaux démontrent leur efficacité. Cependant, le temps d’exécution reste à améliorer. Dans [Rodriguez-Mier et al. (2015)], les auteurs proposent deux méthodes d’ASC, de recherche lo- cale et de recherche globale. La recherche globale cherche à obtenir la composition avec un nombre minimum de services. Cependant, cela consomme beaucoup de temps et peut ne pas renvoyer au- cun résultat dans un délai raisonnable (5 minutes dans ce travail). Pour la recherche locale qui vise d’avoir un bon rapport temps d’exécution/service redondants, peut également contenir des services redondants.
10 Description de ServicesWeb Sémantiques
permettent plus d’interopérabilité entre applications provenant de différentes plate-formes mais certaines lacunes ont vite fait surface. Citons quelques exemples, la manque de la sémantique dans le standard de description de servicesWeb et l’ambiguïté dans la description de servicesWeb spécifiée selon certaines approches sémantiques. Souvent, durant la découverte ou la com- position, des exigences sémantiques sont relevées, telles que l’enrichissement des mécanismes d’annotation sémantique et ce qu’il engendrera d’amélioration des mécanismes de découverte. Cependant, ni les normes (telles que SOAP [3] et UDDI [3]), ni les langages de description ou de modélisation de processus métiers (tels que WSDL [15] et WS-BPEL [89]) ne considèrent l’en- jeu de la sémantique. En fait, SOAP n’est qu’un protocole de transport de messages XML entre les servicesWeb. UDDI est un modèle de description homogène d’annuaires de servicesWeb. Basé sur XML, WSDL est un standard de description qui reste purement syntaxique. Finalement, WS-BPEL est le standard de modélisation de processus métiers et l’orchestration de servicesWeb qui focalise sur la syntaxe. Ce manque de sémantique dans les langages de description et de modélisation pénalise à la fois la découverte et l’orchestration automatiques. En effet, d’éven- tuels problèmes d’hétérogénéités sémantiques s’imposent aux moments de découverte, invoca- tion voire conception des processus métier. La réponse à de telles exigences d’interopérabilité sémantiques a été retrouvée dans le Web sémantique. Les machines peuvent y coopérer grâce à un contenu de pages Web décrit explicitement avec une sémantique basée sur des ontologies de référence. En effet, ceci rend aujourd’hui les données compréhensibles autant par des agents logiciels que par des humains [5].
corr´ elation et nous ´ etudions les propri´ et´ es du mod` ele propos´ e. Finalement, la Section 5.4 pr´ esente et discute de diff´ erents patrons pour ces m´ ecanismes.
5.2 Les m´ ecanismes de corr´ elation et BPEL
L’une des exigences fondamentales pour l’´ echange d’informations via des ServicesWeb est la capacit´ e ` a assurer la persistance du contexte et l’´ etat ` a travers la d´ elivrance de plusieurs messages. Un environnement (framework) orient´ e services et d´ edi´ e ` a la communication est fondamentalement faiblement coupl´ e. De ce fait, il n’existe aucun m´ ecanisme intrins` eque qui permet d’associer, entre eux, les messages ´ echang´ es dans un contexte commun ou dans le cadre d’une activit´ e commune. Mˆ eme l’ex´ ecution d’un simple ´ echange bas´ e sur le mod` ele requˆ ete-r´ eponse ne fournit pas de moyen int´ egr´ e pour associer automatiquement le message de r´ eponse ` a la demande initiale. Or, un aspect cl´ e des processus m´ etiers, est que leur tˆ ache globale est divis´ ee en diff´ erentes sessions (appel´ ees instances de service), chacune ´ etant responsable de l’exploitation d’un service distinct ou travaille pour chacun des clients. Par cons´ equent, les instances de service doivent ˆ etre capables de garder l’´ etat (stateful).
5
informatiques critiques pour des grandes entreprises tels que pour les marchés boursiers et les systèmes de contrôle de circulation aérienne.
Un haut degré de fiabilité est nécessaire tout en échangeant des messages entre le client et le prestataire où pour des transactions importantes qui sont menées au cours de web pour des systèmes critiques ou décisionnelles. Alors la nature des problèmes de fiabilité qui peuvent menacer la sûreté de fonctionnement des servicesWeb est diversifiée. Parmi les problèmes qui peuvent survenir lors de l'exécution, et qu'un système lui-même devra faire face à eux d'une manière automatisée: est la concentration sur la phase de développement et de débogage d’un système en ignorant la phase de la configuration en cas de défaillance causée qui nuire un système et qui influence sur son comportement.
L’inclusion d’un système de définition de règles autant dans le client que dans les services Web permettrait d’utiliser des moteurs d’inférence pour établir le comportement de ces unités[r]
web d'achat et d'envoi de livres étant donnés le titre et un moyen de paiement 4 . Déjà
sur ces exemples le paiement s'effectue généralement via un service bancaire associé ainsi que la livraison qui est assuré par un service tiers de logistique.
Les problématiques associées aux servicesweb sont nombreuses. On peut citer la découverte (i.e. trouver des services correspondant à une requête utilisateur), la sélection (i.e. identifier le meilleur service parmi ceux découvert), la composition (i.e. construire un nouveau service à partir d'une combinaison de services existants), l’orchestration et la chorégraphie (i.e. coordonner une combinaison de services), la supervision (i.e. suivre l’exécution d’un service) , la simulation (i.e. tester avant déploiement), la vérification (i.e. s’assurer qu’un service va bien faire ce qu’il est censé faire) et le traitement d’exception (i.e. pouvoir gérer des erreurs au cours de l’exécution d’un service). La figure 3 en donne une illustration de scénarios prototypes.
∗∗ LAMSADE, Université Paris-Dauphine
{lynda.mokdad, samir.youcef}@lamsade.dauphine.fr + dans le cadre du projet ANR-06-SETI-002 Checkbound
RÉSUMÉ. La qualité de service (QoS) des servicesWeb est un facteur clef de leur réussite. Ceci nécessite le développement de nouvelles méthodes afin de l’analyser. Nous proposons ici des familles de modèles majorant le temps de réponse des servicesWeb composites pour deux types de composition : le « fork and merge » statique et aléatoire. Pour le premier cas, la complexité de résolution des modèles bornants est en O(n√n) où n est le nombre de services alors que
Différents travaux académiques ont abordé le test de conformité, d’interopérabilité et de robustesse des servicesWeb considérés comme des boîtes noires [83, 84, 85, 86, 87, 88, 89, 90, 91]. Salva et al. [83] ont proposé une méthode de test automatique des descriptions WSDL. Cette méthode est en mesure de générer des cas de test automatiquement, et de vérifier la gestion des exceptions, la gestion des sessions ainsi que l’existence des opérations. Salva et al. ont aussi décrit un Framework de test permettant d’exécuter les tests et de fournir un verdict de test. De leur coté, Bartolini et al. [84] ont proposé une approche de test automatique des descriptions WSDL, combinant à la fois la couverture des opérations (de l’interface WSDL) ainsi que la génération des données de test. En outre, ils ont défini une architecture de test intégrant deux outils existants : SoapUI [92], qui est un outil de test manuel des servicesWeb, et TAXI [93, 94], qui permet la dérivation automatique des instances XML conformes et représentatives d’un schéma XML. Dans ce travail, la génération de cas de test est basée sur des critères de couverture ainsi que l’application de certaines heuristiques. Ces dernières visent, en particulier, à combiner de façon variée les différents éléments instanciés (à partir d’un schéma XML d’un document WSDL), et à varier les cardinalités ainsi que les valeurs de données de ces instances.
Tous les éléments de l'architecture des services web utilisent XML pour représenter les descriptions avec WSDL, les stocker dans UDDI et échanger les messages de [r]
d’implémentation, des problèmes au niveau de l’environnement de test ou au niveau du nœud du SUT. Cependant, nous émettons l’hypothèse que les communications dans le réseau entre les nœuds de notre architecture de test sont fiables. Par conséquent, nous n’évoquons pas de problèmes au niveau du réseau. Nous soulignons que la contribution principale de notre tra- vail est la vérification des exigences des compositions de servicesWeb sous des conditions de charge diverses, ceci en proposant une solution rigoureuse de test fonctionnel et de charge à base de modèles Maâlej et Krichen (2016). Par ailleurs, les résultats finaux au sujet des comportements anormaux et des taux d’erreurs observées sont également fournis dans le but d’identifier et aborder les problèmes détectés sous charge. Certainement tous ces points rendent notre approche de test de charge plus riche et plus intéressante que celles existantes.
Sirin et al. [92℄ présentent une méthode semi-automatique pour la
omposition. La
omposition semi-automatique
onsiste à assister l'utilisateur lors de la
réation d'une
omposition. En fait, la
omposition est assistée par ordinateur. Sirin et al. proposent une méthode qui utilise DAML-S. La méthode proposée utilise les attri- buts fon
tionnels et des attributs non-fon
tionnels dénis dans le Servi
eProle pour proposer à l'utilisateur les servi
es qui semblent les plus appropriés pour répondre à sa requête. Pour
e faire, les attributs fon
tionnels
omme paramètres d'entrées et de sorties du servi
e sont représentés par des
lasses OWL [73℄ et sont ltrés par un moteur d'inféren
e basé sur OWL et Prolog. Le moteur d'inféren
e peut ordonner les servi
es Web ltrés en fon
tion de l'ordre d'éloignement des
on
epts. L'éloignement est un paramètre qui dénote l'importan
e des diéren
es entre les
lasses OWL. Pour aner le résultat, si plus d'une
orrespondan
e est trouvée, le système ltre le résultat en fon
tion des
ontraintes fournies par l'utilisateur sur les attributs non-fon
tionnels. Les attributs non-fon
tionnels sont les attributs utiles qui ne sont pas fournis par les attributs fon
tionnels, par exemple, la lo
alisation de la mesure lorsque le servi
e ne la fournit pas lui-même. Seuls les servi
es Web qui passent le ltre de
ontraintes sont présentés à l'utilisateur. La
omposition semi-automatique est attrayante
ar elle permet de surmonter les di
ultés liées, tout d'abord, à la
apture des besoins de l'utilisateur, puis à la
omposition automatique qui, le plus souvent, ne permet pas de garantir l'exa
titude de la
omposition. L'utilisateur étant pro-a
tif, il peut s'assurer que la
omposition est bien
elle qu'il souhaitait. De plus, la méthode proposée est simple et montre que la génération de servi
es Web
omposés peut être ee
tuée en
ombinant les fon
tionnalités de la ma
hine et les
ompéten
es de l'homme.
Nous avons développé : l’outil WSRDCreator pour la création de descriptions WSRD d’un ensemble d’annuaires, l’outil CommunityBuilder pour organiser des annuaires en communautés selon leu[r]
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignemen[r]
Dans ce qui suit, nous présenterons le cycle de vie d'un service web, puis nous nous attarderons sur le protocole SOAP, le langage WSDL, la base de données UDDI,[r]
Le Service des règles de gestion de la remise en charge : Ce service donn e l' ensemble des règles de gestio n qui décrivent la conn aissance liée à la remi se en c harge[r]
Figcire 7.1 : DistribLition normale utilisée pour les requêtes 73 Figure 7.2: Liste de propositions générées par CPA-NAFUR 76 Figure 7.3 : Liste de propositions générées par CP-KPPV 77 F[r]
Orchestrations et séparation des préoccupations Les orchestrations se présentent comme un ensemble de mécanismes pour la construction d’un nouveau service dit composite dans une applicat[r]
des standards (WSDL, SOAP, UDDI...) et des outils pour ces WebServices. Dans le cas du projet T@PA, nous avons souhaité évaluer l'apport d'une transition vers les WebServices en repensant l’architecture globale du projet, de manière à apporter une ouverture et une interopérabilité renforcée tout en assurant la compatibilité avec les standards en cours. Cependant les WebServices sont encore en évolution et leur utilisation nécessite de prendre des précautions dans le cadre d'un projet opérationnel. Nous avons donc décidé de mener une évaluation de ces technologies pour savoir si elles pourraient devenir le socle du projet T@PA. Avant d'envisager une nouvelle version de T@PA, il nous faut d'abord vérifier que cette transition n'affecte pas les performances de la plate-forme et prenne en charge toutes les conditions de sécurité et d'évolutivité qui ont ét é définies lors de la conception. Une difficulté de cette étude de faisabilité est que T@PA n'a pas été spécifiquement conçu ni développé pour le partage de services ou l'ouverture avec d'autres applications.