Soutenance mémoire
Introduction aux services Web
De plus en plus, avec l’essor d’Internet, le développement tend vers les technologies du Web. Il n’est pas évident de distinguer les différents logiciels qui sont de plus en plus intégré au WEB. Les Web Services sont des applications modulaires basées sur Internet qui exécutent des tâches précises et qui respectent un format spécifique. On peut trouver également une autre définition montrant qu’un service Web correspond à une extension du Web le faisant passer d’une infrastructure proposant des services aux personnes à une infrastructure offrant des services à des logiciels qui cherchent à coopérer avec d’autres logiciels [1].
Historique des services Web
Les services web prennent leur origine dans les systèmes repartis e t dans l’avènement du Web. Les systèmes repartis datent des années quatre-vingt avec la migration progressive de systèmes centralisées (où tous les traitements, incluant la gestion des données et celle des calculs, sont exécutés depuis une unique et volumineuses application) vers des systèmes repartis. Le but de la répartition est de permettre à une application sur une machine d’accéder à une fonction d’une autre application sur une machine distante et ce, de la même manière que l’appel d’une fonction locale, indépendamment des plates-formes et des langages utilisés. Donc on peut imaginer que l’application est divisée en plusieurs morceaux, chaque morceau peut être développé dans un langage de programmation différent et exécuté depuis un système d’exploitation différent. Egalement, il est important de noter que chaque morceau joue un rôle différent pour les traitements du système d’information. Actuellement trois standards sont utilisés pour mettre en pratique les applications reparties, chacun de ces st andards offrent des mécanismes de récupération d’espace mémoire, de sécurité, de gestion du cycle de vie des objets. Il s’agit du standard CORBA/IIOP (Common Object Request Broker Architecture / Internet Inter-ORB Protocol) spécifié par l’OMG (Object Management Group), de la standard DCOM (Distributed Component Object Model) de Microsoft et RMI (Remote Method Invocation) de Sun. Le choix entre ces standards est lié à la plate forme employée. DCOM s’impose rapidement comme la solution de développement pour la plate forme Windows. Par contre, CORBA s’impose comme la solution inter patesformes (Unix, Windows).
Mais le problème qui se pose est comment faire collaborer d es environnements reparties (établir des liens entre ces environnements). Ce problème peut arriver en pratique dans le cas d’une fusion entre deux entreprises ayant fait dans le passé un choix différent en terme d’environnement reparti. Avec l’apparition des termes B2B (Business to Business) et B2C (Business to Customer) qui désignent respectivement des plates f ormes de gestion des échanges commerciaux entre entreprises ou d’une entreprise vers ses clients par l’intermédiaire de l’internet, il était clair aux yeux des entreprises la nécessité de tels technologies, qui permettent non seulement de faire des liens de communications entre ces entreprises, mais également qui limitent la nécessité d’un système de middleware réparti commun pour pouvoir communiquer. La solution c’est un modèle d’architecture solide basé seulement sur des protocoles et des technologies de communication interopérables sur Internet.
C’est l’apparition des services Web. L’apport principal des services web est la solution au problème d’hétérogénéité par rapport aux plates-formes et langages des applications. En fin, les services permet non seulement des conserver les caractéristiques des architectures distribuées (comme CORBA ou RMI) qui est indispensable pour répondre aux besoins en terme de complexité des applications d’entreprises, mais permet également de satisfaire les contraintes imposées par le WEB, à savoir : client léger qui est souvent réduit à un simple navigateur et la mise en œuvre du protocole HTTP.
Définition des services Web
W3C définit un service Web comme une application logicielle identifiée par un URI dont les interfaces et les liaisons sont définies, décrites et découvertes en XML et supporte une interaction directe avec les autres applications logicielles en utilisant des messages XML via un protocole Internet [2].
Caractéristiques
Le service web se caractérise en effet par une standardisation des implémentations, par une localisation à distance des services et par une récupération de l’interface d’accès permettant l’exécution du traitement correspondant. Mais les caractéristiques principales sont :
❖ Réutilisable : Une fonctionnalité développée sous forme de Web services peut dorénavant être réutilisée et recombinée à u ne suite d’autres fonctionnalités pour composer une nouvelle application.
❖ indépendamment de la plate-forme (UNIX, Windows,…), de leur environnement d’implémentation (Java, C++, Visual Basic,…) et de l’architecture sous-jacente (.NET, J2EE,…) ;
❖ Web based : les Web services sont basés sur les protocoles et les langages du Web, en particulier HTTP et XML.
❖ Self-described, self-contained : le cadre des Web services contient en lui-même toutes les informations nécessaires à l’utilisation des applications, sous la forme de trois fonctions : trouver, décrire et exécuter.
❖ Modular: les Web services fonctionnent de manière modulaire et non pas intégrée. Cela signifie, qu’au lieu d’intégrer dans une seule application globale toutes les fonctionnalités, on crée (ou on récupère) plusieurs applications spécifiques qu’on fait inter-coopérer entre elles et qui remplissent chacune une de ces fonctionnalités.
Les spécifications de services Web
Les éléments qui constituent la mise en œuvre d’un service web sont :
❖ Le protocole d’accès ;
❖ La description du service ;
❖ L’annuaire des services.
Protocole d’accès (SOAP)
Pour accéder aux services web l’architecture est basée sur le protocole SOAP (en anglais, Simple Object Access Protocol). Le protocole SOAP est un s tandard qui permet la communication entre applications pour l’accès aux services web. Il identifie le réseau internet comme le réseau utilisé pour accéder aux services web, mais il n’identifie pas nécessairement le protocole de niveau application qui sera utilisé pour réaliser cette communication. En effet, plusieurs protocoles de communication sur l’Internet peuvent être utilisés avec SOAP comme par exemple HTTP, SMTP), mais ce standard recommande l’utilisation du protocole HTTP comme protocole de communication principal des services Web. Cette recommandation vient du fait que le protocole http est largement accepté, et qu’il a montré sa capacité à gérer les très nombreux échanges sur Internet. SOAP est développé conjointement par Microsoft, IBM, Lotus Development (une division d’IBM), DevelopMentor et UserLand Software sous les auspices du W3C. SOAP 1.1 f it l’objet d’une note soumise au W3C en mai 2000, et SOAP 1.2 d’ un document de travail (working draft) en juillet 2001 [3]. Ce protocole est indépendant des langages de programmation ou des systèmes d’exploitation employés pour l’implémentation des services Web. Il r epose sur XML et sur quelques standards dérivés, les NameSpaces et XML Schema, en particulier.
La description du service (WSDL)
C’est une description basée sur le langage XML, qui indique quelles sont les opérations disponibles?, comment on y accède (adresse, protocole, …) ?, quel est le format de messages échangés entre le client et le serveur :
❖ pour invoquer le service ?;
❖ pour interpréter les résultats ?
La description est réalisée en se basant sur le langage WSDL (Web Service Description Language, en français un langage XML de description de service Web) qui est une grammaire dérivée de l’XML. Cette description permet de cacher les détails de l’implémentation du service, ce qui permet d’offrir une utilisation indépendante de la plate forme et du langage utilisés. Le langage WSDL est une proposition conjointe des sociétés Ariba, IBM et Microsoft auprès du W3C dont la première spécification fut publiée en septembre 2000 [1]. Le W3C vient de finaliser la version WSDL 2.0 ( 27 juin 2007) prenant complètement en charge le principal protocole Web, HTTP, ainsi que le protocole de services Web le plus couramment utilisé, SOAP. WSDL 2.0 intègre les correctifs apportés à WSDL 1.1 par le profil WS-I Basic, offre des fonctions améliorées de description de fautes et d’erreurs, d’héritage et d’importation plus nombreuses, et prend en compte HTTP et SOAP.
|
Table des matières
Introduction
I. Architecture orientée services
A. Qu’est-ce qu’un service
B. Les éléments du service
C. Contrat de service
D. Le base de l’AOS
E. L’agrégation et la dissémination de service
F. L’architecture orientée services && les services Web
G. Conclusion
II. Introduction aux services Web
A. Historique des services Web
B. Définition des services Web
C. Caractéristiques
D. Les spécifications de services Web
1. Protocole d’accès (SOAP)
2. La description du service (WSDL)
3. L’annuaire des services (UDDI)
E. Conclusion
III. Les Services Web Composites
A. Description et fonctionnement
1. Chorégraphie
2. Orchestration
B. Conclusion
IV. Réseaux d’automates stochastiques
A. Introduction
B. Méthodes d’évaluation de performances
C. Réseaux d’automates stochastiques
1. Terminologie
2. Automates, Événement Synchronisant et Transition Fonctionnelle
D. PEPS
1. Format textuel
2. Structure de données
3. L’agrégation
4. Méthodes Itératives de Résolution des RAS
5. LA structure des fichiers générés par PEPS
E. Conclusion
V. Modélisation des services Web composite
A. Principe de fonctionnement des services Web composite
B. Modèle d’essai
C. Les hypothèses
D. Modélisation
E. Les critères de performances
1. La Longueur des files d’attente au niveau des différents routeurs
2. Taux d’utilisation des différents routeurs
3. Charge du system
4. Taux d’utilisation des différents WEB services
VI. Conclusion et perspectives
VII. Annexe
A. Processus BPEL correspondant à l’exemple d’Agence de voyage
VIII. Références bibliographiques
