Services Web - Détails

Sommaire

1°) Les services web ou les web services (en anglais)
2°) Les couches
3°) Les standards
4°) Invocation du service
5°) Découverte
6°) Les services web avec NatStar, NS-DK et NatJet

1°) Les services web ou les web services (en anglais)

Les services web représentent un mécanisme de communication, entre applications distantes à travers le réseau Internet ou intranet, indépendant de tout langage de programmation et de toute plate-forme d'exécution :

• utilisant le protocole HTTP comme moyen de transport
• employant une syntaxe basée sur la notation XML pour décrire les appels de fonctions distantes et les données échangées
• organisant les mécanismes d'appel et de réponse

Grâce aux services web, les applications peuvent être vues comme un ensemble de services métiers, structurés, flexibles, modulaires et composables, dialoguant selon un standard international.
Le protocole HTTP est simple, très répandu, et facilement paramétrable au sein des pares feux.
Le premier bénéfice de ce découpage est la facilité de maintenance de l'application, ainsi que l'interopérabilité permettant de modifier facilement un composant (un service) pour le remplacer par un autre. Qui plus est, les services web permettent de réduire la complexité d'une application car le développeur peut se focaliser sur un service, indépendamment du reste de l'application.
Les services web facilitent les échanges entre les applications de l'entreprise et permettent une ouverture vers les autres entreprises. Les premiers fournisseurs de services web sont ainsi les fournisseurs de services en ligne (météo, bourse, planification d'itinéraire, pages jaunes, Google, etc.), mettant à disposition des développeurs des API (Application Programmable Interface) payantes ou non, permettant d'intégrer leur service au sein d'applications tierces.
Les fusions, acquisitions, et regroupements génèrent des entreprises importantes, dotées de systèmes informatiques différents. Au sein de deux filiales hétérogènes, les services web permettent une construction d’échanges grandement facilitée.
La mise au point de communications entre progiciel métier et développement spécifique bénéficie d’un standard souple, facilement adaptable, non spécifique au progiciel, et compréhensible au niveau du format des données échangées. Tout cela pouvant être réalisé alors que le fournisseur du service et la (ou les) consommation(s) du service peuvent être développée(s) par des équipes différentes, sur des projets différents à une période différente.
Les services Web orientent l’architecture applicative vers un couplage faible. Cela peut constituer un premier pas vers le SOA.

Haut de page

 

2°) Les couches

Le fonctionnement des services web repose sur un modèle en couches, dont les trois couches fondamentales sont les suivantes :

• Invocation, visant à décrire la structure des messages échangés par les applications
• Découverte, pour permettre de rechercher et de localiser un service web particulier dans un annuaire de services décrivant le nom de la société, l'objectif de chaque service, etc.
• Description, dont l'objectif est la description des interfaces (paramètres des fonctions, types de données) des services web.

Haut de page

 

3°) Les standards

Les standards de base utilisés par les Web-Services (SOAP, WSDL) sont normalisés par le W3C (http://www.w3.org/2002/ws/), tandis que l'OASIS est chargée de la standardisation des couches supérieures, plus proches du niveau applicatif (sécurité, etc.).

Haut de page

 

4°) Invocation du service

L’état de l’art montre qu’il existe deux grandes pratiques de services web, tous deux basés dans les faits sur HTTP :

• SOAP/WSDL (Simple Object Access Protocol/Web Services Description Language), fonctionnant selon le modèle objet.
  Quel que soit le standard utilisé, le principe de programmation est le même : l'appel de méthode distante est réalisé grâce à une bibliothèque cliente qui transmet la demande au fournisseur de service en la formatant en XML de manière transparente; au niveau du serveur une bibliothèque serveur décode la requête, le serveur fait ses traitements, puis répond grâce à cette même bibliothèque; la bibliothèque cliente décode enfin la réponse afin qu'elle puisse être utilisée par l'application client.
  Bien que SOAP soit défini sur un principe multi protocoles, seul le protocole HTTP est réellement utilisé et mis en application dans la pratique.
  Le contrat du service est matérialisé au sein d’un document XML appelé WSDL. Ce contrat décrit l’offre de service ainsi que la manière de l’utiliser. Ce contrat est lui-même explicite et vérifiable du fait de la lisibilité du document XML. De très nombreux outillages permettent d’interpréter ce contrat WSDL pour soit générer une interface adaptée au langage utilisé (WSDL2Java, WSDL2C, WSDL2Ncl, …) ou soit fabriquer le contrat WSDL à partir du service existant (Java2WSDL, C2WSDL, Ncl2WSDL, … )
• REST (REpresentational State Transfer)., le plus ancien, fonctionnant sur un principe procédural d’échange de document XML, HTML, JPEG, … Cette architecture part du principe selon lequel le Web est composé de ressources accessibles à partir d'une URL. Cette représentation place l'application cliente dans un état (state) donné. Il faut bien noter que REST n'est pas en soi un standard : il n'existe pas de spécification du W3C pour la décrire. Il s'agit plutôt d'un style d'architecture, d'un "mode de compréhension du Web" sur lequel le développeur construit ses services (Web). REST fait en revanche usage des standards Web : protocole HTTP, URLs, formats de fichiers pour la représentation des ressources (XML, HTML, JPEG...), types MIME pour la description de ces représentations...
  Tous les sites WEB sont des fournisseurs de services WEB REST potentiels. Pour la réponse, bien qu’il ne soit pas obligatoire, un document XML facilite grandement la réponse à analyser. Le consommateur du service doit alors parser le document XML de réponse pour extraire le ou les résultats souhaités correspondant à sa demande.
  Les services WEB REST sont fortement utilisés par les langages de scripts (Ex : JavaScript).

L’utilisation d’un service WEB SOAP outillé (doté du module WSDL2xxx adapté) s’avère plus simple et plus rapide à coder que l’utilisation d’un service WEB REST.

Haut de page

 

5°) Découverte

Le protocole standard le plus utilisé pour la découverte de services est UDDI.
Le standard UDDI (Universal Description Discovery and Integration) défini par l'OASIS (Objects Active Semantics, Internet and Security) vise à décrire une manière standard de publier et d'interroger les services web proposés par un réseau, généralement au sein d'un service d'annuaire recensant les services web de l'organisation.

Haut de page

 

6°) Les services web avec NatStar, NS-DK et NatJet

• Avec NatStar, toute fonction ou instruction est transformable en un service web donnant de fait une ouverture vers l’extérieur de votre application. Un plugin NatStar automatise complètement la fabrication du WSDL (Ncl2WSDL)
• Il est également possible d’appeler tout service web externe via NatStar ou NS-DK dès lors que vous avez un fichier de description de ce service au format WSDL ou une URL vers le site le contenant. Un assistant vous permet de générer une librairie ou une bibliothèque de fonctions NCL spécialisées pour la gestion du service web spécifié (WSDL2Ncl)
• Avec NatJet, tous les éléments présents dans Java/J2EE permettent de répondre complètement aux besoins (WSDL2Java, Java2WSDL, JAXP, JAX-WS, …)
• Pour l’approche REST, NatStar et NS-DK proposent les services NSHTTP et NWXML. NSHTTP propose une API permettant d’émettre et de réceptionner des requêtes HTTP. Dans le cas ou la réponse du service est un document XML, NWXML propose une API d’un parseur DOM. Nat System propose désormais un parseur SAX, qui permet de gérer les très gros documents XML.

Haut de page