Concepts généraux
Un service Web est :
- une « unité logique applicative » accessible en utilisant les protocoles standard d' Internet
- un «composant» fournissant des données et des services à d'autres applications.
Les WebServices combinent les meilleurs aspects du développement à base de composants et du Web.
Ils s'appuient sur un ensemble de standards (WSDL, SOAP, XML-RPC et UDDI).
Définition
A Web service is a software application identified by a URI, whose interfaces and binding(1) are capable of being defined, described and discovered by XML artefacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols. (W3C definition)
Un service Web est une application logicielle identifiée par une URI dont les interfaces et les liaisons sont définies, décrites et découvertes en XML. Il supporte une interaction directe avec les autres applications logicielles en utilisant des messages XML via un protocole Internet.
Objectifs
- capable d'inter-opérer avec les applications existantes
- capable d'inter-opérer avec le monde extérieur : Extranet (B2B)
- capable d'inter-opérer avec le monde intérieur : Intranet (B2C)
- indépendant des technologies implémentées
- offrant un accès rapide, intégré et généralisé à l'information pertinente
- offrant des outils de travail, de communication, ...
Système réduisant les coûts
- développement rapide d'applications (RAD)
- utilisation de composants distribués et de ressources distantes
- réduction des coûts de développement
Système fournissant une administration simplifiée
- depuis le Web avec des outils d'assistance
Pourquoi ?
Évolution des solutions Middleware
- RPC : Remote Procedure Call
- MOM : Message Oriented Middleware (MQ Series, JMS)
- Objet Distribué (COM, DCOM, CORBA, RMI, EJB)
- Base de Données Orientées Middleware
Remote Procedure Call (RPC)
Principe d'appel de procédure type client/serveur s'exécutant sur une machine distante dans un environnement d'applications distribuées.
- Un des plus vieux middlewares
- Fonctionne de manière synchrone
- Facile à comprendre et à coder
- Nécessite beaucoup de ressources
- Complexe à administrer
- Pas de standards / Implémentation spécifique à un vendeur
- Ne supporte pas la POO
Message Oriented Middleware
Utilisation de messages asynchrones pour faire communiquer les applications
- Les avantages
- Faible couplage
- Garantie de livraison
- Mécanisme de persistance
- Les inconvénients
- Risque de surcharge du système
- Implémentation propriétaire ( msg + architecture)
- Plus le système est grand et hétérogène, plus l'administration est difficile
- Peu portable et peu interopérable
Les objets distribués
CORBA : Common Object Request Broker Architecture
Norme de communication utilisée pour l'échange entre objets logiciels hétérogènes.
Un langage, IDL (Interface Definition Language) décrit les traitements effectués et les formats de données en entrée et en sortie. Un bus applicatif, ORB (Object Request Broker) constitue le coeur de CORBA par lequel les requêtes sur les objets transitent.
- Les avantages
- Indépendant du système d’exploitation et du langage de programmation.
- Permet l’intégration des systèmes propriétaires grâce à l’IDL
- CORBA standardisé par l’OMG
- CORBA intègre les aspects métiers.
- La version 2.3 interopère avec RMI
- Les inconvénients
- Incompatibilité entre les implémentations
- CORBA complexe à appréhender et à mettre en place.
- Problème de pare-feu
- Sécurité et administration
- Pas aussi simple qu’on pense, nécessite des changements dans les applications…
RMI : Remote Method Invocation
Le but de RMI est de permettre l'appel, l'exécution et le renvoi du résultat d'une méthode exécutée dans une machine virtuelle différente de celle de l'objet l'appelant
- Avantages
- Plus simple que le développement des sockets JAVA
- Supporte la POO
- Rend Transparent les communications entre objets
- Permet une gestion distribuée des ressources
- Inconvénients
- Limité à la plate-forme JAVA
- Architecture fortement couplée
- Pas de gestion de session
Modèle de Microsoft pour le développement de composants logiciels réutilisables, orientés objet et indépendants du langage de programmation.
DCOM est le successeur de COM et intègre le multi-machine.
- Les avantages
- Simple d’utilisation.
- Portabilité binaire
- Les inconvénients
- Spécifique à Microsoft
- Problème de gestion des états et de sessions
- Pas de portabilité du code
Intérêt
- Ils utilisent XML pour l’échange des données et messages.
- Ils permettent l’intégration de plates-formes hétérogènes via le protocole HTTP
- L’utilisation du protocole HTTP facilite le passage des pare-feux
- Les développeurs ont l’embarras du choix en matière de langage de programmation : Java, C, C++, Perl, Python, Ruby, C#, et/ou Visual Basic,
- Ils nécessitent peu ou pas de modification des applications existantes
- Ils permettent un couplage faible, les composants sont simples mais peuvent résoudre des problèmes complexes.
- Ils peuvent être créer facilement une fois l’application terminée pour exposer un service sur le net
- Il n’existe pas de client propriétaire
- Des outils de développement et de déploiement sont fournis par les principales plateformes J2EE et Microsoft .NET
- La localisation et l’invocation dynamique d’autres services est possible à partir de registres privés ou publics
Technologies
XML
- Échange de messages XML entre client et serveur
- Lisible, structuré
HTTP, SMTP
- Réutilisation des standards usuels d’Internet
SOAP
- Protocole définissant les échanges XML entre entités
WSDL
- Langage de description technique des services web proposés
UDDI
- Annuaire des services web disponibles et des fournisseurs de ces services
Les acteurs
Service Provider (Fournisseur de service)
Application s'exécutant sur un serveur et comportant un module logiciel accessible par le Web en XML
Service Registry (Annuaires de service)
Annuaire des services publiés par les providers (UDDI)
Géré sur un serveur niveau application, entreprise ou mondial
Service Requester (Demandeur de service)
Application cliente se liant à un service et invoquant ses fonctions par des messages XML (SOAP)
.NET / J2EE
.Net (Microsoft)
- .net Framework SDK (//msdn.microsoft.com/webservices)
- Support depuis Visual Studio .Net
- Développement en tout langage (VB, C++, C#)
- Deux composants essentiels
- Common Language Runtime (MSIL)
- .net class Libraries (GUI, DB, ASP, …)
J2EE (Sun)
- API spécialisée pour Java-XML (JAX)
- Java API for XML Processing (JAXP)
- Java Architecture for XML Binding (JAXB)
- Java API for XML Messaging (JAXM)
- Java API for XML-based RPC (JAX-RPC)
- Java API for XML Registries (JAXR)
- Java API for XML Web Services (JAX-WS)
Produits
Apache SOAP (Apache project)
Servlet permet de déployer les services
Appel servlet depuis SOAP
Générateur WSDL à partir de classe Java ou EJB
Générateur de Proxy client Java
Metro
Implémentation de référence (jax-ws)
Autres
BEA (Oracle), Broadvision, etc.
Synthèse
Web Services
- Invocation dynamique de services WEB décrits en WSDL
- Intégrité et typage des données (schémas XML)
- Possibilité de découvrir dynamiquement les services (UDDI)
- Lisibilité et sécurité renforcée (filtrage dans les pare-feu)
- Indépendance des constructeurs (W3C)
- Intégration des transactions, des workflows et de la sécurité en cours
SOAP
protocole d'invocation de services Web sur HTTP
- Lisible et extensible
- Intégré à HTTP
- Passant les firewalls
- Description en WSDL
- Pousser par Microsoft, IBM, Ariba
Les inconvénients
Sécurité faible
- Entête SOAP n’implémente pas nativement la sécurité
- Attaques par DOS (Deny Of Service)
Problèmes liés à HTTP / Internet
- Absence de qualité de service
- Temps de transmission variable
- Pas d’accusé de réception
- Blocage d’application
SOAP inadapté à l’approche synchrone
- Temps d’exécution variable
- Latence du réseau
- Pas d’information d’avancement
- Pas d’information de « panne »
Références
- Qu'est-ce que SOAP
- Les Web Services et le Service Web
- Les Bases de SOAP