Web services

Service Web

Un service web est un programme informatique permettant la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués. Il s'agit donc d'un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et pour des applications ou machines, sans intervention humaine, et en temps réel^{[réf. nécessaire]}.

Le concept a été précisé et mis en oeuvre dans le cadre de Web Services Activity^[1], au W3C, particulièrement avec le protocole SOAP. Associé avec les Échanges de Données Informatisés (EDI), le consortium ebXML l'a utilisé pour automatiser des échanges entre entreprises. Cependant le concept s'enrichit avec l'approfondissement des notions de ressource et d'état, dans le cadre du modèle Rest, et l'approfondissement de la notion de service, avec le modèle SOA.

Il existe plusieurs technologies derrière le terme services web :

• Les services web de type Representational state transfer (REST) exposent entièrement ces fonctionnalités comme un ensemble de ressources (URI) identifiables et accessibles par la syntaxe et la sémantique du protocole HTTP. Les Services Web de type REST sont donc basés sur l'architecture du web et ses standards de base : HTTP et URI.

• Les Services Web WS-* exposent ces mêmes fonctionnalités sous la forme de services exécutables à distance. Leurs spécifications reposent sur les standards SOAP et WSDL pour transformer les problématiques d'intégration héritées du monde Middleware en objectif d'interopérabilité. Les standards WS-* sont souvent décriés comme l'étaient leurs ancêtres CORBA, RMI ou DCOM : des technologies complexes héritées du vieux principe RPC, fortement couplées et difficilement interopérables dans des environnements hétérogènes. A contrario, le Web est par nature une plateforme interopérable.

Les Services Web de type Representational state transfer (REST)

Introduction

Le World Wide Web est une application conçue selon l'architecture REST. L'architecture du Web remplace donc les concepts applicatifs clients et serveurs par les concepts agents et ressources. Des agents interagissent avec des ressources pour créer, accéder, modifier ou supprimer une ressource. Jusqu'à présent, on parlait surtout de l'interaction entre agents utilisateurs, principalement les navigateurs avec les ressources.

Aujourd'hui, on parle de plus en plus de l'interaction entre agents ressources ; c'est à dire la relation entre les ressources: une ressource devient l'agent d'une autre ressource, mais reste elle-même une ressource accessible par d'autres agents. C'est exactement l'architecture décrite par l'exemple d'implémentation applicative des Mashups.

Les services web traitent donc d'agents ressources là où le mode opératoire classique du Web parle d'agents utilisateurs. Mais les deux concepts reposent sur la même architecture : REST

Il n'y a donc pas de différence fondamentale entre l'interaction d'un navigateur avec une ressource et celle d'un Service Web avec une ressource. La principale différence se situe au niveau du format de la représentation des données: HTML pour les navigateurs ou agents utilisateurs, XML ou JSON pour les Services Web ou agents ressources...

On peut donc définir un Service Web comme l'implémentation logicielle d'une ressource, identifiée par une URL, et accessible en utilisant les protocoles internet. Les agents s'occupent du contenu, de la représentation de leur état, pas du type de contenu. Il faut donc voir les Services Web comme le moyen de manipuler l'information, et non comme un simple fournisseur de services.

Dénominations

• Services Web RESTful
• Agents Ressources
• Robots Logiciels

Les Services Web WS

Introduction

Les Services Web WS-* désignent l'implémentation logicielle des spécifications WS-* et reposent tous sur un ensemble de protocoles et de standards de base utilisés pour l'échange de données entre applications dans des environnements hétérogènes :

• le SOAP (Simple Object Access Protocol) pour l'échange de messages,
• le WSDL (Web Service Description Language) pour la description : des services web, de leurs opérations, des messages utilisés, des types de données utilisées, des protocoles utilisés et de leur localisation au sens internet (URI / URL),
• les annuaires UDDI qui peuvent référencer des services web.

Ces Services Web WS-* sont par ailleurs définis selon le type d'architecture SOA.

Les logiciels écrits dans divers langages de programmation et sur diverses plates-formes peuvent employer des Services Web WS-* pour échanger des données à travers des réseaux informatiques comme Internet. L'OASIS et le World Wide Web Consortium (W3C) sont les comités de coordination responsables de l'architecture et de la standardisation des services Web. Pour améliorer l'interopérabilité entre les réalisations de service Web, l'organisation WS-I a développé une série de profils pour faire évoluer les futures normes impliquées.

Les standards employés

• Liste des spécifications des Services Web WS-*

Avantages

• Les services Web fournissent l'interopérabilité entre divers logiciels fonctionnant sur diverses plates-formes.
• Les services Web utilisent des standards et protocoles ouverts.
• Les protocoles et les formats de données sont au format texte dans la mesure du possible, facilitant ainsi la compréhension du fonctionnement global des échanges.
• Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux pare-feux sans nécessiter des changements sur les règles de filtrage.
• Les outils de développement, s'appuyant sur ces standards, permettent la création automatique de programmes utilisant les services Web existants.

Inconvénients

• Les normes de services Web dans certains domaines sont actuellement récentes.
• Les services Web souffrent de performances faibles comparée à d'autres approches de l'informatique répartie telles que le RMI, CORBA, ou DCOM.
• Par l'utilisation du protocole HTTP, les services Web peuvent contourner les mesures de sécurité mises en place au travers des pare-feux.

Scénarios

Les services Web implémentent de la logique métier rendue consommable (on consomme un service web ⇒ utiliser) par l'utilisation de standards (majoritairement TCP/IP, URI/URN/URL, MIME, HTTP/SMTP/..., SOAP, SSL/TLS, ... pour le transport, puis XML pour le contenu), ce qui permet à n'importe quelle technologie utilisant ces standards de pouvoir l'exploiter, facilitant ainsi l'interopérabilité des applications.

La création de services Web se justifie par l'architecture orientée service, c’est-à-dire la volonté de rendre accessible un service qui implémente une logique métier cachée à des utilisateurs.

Dans le cadre de contrats d'échange de données en Business to Business (entreprise ↔ entreprise), comme en Business to Consumer (entreprise ↔ client/utilisateur), un autre intérêt pour lequel des services Web sont employés est le fait qu'ils se fondent sur le protocole HTTP (qui utilise le port 80 par défaut). Pour comprendre ceci, gardez à l'esprit que beaucoup d'entreprises se sont protégées en employant des pare-feux qui filtrent et bloquent beaucoup de trafic d'Internet pour des raisons de sécurité. Dans ce milieu, beaucoup de (presque tous les) ports sont fermés au trafic entrant et sortant et les administrateurs de ces pare-feux ne sont pas désireux de les ouvrir. Le port 80, cependant, est toujours ouvert parce qu'il est employé par le protocole HTTP utilisé par les navigateurs Web. Avec cet avantage, les services web représentent une sorte de tunneling.

Plates-formes

Des services Web peuvent être déployés en employant un logiciel de serveur d'application :

• JAX-WS 2.x qui constitue l'implémentation de référence de Java EE est Open Source et intégré dans GlassFish et utilisable dans d'autres environnements. Son extension WSIT (aussi appelée "Project Tango") propose une implémentation de WS-ReliableMessaging, WS-SecureConversation, WS-Trust, ...
• Axis et le serveur de Jakarta Tomcat (deux projets open source d'Apache Software Foundation)
• XFire de CodeHaus offre un framework Java avec une approche différente de Axis
• CXF^[2] Fusion entre XFire (CodeHaus) et Celtix (Objectweb)
• ColdFusion MX de Macromedia
• Serveurs HTTP IIS de Microsoft (avec le framework .NET)
• WebLogic de BEA
• WebSphere Application Server d'IBM (basé sur le serveur d'Apache et la plate-forme de J2EE)
• Oracle Application Serveur d'Oracle Corporation
• ZenWorks de Novell
• NuSOAP : bibliothèque pour les développeurs de services Web en PHP
• gSOAP : bibliothèque pour les développeurs de services Web en C++
• JBoss Application Server de la société JBoss. Composant du JEMS (JBoss Enterprise Middleware System) dont fait également partie le framework de persistance relationnelle Hibernate.
• Uniface de Compuware Implémentation des web services SOAP en utilisant Tomcat
• IBM Lotus Domino
• Nirva Application Platform de Nirva Systems qui propose sa plate-forme fusion d'un ESB et d'un serveur d'application manipulant différents langages

Notes et références

1. ↑ (en) Web Services Activity
2. ↑ CXF (en)

Voir aussi

Articles connexes

• REST
• Service Oriented Architecture (SOA)
• XML
• Simple Object Access Protocol (SOAP)
• Web Services Description Language (WSDL)
• AJAX, ou Asynchronous JavaScript And XML
• Smart client

Liens externes

• (en) Web Services Activity au W3C
• (en) Comité Web Services à Oasis
• Sur WS-I : (en) Establishing Best Practices for Web Services Standards, (fr) Web Service Interoperability (WS-I)

Ce document provient de « Service Web ».