Les Services web

 

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) 

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 informatique 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.

Définition

Un service web (ou service de la toile) est un protocole d'interface informatique de la famille des technologies web 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, de manière synchrone ou asynchrone. Le protocole de communication est défini dans le cadre de la norme SOAP dans la signature du service exposé (WSDL). Actuellement, le protocole de transport est essentiellement TCP (via HTTP). Le concept a été précisé et mis en œuvre dans le cadre de Web Services Activity, au W3C, particulièrement avec le protocole SOAP. Associé avec les échanges de données informatisés  (W3C) 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..

Dans sa présentation la plus générale, un service web se concrétise par un agent, réalisé selon une technologie informatique précise par un fournisseur du service. Un demandeur, à l'aide d'un agent de requête, utilise ce service. Fournisseur et demandeur partagent une même sémantique du service web, tandis qu'agent et agent de requête partagent une même description du service pour coordonner les messages qu'ils échangent³.

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 identifiables par un URI 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 Meddleware en objectif d'interopérabilité.

Les standards WS-* sont souvent décriés comme risquant de provoquer une course à la performance technologique. Toutefois leur robustesse dans le milieu des services entre professionnels est reconnue, et ils restent largement utilisés. Aussi on préfère les faire

 évoluer.

Services web de type representational state transfer (REST)

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, lire, 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 : pour les navigateurs HTML 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 un URI, et accessible en utilisant HTTP. 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

Standards employés

Liste des spécifications des services web WS

Il existe une variété de spécifications associées aux  services web WS. Ces spécifications sont à des niveaux de maturité parfois différents, et sont maintenus par diverses organisations de standardisation. Ces spécifications peuvent se compléter, se chevaucher, voire se concurrencer l'une l'autre.

Les spécifications de ces services web sont aujourd'hui désignées sous le terme WS, certainement en raison du sigle WS qui précède la majorité d'entre elles.

Cette page liste la plupart des spécifications considérées comme faisant partie des WS. Les services web qui implémentent ces spécifications sont appelés services web WS-*.

Spécifications générales

·         Web Service Activity, sur le site du W3C

Accès aux répertoires

·      UDDI signifie Universal Description, Discovery, and Integration (UDDI 1.0, 2.0 et 3.0): Normalise l'architecture d'un annuaire distribué permettant de publier les interfaces des services Web (endpoint des contrats WSDL). Il est possible d'y effectuer des recherches en fonction de la description commerciale et technique d'un service. Un annuaire UDDI est lui-même exposé comme un service Web. Il peut être privé (utilisé uniquement dans l'entreprise) ou public (ouvert à l'ensemble de l'internet).

·       ebXML

·         WSFL

·         WS-Policy (W3C Recommandation 04 September 2007)

·         WS-PolicyAssertions

·         WS-PolicyAttachment

·         WS-Policy Framework

·         WS-SecurityPolicy

·         WS-Discover.

·         WS-Inspection

• Spécifications XML de base

·         XML (Extensible Markup Language)

·        Espace de nom XML

·           XML Schema

·         Xpath

·         XML Information Set

·         XInclude

·         XML Pointer

• Description des services (métadonnées)

·        Web Services Description Language (WSDL) du W3C

·         Web Services Semantics (WSDL-S)

·         XINS provides a POX-style Web service specification format

·         WS-Metadatachange

·         WS-Resource Framework (WSRF)

• Messages et fonctions d'appel

·       Simple Object Access Protocol (SOAP)

·         SOAP with Attachments

·         SOAP-over-UDP

·        WS-Eventing (W3C Member Submission 15 March 2006) : Standardise la façon dont les services Web reçoivent et échangent entre eux des messages liés à des événements. WS-Eventing s'appuie sur une série de protocoles, de formats de messages, de notifications d'événements et d'interfaces.

·         WS-Eddressing (W3C Member Submission 10 August 2004): Standard permettant de véhiculer des messages SOAP de façon bidirectionnelle, en mode synchrone ou asynchrone, indépendamment de la couche de transport.

·         WS-Routing (spécification superseded by WS-Addressing)

·         WS-Referral (spécification superseded by WS-Addressing)

·         MTOM (MTOM): Spécifie comment gérer les pièces attachées à un message Soap 1.2. Le message et la pièce attachée sont encapsulés dans une enveloppe Mime Multipart. MTOM fournit un mécanisme de pointeur logique (l'élément xbinc:Include) qui permet de créer des références internes aux pièces attachées directement dans le message Soap, facilitant ainsi le traitement des messages Soap et favorisant leur atomicité.

·       WS-Enumeration(W3C Member Submission 15 March 2006)

·        WS-Transfer (W3C Member Submission 27 September 2006)

• Interopérabilité des services web (WS-I)

Des spécifications fournissent des informations supplémentaires pour améliorer l'interopérabilité entre les implémentations des fournisseurs.

·         WS-I Basic Profile

·         WS-I Basic Security Profile

·         Simple Soap Binding Profile

• Spécifications des processus métiers

·         WS-BPEL

·         WS-CDL WS Langage de définition de chorégraphie, langage basé sur XML qui décrit les collaborations poste-à-poste (peer-to-peer) de participants à de services web.

• Spécifications de sécurité

·        Signature XML

·         Cryptage XML

·        XML Key Management Specification (XKMS)

·        WS-Security

·         WS-SecureConversation

·         WS-SecurityPolicy

·        WS-Trust

·        WS-Federation

·        WS-Federation Active Requestor Profile

·         WS-Federation Passive Requestor Profile

·         Web Services Security Kerberos Binding

·         Web Single Sign-On Interoperability Profile

·         Web Single Sign-On Metadata Exchange Protocol

·         Security Assertion Markup Language (SAML) (utilisé pour l'échange d'authentification et l'information d'autorisation)

·         XACML (peut être utilisé pour décrire les policies d'autorisation)

Spécifications sur la fiabilité des messages

·         WS-ReliableMessaging

·         WS-Reliability

• Specifications de transaction

·         WS-Coordination

·         WS-Transaction

·         WS-AtomicTransaction

·         WS-BusinessActivity

·         WS-TXM

• Spécifications d'événements et de notifications

·         WS-Notification est une approche web services destinée à la notification, utilisant un pattern basé sur un topic publish/subscribe. Cette spécification inclut trois familles de spécifications :

·         WS-BaseNotification

·         WS-BrokeredNotification

·         WS-Topics

·         WS-Eventing

• Spécifications de gestion et d'administration

·         WS-Management

·         WS-Management Catalog

·         WS-ResourceTransfer

• Spécifications en projet

·         WS-CAF Web Services Composite Application Frameworks

·         WS-CDL Web Services Choreography Description Language. It is W3C specification that describes peer-to-peer collaborations of parties by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal.

·         WSDM Web Services Distributed Management

·         WS-Provisioning Décrit les API et Schémas nécessaires pour faciliter l'interopérabilité entre les systèmes de provisioning d'une façon cohérente

Sécurité et le WSDL

Basés sur le protocole HTTP, les services web peuvent fonctionner au travers de nombreux pare-feu sans nécessiter des changements sur les règles de filtrage.

Cette facilité à implémenter les services web WS-* a un revers : il est plus complexe d'implémenter des règles de sécurité spécifiques aux c WS que sur un  Web Services  classique.

Avantages

En plus de permettre aux applications écrites dans différents langages de programmation de communiquer entre elles, les services web offrent d’autres avantages. Tout d’abord, ils permettent d’accéder à des fonctionnalités via internet. En effet, les fonctionnalités fournies par le service web à une application client sont invoquées via le protocole HTTP. Elles peuvent donc être invoquées via internet. A l’heure où toutes les applications sont connectées à internet, les services web sont donc devenus bien plus utiles qu’autrefois.

Par ailleurs, les services web permettent une interopérabilité entre les applications. Ils permettent en effet à diverses applications de communiquer entre elles, et de partager des données et des services. Ainsi, plutôt que d’avoir à écrire un code spécifique pouvant être compris uniquement par des applications spécifiques, il est possible d’écrire un code générique pouvant être compris par toutes les applications.

Un autre avantage des services web est qu’ils utilisent un protocole industriel standardisé pour la communication. Les quatre couches (Service Transport, XML Messaging, Service Description et Service Discovery) utilisent des protocoles bien définis.

Enfin, les services web permettent de réduire les coûts des communications. Sachant qu’ils utilisent le SOAP via le protocole HTTP, il est possible d’utiliser une connexion internet low-cost pour implémenter les services web.

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.

Scénarios

Les services web implémentent de la logique métier renduebe consommable par l'utilisation de standards (majoritairement TCP/IP, URI, MIME, HTTP, SMTP, SOAP, TLS, etc. 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 interentreprises, comme dans le commerce entreprises aux particulier, 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, il faut garder à l'esprit que beaucoup d'entreprises se sont protégées en employant des pare-feu 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 protocoleHTTP utilisé par les navigateurs web. Avec cet avantage, les services web représentent une sorte de tunnling.

Plates-formes

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

·         JAX-WS 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 Fusion entre XFire (CodeHaus) et Celtix (Objectweb).

·         ColdFusion MX de Macromedia.

·         Serveurs HTTP IIS de Microsoft (avec le framework .Net).

·        WebLogic d'Oracle Corporation.

·         WebSphere Application serveur d'IBM (basé sur le serveur d'Apache et la plate-forme de J2EE).

·         Oracle Application Serveur d'Oracle Corpration.

·         ZenWorks de Norvell.

·         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 Serveur de la société  JBoss. Composant du JEMS (JBoss Enterprise Middleware System) dont fait également partie le framework de persistance relationnelle Hibernate.

·         GlassFish: serveur d'application.

·       Uniface de Compuware Implémentation des services web 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.

 

Les applications web modernes sont développées dans différents langages de programmation : Java, Net, Angular JS, Node.js… de fait, il peut être difficile d’assurer la communication entre ces applications. C’est la raison pour laquelle on utilise des services web.

 comment ça fonctionne ?

 

            

Une fois invoqué, un service web est en mesure de fournir ses fonctionnalités au client qui l’invoque. Le client invoque une série d’appels de service web par le biais de requêtes envoyées au serveur qui héberge le service. Ces requêtes sont effectuées par le biais d’appels de procédure distante (Remote Procedure Calls).

Par exemple, Amazon propose un service web fournissant les prix pour des produits vendus en ligne via Amazon.com. Le front end ou la couche de présentation peuvent être en .Net ou en Java, mais ces deux langages de programmation auront la capacité de communiquer avec le service web.

Le principal composant d’un service web sont les données transférées entre le client et le serveur. Ces données sont en XML (Extensible Markup Language). Le XML est la contrepartie du HTML. Pour faire simple, on peut le décrire comme un langage intermédiaire compris par la plupart des langages de programmation. Ainsi, les applications communiquent entre elles en XML.

Pour envoyer les données XML entre les applications, les services web utilisent le SOAP (Simple Object Access Protocol). Les données envoyées du service web vers l’application sont appelées des messages SOAP. Il s’agit tout simplement d’un document au format XML.