LES PRINCIPALES TECHNOLOGIES DE DEVELOPPEMENT DES SERVICES WEB

Télécharger le fichier pdf d’un mémoire de fin d’études

Description de services Web

Dans cette section nous discutons à la description des interfaces des services. Cette description peut porter sur les aspects structurels et/ou comportementaux des services, aussi bien que sur leurs aspects non-fonctionnels. Les langages présentés dans cette section sont fondés sur XML (Extensible Markup Language), XML est un standard de représentation de données semi-structurées [2].
Dans un document XML, la structure des données est fournie par le biais de l’utilisation de balises (comme en SGML Standard Generalized Markup Language [3], mais en s’affranchissant des aspects liés à la présentation des données). Cette structure n’est pas aussi rigide que celle d’une base de données relationnelle par exemple. Dans un document XML, les données peuvent être définies selon un schéma, mais cela n’est pas obligatoire et le schéma peut laisser quelques parties partiellement spécifiées.
Une problématique généralement associée à la description de services est celle de leur publication et de leur découverte. Un standard proposé pour s’attaquer à cette problématique est UDDI [4]. UDDI définit une interface de programmation pour publier des descriptions de services dans des répertoires dédiés, pour soumettre des requêtes à base de mots-clés sur ces répertoires et pour naviguer au travers des descriptions obtenues par le biais de ces requêtes.

Description fonctionnelle et structurelle WSDL

WSDL (Web Services Description Language) est un langage de la famille XML permettant de décrire les types de données supportés et les fonctions offertes par un service Web. L’objectif est de fournir la description, en XML, des services indépendamment de la plate-forme et du langage utilisés et sous une forme que des personnes ou des programmes peuvent interpréter. Les descriptions WSDL sont en fait l’équivalent des interfaces IDL (Interface Définition Language) de CORBA par exemple [5].
Dans le langage WSDL, un service est vu comme une collection de messages pour les échanges et d’une collection de points d’entrée. Un point d’entrée consiste en la description abstraite d’une interface et de son implantation. La description abstraite contient :
¾ la définition des messages qui sont consommés et générés par le service (les entrées et les sorties)
¾ la signature des opérations offertes par le service.

Description comportementale

La portée de WSDL est limitée la description des types des données incluses dans les messages qu’un service est capable de recevoir ou d’émettre. Dans de nombreuses applications, ces descriptions uniquement structurelles n’offrent pas assez d’information sur les contraintes régissant les interactions dans lesquelles un service peut ou est censé s’engager.
Dans certains cas, ces contraintes sont assez simples, comme par exemple : < le fournisseur n’envoie le bordereau de livraison qu’après avoir reçu la confirmation du paiement >. D’autres fois, ces contraintes peuvent être relativement complexes.
Plusieurs initiatives de recherche, de développement et de standardisation sont en cours afin de définir des langages de description de services prenant en compte des aspects comportementaux, et d’utiliser ces descriptions < comportementales >lors du développement et de l’exécution des services.
BPEL est un langage fondé sur XML et permettant de décrire aussi bien des interfaces comportementales que des orchestrations complètement exécutables. En quelques mots, BPEL permet de décrire des actions communicationnelles (envois et réceptions de message dont les types sont décrits en WSDL et XML Schéma), et de lier ces actions au travers d’opérateurs de flot de contrôle (par exemple la séquence, le choix, l’itération, et les clauses throw/catch pour le traitement des exceptions).

Description d’aspects non-fonctionnels < WS-Policy >

Les services Web étant généralement développés par des équipes indépendantes, ont besoin d’être décrits de façon précise selon des conventions standards, et de telle manière que leurs descriptions puissent être utilisées au maximum pour automatiser le processus de développement et de déploiement des futurs services devant interagir avec un service existant. WSDL et BPEL permettent de décrire les opérations fournies par un service Web, les types de données des messages devant être échangés pour invoquer ces opérations, et les dépendances comportementales entre ces opérations. Cependant, ils ne permettent pas de décrire des aspects non-fonctionnels des services tels que leur capacité à garantir une certaine qualité de service par rapport à des préoccupations telles que la sécurité, la fiabilité, la journalisation des accès ou la gestion de transactions.
Ce manque est en partie compensé par le concept de politiques d’usage. Une politique d’usage est une énonciation explicite des possibilités et des restrictions d’usage d’un service Web. < WS-Policy >est un langage extensible permettant d’exprimer des politiques (ou règles) d’usage sous forme de conjonctions et de disjonctions (au sens logique) d’assertions [6].

Les principales technologies de développement des 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 l’industrie. Dans cette section il y a une description de ces technologies.

XML (Extensible Markup Language)

Le langage XML (Extensible Markup Language) est un langage balisé, issu d’une recommandation W3C (WorldWideWeb Consortium), ayant pour but d’encoder tout type de données, indépendamment du code machine de celles-ci. Il a été développé dans le but de partager facilement des données entres différents systèmes et en particulier à travers un réseau Internet.

XML un descendant de SGML

SGML (Standard Generalized Markup Language) est un métalangage avec lequel il est possible de définir des langages balisés. Il est lui-même descendant de la recherche sur la théorie des langages et en particulier du langage GML (Generalized Markup Language) d’IBM. Il est devenu par la suite un standard ISO.
XML est un sous-ensemble simplifié du langage SGML (Standard Generalized Markup Language) et est utilisé dans de nombreuses technologies ou protocoles tels que (RDF, RSS, XHTML, Atom, MathML, …etc). Tous les langages dérivés présentent le même avantage : encoder de façon structurée l’information destinée à être partagée à travers un parc d’ordinateurs et de logiciels hétérogènes.
En plus d’avoir donné naissance à XML, SGML est également à la base du langage de balisage HTML, un des éléments clés d’Internet. Par contre, son petit frère, XHTML qui hérite les propriétés de XML, d’où les similitudes entre ces différents langages [7].

Codage des données et interopérabilité

XML permet d’écrire sous forme de fichier texte, dont le codage est exprimé en en-tête, tous les types définis eux-mêmes par un autre fichier XML. Ainsi, grâce à ces deux fichiers (l’un contenant les données, l’autre de description des types de données), n’importe quel logiciel pouvant accéder à des fichiers texte peut analyser les données.
Ce type de technologie est une solution, très utilisée aujourd’hui, pour permettre l’interopérabilité des logiciels à travers Internet. Il est vrai que la syntaxe XML est très verbeuse, ce qui la rend difficilement lisible pour un humain : mais c’est le prix à payer pour une compatibilité maximale et une description au mieux des données pour leur traduction informatique.
Son succès est grandissant, et de nouvelles technologies apparaissent comme AJAX par exemple, une technologie web basée sur la JavaScript, le XML et le XHTML, permettant de travailler les données du côté client pour en envoyer une version complète au serveur sans faire de requête entre chaque petite modification.

Utilisation des fichiers XML

Plusieurs méthodes permettent d’exploiter les données d’un fichier XML. Des méthodes permettent d’accéder à la donnée précise en parcourant le chemin hiérarchique lié au balisage du fichier : ce sont les technologies telles que le langage XPath. Il permet d’exploiter le fichier sans devoir construire une représentation complète en mémoire du fichier. D’autres technologies consistent à construire un arbre représentant le fichier XML dans son entier, les nœuds de cet arbre étant les différentes balises XML. Cet arbre s’appelle l’arbre DOM (Document Object Model). Une telle utilisation est difficilement concevable pour accéder aux quantités de données stockées dans une base de données XML, mais est totalement viable pour analyser un fichier de description simple de service web, par exemple.
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 livre (Figure I-1).

Enveloppe SOAP

Un message SOAP est composé d’un élément obligatoire appelé 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.
L’enveloppe SOAP est constituée d’un en-tête facultatif (SOAP header) et d’un corps obligatoire (SOAP body). Une description générale de l’enveloppe SOAP et ses composants est donnée par un extrait de code (Figure I-3).

En tête SOAP

L’en-tête peut avoir plusieurs fils (SOAP blocks). Ces fils sont utilisés pour ajouter des fonctionnalités au message comme l’authentification et la gestion des transactions. L’en-tê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 traitée par le destinataire. Le destinataire d’une entrée d’en-tête est défini par l’attribut d’acteur de SOAP. 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 ».
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 une URL. 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 une URL.

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 le processus comme le marshaling d’appels RPC et le rapport des erreurs.
Le corps SOAP peut contenir un SOAP fault. Ce bloc est utilisé pour transmettre l’information des erreurs durant le traitement du message.
Malgré que l’en-tête et le corps soient 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’en-tête destinée pour l’acteur de défaut et avec une valeur d’attribut mustunderstand de 1 (Figure I-3).

UDDI (Universal Description Discovery and Integration)

L’objectif primaire d’UDDI [8] 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 », qui 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 ce registre afin de chercher des descriptions publiées. Parce que les APIs d’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.

L’encapsulation de services natifs

Cette première activité permet de s’assurer que tout service peut être appelé lors d’une composition, indépendamment de son modèle de données, de son format de message, et de son protocole d’interaction.

L’établissement d’accord d’externalisation

Cette seconde activité consiste à négocier, établir, et appliquer des obligations contractuelles entre les services.

L’assemblage de services composants

Cette activité permet de spécifier, à un haut niveau d’abstraction, l’ensemble des services à composer afin d’atteindre l’objectif attendu. Cet assemblage comporte une phase d’identification des services et de spécification de leurs interactions conformément aux descriptions et aux accords entre services.

L’exécution de services composants

Cette activité consiste en l’exécution des spécifications de la composition précédemment définies.

Le contrôle de l’exécution de services composites

La phase de contrôle permet de superviser l’exécution de la composition en vérifiant, par exemple, l’accès aux services, les changements de statut, les échanges de messages. Ce contrôle permet de détecter des violations de contrats, de mesurer les performances des services appelés et de prédire des exceptions.

L’évolutivité des services

Cette dernière phase permet de faire évoluer la composition en modifiant les altérations de l’organisation de services, en utilisant de nouveaux services, ou en prenant en compte les retours de la phase de contrôle.

Types de composition de services Web

La plupart des travaux portant sur la composition de services Web reconnaissent deux types de composition : l’orchestration et la chorégraphie de services. Cependant, selon les travaux, les définitions des types de composition diffèrent.
¾ l’orchestration et la chorégraphie sont des moyens de concevoir la composition [12].
¾ tandis que l’orchestration et la chorégraphie sont des points de vue de la composition de services [13].

Orchestration

L’orchestration est un ensemble de processus exécutés dans un ordre prédéfini afin de répondre à un but [13]. Ce type de composition permet de centraliser l’invocation des services Web composant. Chaque service est décrit en termes d’actions internes. Les contrats entre deux services sont constitués selon le processus à exécuter.
L’orchestration est un ensemble d’actions à réaliser par l’intermédiaire de services Web. Un moteur d’exécution, un service Web jouant le rôle de chef d’orchestre, gère l’enchaînement des services Web par une logique de contrôle. Pour concevoir une orchestration de services Web, il faut décrire les interactions entre le moteur d’exécution et les services Web. Ces interactions correspondent aux appels, effectués par le moteur, d’action(s) proposée(s) par les services Web composants [13].
L’orchestration de services Web consiste en la programmation d’un moteur qui appelle un ensemble de services Web selon un processus prédéfini. Ce moteur définit le processus dans son ensemble et appelle les services Web (tant internes qu’externes à l’organisation) selon l’ordre des tâches d’exécution. La Figure I-6 illustre l’exécution du moteur (lui-même un service Web – Service Web Moteur) permise par l’enchaînement de l’exécution de deux autres services Web (le Service Web 1 puis le Service Web 2).
Cet enchaînement est possible via un opérateur d’ordonnancement (représenté par le losange). L’exécution de la composition repose sur l’appel du Service Web 1, puis sur l’appel du Service Web 2, réalisés tous deux par le Service Web Moteur [12].

Table des matières

INTRODUCTION GENERALE
CHAPITRE I : ARCHITECTURE DES SERVICES WEB
PARTIE 1 : ARCHITECTURE DES SERVICES WEB
I.1. INTRODUCTION
I.2. SERVICES WEB : DEFINITION ET PRINCIPES
I.3. DESCRIPTION DE SERVICES WEB
I.3.1. Description fonctionnelle et structurelle WSDL
I.3.2. Description comportementale
I.3.3. Description d’aspects non-fonctionnels < WS-Policy >
I.4. LES PRINCIPALES TECHNOLOGIES DE DEVELOPPEMENT DES SERVICES WEB
I.4.1. XML (Extensible Markup Language)
I.4.1.1. XML un descendant de SGML
I.4.1.2. Codage des données et interopérabilité
I.4.1.3. Utilisation des fichiers XML
I.4.2. SOAP (Simple Object Access Protocol)
I.4.2.1. Modèles d’échange de messages en SOAP
I.4.2.2. Enveloppe SOAP
I.4.2.3. En tête SOAP
I.4.2.4. Corps SOAP
I.4.3. Apatche-Axis Une mise en œuvre de SOAP
I.4.4. WSDL (Web Service Description Language)
I.4.5. UDDI (Universal Description Discovery and Integration)
I.5. CYCLE DE VIE DES SERVICES WEB
I.6. AVANTAGES DES SERVICES WEB
I.7. LIMITES DES SERVICES WEB
PARTIE 2 : COMPOSITION DES SERVICES WEB
I.8. DEFINITIONS ET TYPES DE COMPOSITION DE SERVICES WEB
I.8.1. Définitions
I.8.1.1. L’encapsulation de services natifs
I.8.1.2. L’établissement d’accord d’externalisation
I.8.1.3. L’assemblage de services composants
I.8.1.4. L’exécution de services composants
I.8.1.5. Le contrôle de l’exécution de services composites
I.8.1.6. L’évolutivité des services
I.8.2. Types de composition de services Web
I.8.2.1. Orchestration
I.8.2.2. Chorégraphie
I.8.3. Langages de composition de services Web
I.8.3.1. XLANG (XML Business Process Language)
I.8.3.2. BPML (Business Process Modeling Language)
I.8.3.3. WSFL (Web Service Flow Language)
I.8.3.4. WSCL (Web Service Conversation Language)
I.8.3.5. WSCI (Web Service Choreography Interface)
I.8.3.6. BPEL4WS
a. Le processus abstrait
b. Le processus exécutable
I.8.3.7. WS-CDL (Web Services Choreography Description Language)
I.9. CONCLUSION
CHAPITRE II : LES PLATES-FORMES COLLABORATIVES
II.1. INTRODUCTION
II.1.1. Les Outils Synchrones
II.1.2. Les Outils Asynchrones
II.2. DEFINITION DE TRAVAIL COLLABORATIVE
II.3. CATEGORIE DES SYSTEMES COLLABORATIFS
II.3.1. Les collecticiels
II.3.2. Le Workflow
II.4. LES PRINCIPAUX PLATES-FORMES EXISTANTES
II.4.1. SAKAI
II.4.2. Open-Xchange
II.4.2.1. Présentation
II.4.2.2. Fonctionnalités de Open-Xchange Server
II.4.3. Silverpeas
II.4.3.1. Des services collaboratifs
a. Le service« ALMANACH »
b. Le service« CHAT »
c. Le service « ANNUAIRE »
d. Le service « ENQUETE »
e. Le service « FORUM »
f. Le service de « GESTION DE PROJET » – (PROJECT ORGANIZER)
g. Le service « PLAN D’ACTION »
h. Le service « QUIZ »
i. Le service « NEWS »
j. Le service « BLOG »
k. Le service « GALLERY » (BANQUE D’IMAGES)
l. Le service « SILVERCRAWLER »
m. Le service de NOTIFICATION
n. WORKFLOW DE CIRCULATION DES INFORMATIONS
II.4.3.2. Des services de GED et de gestion de connaissances
II.4.4. Xwiki
II.5. CONCLUSION
CHAPITRE III : ARCHITECTURE PROPOSEE
III.1. INTRODUCTION
III.2. L’OUTIL OPEN SOURCE
III.2.1. Définition
III.2.2. La licence open source
III.2.2.1. Libre redistribution
III.2.2.2. Code source
III.2.2.3. Travaux dérivés
III.2.2.4. Intégrité du code source de l’auteur
III.2.2.5. Pas de discrimination entre les personnes ou les groupes
III.2.2.6. Pas de discrimination entre les domaines d’application
III.2.2.7. Distribution de la licence
III.2.2.8. La licence ne doit pas être spécifique à un produit
III.2.2.9. La licence ne doit pas contaminer d’autres logiciels
III.3. L’INTEGRATION DES APPLICATIONS AU SEIN D’UN ENVIRONNEMENT COLLABORATIVE
III.3.1. Les problèmes liés à l’intégration d’applications
III.3.1.1. La complexité
III.3.1.2. Une programmation redondante et ne pouvant être réutilisée
III.3.1.3. Des interfaces multiples
III.3.2. Les exigences de la programmation d’aujourd’hui
III.3.2.1. L’exploitation du parc informatique existant
III.3.2.2. La prise en charge de tous les types d’intégrations requis
III.3.2.3. La possibilité de mises en œuvre incrémentielles et de migration du parc
III.3.2.4. La constitution dans un cadre de composants standards
III.3.2.5. La possibilité de mise en œuvre de nouveaux modèles informatiques
III.3.3. Une architecture orientée services : au-delà des services Web
III.3.3.1. Les éléments constitutifs d’une architecture orientée services
III.3.3.2. La nature d’un service
III.3.3.3. L’intégration d’applications
III.3.3.4. Les exigences d’intégration au sein de l’architecture
a. L’intégration au niveau de l’interface
b. La connectivité d’applications
c. L’intégration des informations
III.4. ARCHITECTURE PROPOSEE
III.4.1. Architecture orientée service (SOA)
III.4.2. Difficultés rencontrées dans la réalisation d’une plate-forme collaborative complète
III.4.3. Vers l’intégration d’applications existantes
III.4.4. Architecture proposée
III.5. CONCLUSION
CHAPITRE IV : EXPERIMENTATION
IV.1. INTRODUCTION
IV.2. LA PLATE-FORME SILVERPEAS
IV.2.1. Présentation de la plateforme silverpeas
IV.2.2. La Structure de Silverpeas
IV.2.2.1. Administration
IV.2.2.2. Le Bus
IV.2.2.3. Services
IV.2.3. L’architecture de Silverpeas
IV.3. LA PLATE-FORME XWIKI
IV.3.1. Installation de Xwiki
IV.3.1.1. Configurer Tomcat
IV.3.1.2. Configurer MySQL
IV.3.1.3. Démarrer Xwiki
IV.3.2. Architecture de la plate-forme Xwiki
IV.4. QUELQUES SCENARIOS DE TEST
IV.4.1. L’espace personnel
IV.4.2. Moteur de recherche
IV.4.3. Barre D’outils
IV.4.4. Page d’accueil
IV.4.5. Logo Silverpeas
IV.4.6. Espaces et Services
IV.5. LES SERVICES DE LA PLATE-FORME
IV.5.1. Attribution des Rôles
IV.6. CREER UN ESPACE OU UN SOUS ESPACE
IV.7. OUVRIR XWIKI
IV.8. CONCLUSION
CONCLUSION
RÉFÉRENCES

Télécharger le rapport complet