Que sont les services Web? Architecture, types, exemple

Qu'est-ce qu'un service Web ?

Service Web est un support standardisé pour propager la communication entre les applications client et serveur sur le WWW (World Wide Web). Un service Web est un module logiciel conçu pour effectuer un certain ensemble de tâches.

• Les services Web dans le cloud computing peuvent être recherchés sur le réseau et peuvent également être invoqués en conséquence.
• Lorsqu'il est invoqué, le service Web serait en mesure de fournir la fonctionnalité au client qui invoque ce service Web.

Comment fonctionnent les services Web ?

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 par le biais d'appels de procédure distante (RPC). Les RPC sont des appels effectués à 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 Javamais les deux langages de programmation auraient la possibilité 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) Il s'agit d'un équivalent du HTML et d'un langage intermédiaire facile à comprendre, reconnu par de nombreux langages de programmation.

Ainsi, lorsque des applications communiquent entre elles, elles utilisent en réalité le langage XML. Cela fournit une plateforme 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 d'entreprise modernes utilisent diverses plateformes 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 encore en Angular JS, Node.js, etc.

Le plus souvent, ces applications hétérogènes nécessitent une forme de communication entre elles. Comme elles sont développées à l'aide de langages différents, il devient très difficile de garantir une communication précise entre elles.

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.

Types de services 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 sont indispensables. Ces composants doivent être présents quel que soit le langage de développement utilisé pour programmer le service web. Examinons-les plus en détail.

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

SOAP est un protocole de messagerie indépendant du transport. Il repose sur le transfert de données XML sous forme de messages SOAP. Chaque message contient un document XML. Seule la structure de ce document suit un modèle spécifique, son contenu restant inchangé. L'avantage principal des services Web et de SOAP réside dans le fait que toutes les données sont transmises via HTTP, 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, c'est-à-dire 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 (services Web DescriptLangue ionique)

Un service web ne peut être utilisé s'il est introuvable. Le client qui invoque le service web doit savoir où se trouve réellement ce service.

Deuxièmement, l'application cliente doit savoir ce que fait réellement le service Web afin de pouvoir l'appeler correctement. Ceci est réalisé grâce au WSDL, également appelé service Web. DescriptLe fichier WSDL est un fichier XML qui décrit à l'application cliente le fonctionnement du service web. Grâce à ce document WSDL, l'application cliente peut localiser le service web et savoir comment l'utiliser.

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` de 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. Dans l'exemple de service web ci-dessus, deux messages peuvent être échangés entre le service web et l'application cliente : « TutorialRequest » et « TutorialResponse ». `TutorialRequest` contient un élément `TutorialID` de type chaîne de caractères. De même, `TutorialResponse` contient un élément `TutorialName`, également de type chaîne de caractères.
2. – Ceci décrit en fait l'opération que peut effectuer le service web, appelé ici Tutorial. Cette opération prend deux messages : un message d'entrée et un message de sortie.
3. Cet élément contient le protocole utilisé. Dans notre cas, nous le définissons pour utiliser HTTP (http://schemas.xmlsoap.org/soap/http). Nous spécifions également d'autres détails concernant le corps de l'opération, comme l'espace de noms et si le message doit être encodé.

Nous aborderons en détail le concept de « WSDL » dans cet article. 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.

De même qu'un annuaire téléphonique contient le nom, l'adresse et le numéro de téléphone d'une personne, le registre UDDI contiendra les informations nécessaires au service web., afin qu'une application cliente sache où la trouver.

Avantages des services Web

Nous comprenons déjà la raison d'être des services web : fournir une plateforme permettant à différentes applications de communiquer entre elles. Mais examinons les avantages des services web et pourquoi il est important de les utiliser.

1. Exposer les fonctionnalités métier sur le réseau Un service web est une unité de code managé qui fournit des fonctionnalités aux applications clientes ou aux utilisateurs finaux. Ces fonctionnalités sont accessibles via le protocole HTTP, c'est-à-dire via Internet. De nos jours, la plupart des applications sont disponibles sur Internet, ce qui renforce l'utilité des services web. Ainsi, un service web peut être hébergé n'importe où sur Internet et fournir les fonctionnalités nécessaires en temps réel.
2. Interopérabilité entre les applications Les services web permettent à différentes applications de communiquer entre elles et de partager des données et des services. Tous les types d'applications peuvent interagir. Ainsi, au lieu d'écrire du code spécifique compréhensible uniquement par certaines applications, il est désormais possible d'écrire du code générique, compréhensible 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 (Transport de services, Messagerie XML, Service) sont toutes concernées. DescriptLes couches d'intégration et de découverte de services utilisent 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.

Services Web Architecture

Chaque framework nécessite une architecture pour garantir son bon fonctionnement. De même, dans les services web, Services Web Architecture se compose de trois rôles distincts, comme indiqué ci-dessous :

1. Provider – Le fournisseur crée le service web et le met à disposition des applications clientes qui souhaitent 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, Javaou toute autre application basée sur le langage qui recherche une fonctionnalité quelconque via un service web.
3. Broker Le courtier n'est autre que l'application qui permet d'accéder à l'UDDI. L'UDDI, comme expliqué précédemment, permet à l'application cliente de localiser le service web.

Le schéma ci-dessous illustre comment le fournisseur de services, le demandeur de services et le registre de services interagissent entre eux.

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) concernant le service Web, le demandeur est en mesure de se lier, ou d'invoquer, le service Web.

Caractéristiques des services Web

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 aux niveaux de représentation et de transport. L'utilisation d'XML élimine toute dépendance vis-à-vis du réseau, du système d'exploitation ou de la plateforme, car XML est un 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.

FAQ