|
|
 |
Services Web : les protocoles standards |
|
Plan
Objectif
Avantages
Mise en place
Exemple d'architecture Générale
SOAP
WSDL
UDDI
Protocole Collaboratif
Alternative
Les commentaires sur cet article
Objectif
Le Web service est un concept inventé par HP (nommé alors e-services et implémenté par le middleware e-speak) dans un contexte d'EAI (intégration d'applications d'entreprise). Ce document va traiter des protocoles standards défissant ces services web.
Avantages
- Facilite l'EAI (interopérabilité des différents modèles de composants en interne comme en externe)
- Utilisation et intégration très facilitées de composants métiers de partenaires
- Facilite le déploiement de composants distribués (en interne ou chez les partenaires, limités souvent à de simples copies de fichiers)
- Facilite l'agrégation de composants dans un EIP (Enterprise Information Portal - Portail d'entreprise)
- Agrégation de plusieurs services sur un même site (horaires/réservation train, assurance, hôtel...)
- Décomposition d'une application en briques fonctionnelles (les applications ne sont plus que des assemblages de briques)
Mise en place
Remplacement des objets distribués traditionnels Corba, COM, EJB qui ne transmettent pas la structure (car elle est connu, elle est propriétaire).
Il faut définir des entités fonctionnelles qui pourraient intéresser d'autres applications (internes comme externes). Ces entités seront alors packager avec les protocoles des services web.
Appel asynchrone
Un service web peut prendre 5 voire 10 secondes à répondre. Cependant, l'internaute ne peut pas attendre plus de 3 secondes devant un navigateur qui réfléchit (et affiche donc une page blanche). La solution consiste à appeller le service web de façon asynchrone :
- 1 : Appel du service web (mais redonne la main)
- 2 : On teste périodiquement si nos résultats sont disponibles
- 3 : Dès que les résultats sont disponibles, on utilise une méthode qui les récupère
Exemple d'architecture Générale
Article du 01 Informatique n°1663 résumant les avantages des services web.
SOAP - Simple Object Access Protocol
SOAP est un mécanisme de type RPC (Remote Procedure Call).
C'est un protocole de communication interapplicatif, constitué d'un ensemble de règles communes pour structurer les messages XML et invoquer un service Web.
SOAP est porté par http (serveur web) ou par smtp (serveur de messagerie).
Le fait que SOAP passe par http permet de faire communiquer des applications qui sont séparées par des firewalls (le port 80 n'est pas bloqué par les pare-feu contrairement). Ceci est une grande différence avec les modèles comme DCOM ou Corba ou les protocoles RMI et IIOP nécessites l'ouverture de ports particuliers sur les pare-feu.
Le fait que SOAP reformate http (échange de documents XML et non de données binaires) oblige l'utilisation de clients SOAP au niveau de l'émetteur et du récepteur (encodant ou décodant du SOAP).
Le proxy SOAP traduit le XML reçu au format Corba, DCOM, J2EE...
Le problème majeur de SOAP est qu'il est dépourvu de QoS.
Le problème consiste à l'absence de rapport d'erreur : on ne sait pas pourquoi un service web ne répond pas (requête non arrivée, Web Service en panne, n'existe plus, a été modifié...).
L'Oasis (Organization for the Advancement of Structured Information Standards - soutenue par BEA, HP et Sun) met au point une norme BTP (Business Tansaction Protocol) qui enrichit Soap avec des fonctions de validation (commit) ou d'annulation des transactions.
WSDL - Web Service Description Language
WSDL langage basé sur XML, décrit les fonctionnalités, l’interface d’un service Web.
C'est en quelque sorte une API universelle, une enveloppe permettant de publier et d'appeler de facon homogène les méthodes d'un composant (où qu'il se trouve et quelque soit la technologie utilisée).
UDDI
UDDI est un répertoire ou annuaire permettant de retrouver tous les types de services Web.
Techniquement, l'interogation s'effectue via une requete SOAP avec en retour, des services sous forme d'une liste d'URL des WSDL concernés.
La spécification UDDI est divisée en trois parties :
- les pages blanches, comprenant les informations sur les entreprises
- les pages jaunes, répertoriant les services Web par catégorie (par exemple, «Service d’autorisation de carte de crédit»)
- les pages vertes, fournissant des informations techniques détaillées sur les services individuels.
Processus collaboratif
Workflow applicatifs comme Xlang (Microsoft), WSFL (Web Service Flow Language - IBM) qui décrivent les services web
à utiliser, l'enchaînement des appels, que faire en cas de non réponse d'un service web (intérogation d'un annuaire UDDI pour rechercher un service similaire).
Seul Sun n'a pas rejoint consortium WS-I (Web Services Interoperability Group) pour améliorer l'interopérabilité des Web Services.
Alternative : JXTA (juxtapose) de Sun
Cet ensemble de protocoles, basé sur une architecture distribuée, permet aux applications de communiquer et de fonctionner dans un environnement P2P (Peer-to-Peer). Le gros avantage du P2P est la répartition de la charge sur tout le réseau.
JXTA permet d'implémenter n'importe quel langage sur n'importe quel OS (ouverture vers le matériel "non PC" comme les téléphones).
Tout en étant décentralisé (P2P), un module centralisé (comme une application de type messagerie instannée) pourra être facilement ajouté à une autre application (si les deux applications supportent les protocoles Juxta). A noter,
les messages interpeers dans Jxta sont des documents XML (interopérabilité possible avec les services web via XML-RPC ou même SOAP).
Ce projet open-source est lancé depuis avril 2001. Certains éléments de Jxta sont déjà intégrés dans Sun ONE.
Jxta est open source au contraire de la JVM. La description des interfaces (Services Web via des SOAP et WSDL) s'opère avec des protocoles non standards.
Draft
Dernière MAJ : 13 Mars 2002
Les articles du Forum traitant du même sujet
N'hésitez pas à faire un commentaire sur ce sujet en cliquant sur le lien suivant
