Que sont les services Web? Architecture, types, exemple

Comment fonctionnent les WebServices ?

Le diagramme ci-dessus montre une vue très simpliste du fonctionnement réel d’un service Web. Le client invoquerait une série d'appels de service Web via des requêtes adressées à un serveur qui hébergerait le service Web lui-même.

Ces requêtes sont effectuées via ce que l'on appelle des appels de procédure à distance. Les appels de procédure à distance (RPC) sont des appels effectués vers des méthodes hébergées par le service Web concerné.

Par exemple, Amazon fournit un service Web qui fournit les prix des produits vendus en ligne via amazon.com. La couche frontale ou de présentation peut être en .Net ou Java mais l'un ou l'autre langage de programmation aurait la capacité de communiquer avec le service Web.

Le composant principal de la conception d'un service Web sont les données qui sont transférées entre le client et le serveur, à savoir XML. XML (langage de balisage extensible) est un homologue du HTML et un langage intermédiaire facile à comprendre qui est compris par de nombreux langages de programmation.

Ainsi, lorsque les applications communiquent entre elles, elles parlent en réalité en XML. Cela fournit une plate-forme commune permettant aux applications développées dans différents langages de programmation de communiquer entre elles.

Les services Web utilisent quelque chose appelé SOAP (Simple Object Access Protocol) pour envoyer les données XML entre les applications. Les données sont envoyées via HTTP normal. Les données envoyées du service Web à l'application sont appelées un message SOAP. Le message SOAP n'est rien d'autre qu'un document XML. Le document étant écrit en XML, l'application cliente appelant le service Web peut être écrite dans n'importe quel langage de programmation.

Pourquoi avez-vous besoin d'un service Web ?

Les applications professionnelles modernes utilisent diverses plates-formes de programmation pour développer des applications Web. Certaines applications peuvent être développées en Java, d'autres en .Net, tandis que d'autres en Angular JS, Node.js, etc.

Le plus souvent, ces applications hétérogènes nécessitent une sorte de communication entre elles. Puisqu’ils sont construits à l’aide de différents langages de développement, il devient très difficile d’assurer une communication précise entre les applications.

C'est ici qu'interviennent les services Web. Les services Web fournissent une plate-forme commune qui permet à plusieurs applications construites sur différents langages de programmation avoir la capacité de communiquer entre eux.

Type de service Web

Il existe principalement deux types de services Web.

1. Services Web SOAP.
2. Services Web RESTful.

Pour qu’un service Web soit pleinement fonctionnel, certains composants doivent être en place. Ces composants doivent être présents quel que soit le langage de développement utilisé pour programmer le service Web.

Examinons ces composants plus en détail.

SOAP (protocole d'accès aux objets simples)

SOAP est connu comme un protocole de messagerie indépendant du transport. SOAP est basé sur le transfert de données XML sous forme de messages SOAP. Chaque message contient quelque chose que l'on appelle un document XML. Seule la structure du document XML suit un modèle spécifique, mais pas le contenu. La meilleure partie des services Web et de SOAP est que tout est envoyé via HTTP, qui est le protocole Web standard.

Voici en quoi consiste un message SOAP

• Chaque document SOAP doit avoir un élément racine appelé élément. L'élément racine est le premier élément d'un document XML.
• L’« enveloppe » est quant à elle divisée en 2 parties. Le premier est l’en-tête et le suivant est le corps.
• L'en-tête contient les données de routage qui sont essentiellement les informations qui indiquent au document XML à quel client il doit être envoyé.
• Le corps contiendra le message réel.

Le schéma ci-dessous montre un exemple simple de communication via SOAP.

Nous discuterons de SOAP en détail dans ce tutoriel.

WSDL (langage de description des services Web)

Un service Web ne peut pas être utilisé s'il est introuvable. Le client qui invoque le service Web doit savoir où réside réellement le service Web.

Deuxièmement, l'application cliente doit savoir ce que fait réellement le service Web, afin de pouvoir appeler le bon service Web. Cela se fait à l'aide du WSDL, connu sous le nom de langage de description de services Web. Le fichier WSDL est à nouveau un fichier XML qui indique essentiellement à l'application client ce que fait le service Web. En utilisant le document WSDL, l'application client serait en mesure de comprendre où se trouve le service Web et comment il peut être utilisé.

Exemple de service Web

Un exemple de service Web de fichier WSDL est donné ci-dessous.

<definitions>	
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>
     
   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

Les aspects importants à noter concernant les exemples de déclarations WSDL de services Web ci-dessus sont les suivants :

1. – Le paramètre message dans la définition WSDL permet de définir les différents éléments de données pour chaque opération effectuée par le service web. Ainsi, dans les exemples de services Web ci-dessus, nous avons 2 messages qui peuvent être échangés entre le service Web et l'application client, l'un est le « TutorialRequest » et l'autre est l'opération « TutorialResponse ». Le TutorialRequest contient un élément appelé « TutorialID » qui est du type chaîne. De même, l'opération TutorialResponse contient un élément appelé « TutorialName » qui est également une chaîne de type.
2. – Ceci décrit en fait l'opération qui peut être effectuée par le service web, qui dans notre cas s'appelle Tutorial. Cette opération peut prendre 2 messages ; l'un est un message d'entrée et l'autre est le message de sortie.
3. – Cet élément contient le protocole utilisé. Donc dans notre cas, nous le définissons pour utiliser http (http://schemas.xmlsoap.org/soap/http). Nous spécifions également d'autres détails pour le corps de l'opération, comme l'espace de noms et si le message doit être codé.

Nous discuterons du « WDSL » en détail dans ce tutoriel.

Universel Description, découverte et intégration (UDDI)

UDDI est une norme permettant de décrire, de publier et de découvrir les services Web fournis par un fournisseur de services particulier. Il fournit une spécification qui aide à héberger les informations sur les services Web.

Nous avons maintenant abordé dans la rubrique précédente le WSDL et la façon dont il contient des informations sur ce que fait réellement le service Web. Mais comment une application client peut-elle localiser un fichier WSDL pour comprendre les différentes opérations proposées par un service web ? UDDI est donc la réponse à cette question et fournit un référentiel sur lequel les fichiers WSDL peuvent être hébergés. Ainsi, l'application client aura un accès complet à l'UDDI, qui fait office de base de données contenant tous les fichiers WSDL.

Tout comme un annuaire téléphonique contient le nom, l'adresse et le numéro de téléphone d'une personne particulière, de la même manière le registre UDDI disposera des informations pertinentes pour le service Web.. Pour qu'une application client sache où elle peut être trouvée.

Avantages des services Web

Nous comprenons déjà pourquoi les services Web sont apparus en premier lieu, à savoir fournir une plate-forme permettant à différentes applications de communiquer entre elles.

Mais regardons la liste des avantages des services Web pour comprendre pourquoi il est important d'utiliser les services Web.

1. Exposer les fonctionnalités métier sur le réseau – Un service Web est une unité de code géré qui fournit une sorte de fonctionnalité aux applications clientes ou aux utilisateurs finaux. Cette fonctionnalité peut être invoquée via le protocole HTTP, ce qui signifie qu'elle peut également être invoquée via Internet. De nos jours, toutes les applications se trouvent sur Internet, ce qui rend la finalité des services Web plus utile. Cela signifie que le service Web peut se trouver n'importe où sur Internet et fournir les fonctionnalités nécessaires selon les besoins.
2. Interopérabilité entre les applications – Les services Web permettent à diverses applications de communiquer entre elles et de partager des données et des services entre elles. Tous les types d’applications peuvent communiquer entre elles. Ainsi, au lieu d'écrire du code spécifique qui ne peut être compris que par des applications spécifiques, vous pouvez désormais écrire du code générique qui peut être compris par toutes les applications.
3. Un protocole standardisé que tout le monde comprend – Les services Web utilisent un protocole industriel standardisé pour la communication. Les quatre couches (Service Transport, XML Messaging, Service Description et Service Discovery) utilise des protocoles bien définis dans la pile de protocoles des services Web.
4. Réduction du coût de la communication – Les services Web utilisent le protocole SOAP sur HTTP, vous pouvez donc utiliser votre Internet à faible coût existant pour implémenter des services Web.

1. Provider – Le fournisseur crée le service Web et le met à disposition de l'application cliente qui souhaite l'utiliser.
2. Demandeur – Un demandeur n’est rien d’autre que l’application client qui doit contacter un service Web. L'application client peut être un .Net, Java, ou toute autre application basée sur un langage qui recherche une sorte de fonctionnalité via un service Web.
3. Broker – Le courtier n'est rien d'autre que l'application qui permet d'accéder à l'UDDI. L'UDDI, comme indiqué dans la rubrique précédente, permet à l'application client de localiser le service Web.

Le diagramme ci-dessous montre comment le fournisseur de services, le demandeur de service et le registre de services interagissent les uns avec les autres.

1. Publier – Un fournisseur informe le courtier (registre de services) de l'existence du service Web en utilisant l'interface de publication du courtier pour rendre le service accessible aux clients
2. Trouvez – Le demandeur consulte le courtier pour localiser un service web publié
3. Lier – Grâce aux informations obtenues auprès du courtier (registre de services) sur le service Web, le demandeur est en mesure de lier ou d'invoquer le service Web.

Webservice Caractéristiques

Les services Web présentent les caractéristiques comportementales particulières suivantes :

1. Ils sont basés sur XML – Les services Web utilisent XML pour représenter les données au niveau des couches de représentation et de transport de données. L’utilisation de XML élimine toute dépendance en matière de réseau, de système d’exploitation ou de plate-forme puisque XML est le langage commun compris par tous.
2. Couplage lâche – Un couplage faible signifie que le client et le service Web ne sont pas liés l'un à l'autre, ce qui signifie que même si le service Web change au fil du temps, il ne devrait pas changer la façon dont le client appelle le service Web. L'adoption d'une architecture faiblement couplée tend à rendre les systèmes logiciels plus gérables et permet une intégration plus simple entre différents systèmes.
3. SyncFonctionnalité synchrone ou asynchrone - SyncL'hronicité fait référence à la liaison du client à l'exécution du service. Dans les opérations synchrones, le client attendra en fait que le service Web termine une opération. Un exemple de cela est probablement un scénario dans lequel une opération de lecture et d'écriture de base de données est en cours d'exécution. Si les données sont lues à partir d'une base de données puis écrites dans une autre, les opérations doivent être effectuées de manière séquentielle. Les opérations asynchrones permettent à un client d'appeler un service puis d'exécuter d'autres fonctions en parallèle. Il s'agit de l'une des techniques les plus courantes et probablement les plus appréciées pour garantir que les autres services ne sont pas arrêtés lorsqu'une opération particulière est en cours d'exécution.
4. Capacité à prendre en charge les appels de procédure à distance (RPC) – Les services Web permettent aux clients d'invoquer des procédures, des fonctions et des méthodes sur des objets distants à l'aide d'un protocole basé sur XML. Les procédures distantes exposent les paramètres d'entrée et de sortie qu'un service Web doit prendre en charge.
5. Prend en charge l'échange de documents – L'un des principaux avantages de XML réside dans sa manière générique de représenter non seulement des données mais également des documents complexes. Ces documents peuvent être aussi simples que représenter une adresse actuelle, ou ils peuvent être aussi complexes que représenter un livre entier.