Services Web - Guide rapide

Différents livres et différentes organisations fournissent des définitions différentes aux services Web. Certains d'entre eux sont répertoriés ici.

  • Un service Web est tout logiciel qui se rend disponible sur Internet et utilise un système de messagerie XML normalisé. XML est utilisé pour coder toutes les communications vers un service Web. Par exemple, un client appelle un service Web en envoyant un message XML, puis attend une réponse XML correspondante. Comme toutes les communications sont en XML, les services Web ne sont liés à aucun système d'exploitation ou langage de programmation - Java peut communiquer avec Perl; Les applications Windows peuvent communiquer avec les applications Unix.

  • Les services Web sont des applications autonomes, modulaires, distribuées et dynamiques qui peuvent être décrites, publiées, localisées ou appelées sur le réseau pour créer des produits, des processus et des chaînes d'approvisionnement. Ces applications peuvent être locales, distribuées ou basées sur le Web. Les services Web reposent sur des normes ouvertes telles que TCP / IP, HTTP, Java, HTML et XML.

  • Les services Web sont des systèmes d'échange d'informations basés sur XML qui utilisent Internet pour une interaction directe d'application à application. Ces systèmes peuvent inclure des programmes, des objets, des messages ou des documents.

  • Un service Web est un ensemble de protocoles et de normes ouverts utilisés pour l'échange de données entre des applications ou des systèmes. Les applications logicielles écrites dans divers langages de programmation et exécutées sur diverses plates-formes peuvent utiliser des services Web pour échanger des données sur des réseaux informatiques comme Internet d'une manière similaire à la communication inter-processus sur un seul ordinateur. Cette interopérabilité (par exemple, entre Java et Python, ou entre les applications Windows et Linux) est due à l'utilisation de standards ouverts.

Pour résumer, un service Web complet est donc tout service qui -

  • Est disponible sur Internet ou sur des réseaux privés (intranet)

  • Utilise un système de messagerie XML standardisé

  • N'est lié à aucun système d'exploitation ou langage de programmation

  • Est auto-descriptif via une grammaire XML commune

  • Est découvrable via un simple mécanisme de recherche

Composants des services Web

La plate-forme de services Web de base est XML + HTTP. Tous les services Web standard fonctionnent avec les composants suivants -

  • SOAP (Simple Object Access Protocol)

  • UDDI (description, découverte et intégration universelles)

  • WSDL (langage de description de services Web)

Tous ces composants ont été abordés dans le chapitre Architecture des services Web .

Comment fonctionne un service Web?

Un service Web permet la communication entre diverses applications à l'aide de normes ouvertes telles que HTML, XML, WSDL et SOAP. Un service Web prend l'aide de -

  • XML pour baliser les données

  • SOAP pour transférer un message

  • WSDL pour décrire la disponibilité du service.

Vous pouvez créer un service Web Java sur Solaris accessible à partir de votre programme Visual Basic qui s'exécute sous Windows.

Vous pouvez également utiliser C # pour créer de nouveaux services Web sur Windows qui peuvent être appelés à partir de votre application Web basée sur JavaServer Pages (JSP) et s'exécutant sous Linux.

Exemple

Envisagez un système simple de gestion des comptes et de traitement des commandes. Le personnel comptable utilise une application client construite avec Visual Basic ou JSP pour créer de nouveaux comptes et saisir de nouvelles commandes clients.

La logique de traitement de ce système est écrite en Java et réside sur une machine Solaris, qui interagit également avec une base de données pour stocker des informations.

Les étapes pour effectuer cette opération sont les suivantes -

  • Le programme client regroupe les informations d'enregistrement du compte dans un message SOAP.

  • Ce message SOAP est envoyé au service Web en tant que corps d'une requête HTTP POST.

  • Le service Web décompresse la requête SOAP et la convertit en une commande que l'application peut comprendre.

  • L'application traite les informations selon les besoins et répond avec un nouveau numéro de compte unique pour ce client.

  • Ensuite, le service Web regroupe la réponse dans un autre message SOAP, qu'il renvoie au programme client en réponse à sa requête HTTP.

  • Le programme client décompresse le message SOAP pour obtenir les résultats du processus d'enregistrement de compte.

Voici les avantages de l'utilisation des services Web -

Exposer la fonction existante sur le réseau

Un service Web est une unité de code géré qui peut être appelée à distance à l'aide de HTTP. Autrement dit, il peut être activé à l'aide de requêtes HTTP. Les services Web vous permettent d'exposer les fonctionnalités de votre code existant sur le réseau. Une fois qu'il est exposé sur le réseau, d'autres applications peuvent utiliser les fonctionnalités de votre programme.

Interopérabilité

Les services Web permettent à diverses applications de se parler et de partager des données et des services entre elles. D'autres applications peuvent également utiliser les services Web. Par exemple, une application VB ou .NET peut communiquer avec des services Web Java et vice versa. Les services Web sont utilisés pour rendre la plate-forme d'application et la technologie indépendantes.

Protocole normalisé

Les services Web utilisent le protocole standard standard de l'industrie pour la communication. Les quatre couches (couches de transport de service, de messagerie XML, de description de service et de découverte de service) utilisent des protocoles bien définis dans la pile de protocoles des services Web. Cette standardisation de la pile de protocoles donne à l'entreprise de nombreux avantages tels qu'un large éventail de choix, une réduction des coûts due à la concurrence et une augmentation de la qualité.

Communication à faible coût

Les services Web utilisent le protocole SOAP sur HTTP, vous pouvez donc utiliser votre Internet bon marché existant pour implémenter des services Web. Cette solution est beaucoup moins coûteuse par rapport aux solutions propriétaires comme EDI / B2B. Outre SOAP sur HTTP, les services Web peuvent également être implémentés sur d'autres mécanismes de transport fiables tels que FTP.

Les services Web présentent les caractéristiques comportementales spéciales suivantes:

Basé sur XML

Les services Web utilisent XML au niveau des couches de représentation et de transport de données. L'utilisation de XML élimine toute liaison réseau, système d'exploitation ou plate-forme. Les applications basées sur les services Web sont hautement interopérables à leur niveau de base.

Couplage lâche

Un consommateur d'un service Web n'est pas directement lié à ce service Web. L'interface du service Web peut changer au fil du temps sans compromettre la capacité du client à interagir avec le service. Un système étroitement couplé implique que les logiques client et serveur sont étroitement liées l'une à l'autre, ce qui implique que si une interface change, l'autre doit être mise à jour. 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.

À gros grains

Les technologies orientées objet telles que Java exposent leurs services via des méthodes individuelles. Une méthode individuelle est une opération trop fine pour fournir une capacité utile au niveau de l'entreprise. La création d'un programme Java à partir de zéro nécessite la création de plusieurs méthodes à granularité fine qui sont ensuite composées en un service à granularité grossière qui est consommé par un client ou un autre service.

Les entreprises et les interfaces qu'elles exposent doivent être grossières. La technologie des services Web offre un moyen naturel de définir des services grossiers qui accèdent à la bonne quantité de logique métier.

Capacité à être synchrone ou asynchrone

La synchronicité fait référence à la liaison du client à l'exécution du service. Dans les appels synchrones, le client se bloque et attend que le service termine son opération avant de continuer. Les opérations asynchrones permettent à un client d'appeler un service, puis d'exécuter d'autres fonctions.

Les clients asynchrones récupèrent leur résultat ultérieurement, tandis que les clients synchrones reçoivent leur résultat lorsque le service est terminé. La capacité asynchrone est un facteur clé pour permettre des systèmes faiblement couplés.

Prend en charge les appels de procédure à distance (RPC)

Les services Web permettent aux clients d'appeler des procédures, des fonctions et des méthodes sur des objets distants à l'aide d'un protocole XML. Les procédures distantes exposent les paramètres d'entrée et de sortie qu'un service Web doit prendre en charge.

Le développement de composants via les EJB (Enterprise JavaBeans) et les composants .NET fait de plus en plus partie des architectures et des déploiements en entreprise au cours des deux dernières années. Les deux technologies sont distribuées et accessibles via une variété de mécanismes RPC.

Un service Web prend en charge RPC en fournissant ses propres services, équivalents à ceux d'un composant traditionnel, ou en traduisant les appels entrants en un appel d'un EJB ou d'un composant .NET.

Prend en charge l'échange de documents

L'un des principaux avantages de XML est 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 ou une demande de devis (RFQ). Les services Web prennent en charge l'échange transparent de documents pour faciliter l'intégration commerciale.

Il existe deux façons d'afficher l'architecture du service Web:

  • La première consiste à examiner les rôles individuels de chaque acteur du service Web.
  • La seconde consiste à examiner la pile de protocoles de service Web émergente.

Rôles du service Web

Il existe trois rôles principaux dans l'architecture de service Web:

Fournisseur de services

Il s'agit du fournisseur du service Web. Le fournisseur de services met en œuvre le service et le met à disposition sur Internet.

Demandeur de service

Il s'agit de n'importe quel consommateur du service Web. Le demandeur utilise un service Web existant en ouvrant une connexion réseau et en envoyant une requête XML.

Registre des services

Il s'agit d'un répertoire de services logiquement centralisé. Le registre fournit un endroit central où les développeurs peuvent publier de nouveaux services ou trouver des services existants. Il sert donc de chambre de compensation centralisée pour les entreprises et leurs services.

Pile de protocoles de service Web

Une deuxième option pour visualiser l'architecture du service Web consiste à examiner la pile de protocoles de service Web émergente. La pile évolue toujours, mais compte actuellement quatre couches principales.

Transport de service

Cette couche est responsable du transport des messages entre les applications. Actuellement, cette couche comprend le protocole de transport Hyper Text (HTTP), le protocole de transfert de courrier simple (SMTP), le protocole de transfert de fichiers (FTP) et les protocoles plus récents tels que le protocole d'échange extensible de blocs (BEEP).

Messagerie XML

Cette couche est responsable du codage des messages dans un format XML commun afin que les messages puissent être compris à chaque extrémité. Actuellement, cette couche comprend XML-RPC et SOAP.

Description du service

Cette couche est chargée de décrire l'interface publique avec un service Web spécifique. Actuellement, la description du service est gérée via le Web Service Description Language (WSDL).

Découverte de service

Cette couche est chargée de centraliser les services dans un registre commun et de fournir une fonctionnalité de publication / recherche facile. Actuellement, la découverte de services est gérée via la description, la découverte et l'intégration universelles (UDDI).

À mesure que les services Web évoluent, des couches supplémentaires peuvent être ajoutées et des technologies supplémentaires peuvent être ajoutées à chaque couche.

Le chapitre suivant explique les composants des services Web.

Quelques mots sur le service de transport

Le bas de la pile de protocoles de service Web est le transport de service. Cette couche est responsable du transport des messages XML entre deux ordinateurs.

Protocole de transfert Hyper Text (HTTP)

Actuellement, HTTP est l'option la plus populaire pour le transport de services. HTTP est simple, stable et largement déployé. De plus, la plupart des pare-feu autorisent le trafic HTTP. Cela permet aux messages XMLRPC ou SOAP de se faire passer pour des messages HTTP. C'est bien si vous souhaitez intégrer des applications distantes, mais cela soulève un certain nombre de problèmes de sécurité.

Bloque le protocole d'échange extensible (BEEP)

C'est une alternative prometteuse à HTTP. BEEP est un nouveau cadre IETF (Internet Engineering Task Force) pour la création de nouveaux protocoles. BEEP est directement posé sur TCP et comprend un certain nombre de fonctionnalités intégrées, notamment un protocole de prise de contact initial, l'authentification, la sécurité et la gestion des erreurs. En utilisant BEEP, on peut créer de nouveaux protocoles pour une variété d'applications, y compris la messagerie instantanée, le transfert de fichiers, la syndication de contenu et la gestion de réseau.

SOAP n'est lié à aucun protocole de transport spécifique. En fait, vous pouvez utiliser SOAP via HTTP, SMTP ou FTP. Une idée prometteuse est donc d'utiliser SOAP sur BEEP.

Au cours des dernières années, trois technologies principales sont devenues des normes mondiales qui constituent le cœur de la technologie actuelle des services Web. Ces technologies sont décrites ci-dessous.

XML-RPC

Il s'agit du protocole XML le plus simple pour l'échange d'informations entre ordinateurs.

  • XML-RPC est un protocole simple qui utilise des messages XML pour effectuer des RPC.

  • Les demandes sont encodées en XML et envoyées via HTTP POST.

  • Les réponses XML sont intégrées dans le corps de la réponse HTTP.

  • XML-RPC est indépendant de la plate-forme.

  • XML-RPC permet à diverses applications de communiquer.

  • Un client Java peut parler XML-RPC à un serveur Perl.

  • XML-RPC est le moyen le plus simple de démarrer avec les services Web.

Pour en savoir plus sur XML-RPC, visitez notre didacticiel XML-RPC .

SAVON

SOAP est un protocole basé sur XML pour l'échange d'informations entre ordinateurs.

  • SOAP est un protocole de communication.

  • SOAP est pour la communication entre les applications.

  • SOAP est un format d'envoi de messages.

  • SOAP est conçu pour communiquer via Internet.

  • SOAP est indépendant de la plateforme.

  • SOAP est indépendant du langage.

  • SOAP est simple et extensible.

  • SOAP vous permet de contourner les pare-feu.

  • SOAP sera développé en tant que norme W3C.

Pour en savoir plus sur SOAP, visitez notre didacticiel SOAP .

WSDL

WSDL est un langage basé sur XML pour décrire les services Web et comment y accéder.

  • WSDL signifie Web Services Description Language.

  • WSDL a été développé conjointement par Microsoft et IBM.

  • WSDL est un protocole basé sur XML pour l'échange d'informations dans des environnements décentralisés et distribués.

  • WSDL est le format standard pour décrire un service Web.

  • La définition WSDL décrit comment accéder à un service Web et quelles opérations il effectuera.

  • WSDL est un langage pour décrire comment s'interfacer avec des services basés sur XML.

  • WSDL fait partie intégrante de UDDI, un registre mondial des entreprises basé sur XML.

  • WSDL est le langage utilisé par UDDI.

  • WSDL est prononcé comme «wiz-terne» et épelé comme «WSD-L».

Pour en savoir plus sur WSDL, consultez notre didacticiel WSDL .

UDDI

UDDI est une norme basée sur XML pour la description, la publication et la recherche de services Web.

  • UDDI signifie Universal Description, Discovery et Integration.

  • UDDI est une spécification pour un registre distribué de services Web.

  • UDDI est un framework ouvert et indépendant de la plateforme.

  • UDDI peut communiquer via SOAP, CORBA et Java RMI Protocol.

  • UDDI utilise WSDL pour décrire les interfaces avec les services Web.

  • UDDI est considéré avec SOAP et WSDL comme l'une des trois normes fondamentales des services Web.

  • UDDI est une initiative industrielle ouverte permettant aux entreprises de se découvrir et de définir comment elles interagissent sur Internet.

Pour en savoir plus sur UDDI, visitez notre didacticiel UDDI .

Sur la base de l'architecture du service Web, nous créons les deux composants suivants dans le cadre de la mise en œuvre des services Web:

Fournisseur de services ou éditeur

Il s'agit du fournisseur du service Web. Le prestataire met en œuvre le service et le met à disposition sur Internet ou intranet.

Nous allons écrire et publier un service Web simple à l'aide du SDK .NET.

Demandeur de service ou consommateur

Il s'agit de n'importe quel consommateur du service Web. Le demandeur utilise un service Web existant en ouvrant une connexion réseau et en envoyant une requête XML.

Nous écrirons également deux demandeurs de service Web: un consommateur basé sur le Web (application ASP.NET) et un autre consommateur basé sur une application Windows.

Vous trouverez ci-dessous notre premier exemple de service Web qui fonctionne en tant que fournisseur de services et expose deux méthodes (add et SayHello) en tant que services Web à utiliser par les applications. Il s'agit d'un modèle standard pour un service Web. Les services Web .NET utilisent l'extension .asmx. Notez qu'une méthode exposée en tant que service Web a l'attribut WebMethod. Enregistrez ce fichier sous FirstService.asmx dans le répertoire virtuel IIS (comme expliqué dans la configuration d'IIS; par exemple, c: \ MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

Pour tester un service Web, il doit être publié. Un service Web peut être publié sur un intranet ou sur Internet. Nous publierons ce service Web sur IIS fonctionnant sur une machine locale. Commençons par configurer IIS.

  • Ouvrez Démarrer → Paramètres → Panneau de configuration → Outils d'administration → Gestionnaire des services Internet.

  • Développez et faites un clic droit sur le site Web par défaut; sélectionnez Nouveau & # rarr; Répertoire virtuel. L'assistant de création de répertoire virtuel s'ouvre. Cliquez sur Suivant.

  • L'écran "Virtual Directory Alias" s'ouvre. Tapez le nom du répertoire virtuel. Par exemple, MyWebServices. Cliquez sur Suivant.

  • L'écran "Répertoire de contenu du site Web" s'ouvre.

  • Entrez le nom du chemin du répertoire virtuel. Par exemple, c: \ MyWebServices. Cliquez sur Suivant.

  • L'écran "Autorisation d'accès" s'ouvre. Modifiez les paramètres selon vos besoins. Gardons les paramètres par défaut pour cet exercice.

  • Cliquez sur le bouton Suivant. Il termine la configuration IIS.

  • Cliquez sur Terminer pour terminer la configuration.

Pour tester si IIS a été configuré correctement, copiez un fichier HTML (par exemple, x.html) dans le répertoire virtuel (C: \ MyWebServices) créé ci-dessus. Maintenant, ouvrez Internet Explorer et tapezhttp://localhost/MyWebServices/x.html. Il devrait ouvrir le fichier x.html.

Note- Si cela ne fonctionne pas, essayez de remplacer l'hôte local par l'adresse IP de votre machine. Si cela ne fonctionne toujours pas, vérifiez si IIS est en cours d'exécution; vous devrez peut-être reconfigurer IIS et le répertoire virtuel.

Pour tester ce service Web, copiez FirstService.asmx dans le répertoire virtuel IIS créé ci-dessus (C: \ MyWebServices). Ouvrez le service Web dans Internet Explorer (http: //localhost/MyWebServices/FirstService.asmx). Il devrait ouvrir la page de votre service Web. La page doit contenir des liens vers deux méthodes exposées en tant que services Web par notre application. Toutes nos félicitations! Vous avez écrit votre premier service Web!

Test du service Web

Comme nous venons de le voir, l'écriture de services Web est facile dans le .NET Framework. L'écriture de consommateurs de services Web est également facile dans le framework .NET; cependant, c'est un peu plus compliqué. Comme indiqué précédemment, nous écrirons deux types de consommateurs de services, l'un basé sur le Web et l'autre basé sur l'application Windows. Écrivons notre premier consommateur de services Web.

Consommateur de services Web

Écrivez un consommateur basé sur le Web comme indiqué ci-dessous. Appelez-le WebApp.aspx. Notez qu'il s'agit d'une application ASP.NET. Enregistrez-le dans le répertoire virtuel du service Web (c: \ MyWebServices \ WebApp.axpx).

Cette application a deux champs de texte qui sont utilisés pour obtenir des nombres de l'utilisateur à ajouter. Il a un bouton, Exécuter, qui, lorsqu'il est cliqué, obtient les services Web Add et SayHello.

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

Une fois le consommateur créé, nous devons créer un proxy pour le service Web à consommer. Ce travail est effectué automatiquement par Visual Studio .NET pour nous lors du référencement d'un service Web qui a été ajouté. Voici les étapes à suivre -

  • Créez un proxy pour le service Web à utiliser. Le proxy est créé à l'aide de l'utilitaire WSDL fourni avec le SDK .NET. Cet utilitaire extrait les informations du service Web et crée un proxy. Le proxy n'est valide que pour un service Web particulier. Si vous devez utiliser d'autres services Web, vous devez également créer un proxy pour ce service. Visual Studio .NET crée automatiquement un proxy pour vous lorsque la référence de service Web est ajoutée. Créez un proxy pour le service Web à l'aide de l'utilitaire WSDL fourni avec le SDK .NET. Il créera le fichier FirstSevice.cs dans le répertoire courant. Nous devons le compiler pour créer FirstService.dll (proxy) pour le service Web.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

  • Placez le proxy compilé dans le répertoire bin du répertoire virtuel du Web Service (c: \ MyWebServices \ bin). Internet Information Services (IIS) recherche le proxy dans ce répertoire.

  • Créez le consommateur de service, de la même manière que nous l'avons déjà fait. Notez qu'un objet du proxy de service Web est instancié dans le consommateur. Ce proxy s'occupe de l'interaction avec le service.

  • Tapez l'URL du consommateur dans IE pour le tester (par exemple, http: //localhost/MyWebServices/WebApp.aspx).

Consommateur de services Web Windows

L'écriture d'un consommateur de service Web basé sur une application Windows est identique à l'écriture de toute autre application Windows. Il vous suffit de créer le proxy (ce que nous avons déjà fait) et de référencer ce proxy lors de la compilation de l'application. Voici notre application Windows qui utilise le service Web. Cette application crée un objet de service Web (bien sûr, un proxy) et appelle les méthodes SayHello et Add dessus.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Compilez-le en utilisant c:\>csc /r:FirstService.dll WinApp.cs. Cela créera WinApp.exe. Exécutez-le pour tester l'application et le service Web.

Maintenant, la question se pose: comment pouvez-vous être sûr que cette application appelle réellement le service Web?

C'est simple à tester. Arrêtez votre serveur Web afin que le service Web ne puisse pas être contacté. Maintenant, exécutez l'application WinApp. Il déclenchera une exception d'exécution. Maintenant, redémarrez le serveur Web. Ça devrait marcher.

La sécurité est essentielle aux services Web. Cependant, ni les spécifications XML-RPC ni SOAP n'imposent des exigences de sécurité ou d'authentification explicites.

Il existe trois problèmes de sécurité spécifiques avec les services Web:

  • Confidentiality
  • Authentication
  • Sécurité Internet

Confidentialité

Si un client envoie une requête XML à un serveur, pouvons-nous nous assurer que la communication reste confidentielle?

La réponse se trouve ici -

  • XML-RPC et SOAP s'exécutent principalement sur HTTP.
  • HTTP prend en charge Secure Sockets Layer (SSL).
  • La communication peut être cryptée via SSL.
  • SSL est une technologie éprouvée et largement déployée.

Un seul service Web peut être constitué d'une chaîne d'applications. Par exemple, un grand service peut relier les services de trois autres applications. Dans ce cas, SSL n'est pas adéquat; les messages doivent être chiffrés à chaque nœud le long du chemin de service, et chaque nœud représente un maillon faible potentiel dans la chaîne. Actuellement, il n'y a pas de solution convenue à ce problème, mais une solution prometteuse est la norme de chiffrement XML du W3C. Cette norme fournit un cadre pour crypter et décrypter des documents XML entiers ou juste des portions d'un document XML. Vous pouvez le vérifier sur www.w3.org/Encryption

Authentification

Si un client se connecte à un service Web, comment identifier l'utilisateur? L'utilisateur est-il autorisé à utiliser le service?

Les options suivantes peuvent être envisagées mais il n'y a pas de consensus clair sur un schéma d'authentification forte.

  • HTTP inclut un support intégré pour l'authentification de base et Digest, et les services peuvent donc être protégés de la même manière que les documents HTML sont actuellement protégés.

  • SOAP Digital Signature (SOAP-DSIG) exploite la cryptographie à clé publique pour signer numériquement les messages SOAP. Il permet au client ou au serveur de valider l'identité de l'autre partie. Vérifiez-le sur www.w3.org/TR/SOAP-dsig .

  • L'Organisation pour l'avancement des normes d'information structurée (OASIS) travaille sur le langage SAML (Security Assertion Markup Language).

Sécurité Internet

Il n’existe actuellement pas de réponse facile à ce problème et il a fait l’objet de nombreux débats. Pour l'instant, si vous avez vraiment l'intention de filtrer les messages SOAP ou XML-RPC, une possibilité est de filtrer toutes les requêtes HTTP POST qui définissent leur type de contenu sur text / xml.

Une autre alternative consiste à filtrer l'attribut d'en-tête HTTP SOAPAction. Les fournisseurs de pare-feu développent également actuellement des outils explicitement conçus pour filtrer le trafic des services Web.

Ce chapitre vous donne une idée de toutes les dernières normes relatives aux services Web.

Les transports

BEEP, le protocole d'échange extensible de blocs (anciennement appelé BXXP), est un cadre permettant de créer des protocoles d'application. Il a été normalisé par l'IETF et fait pour les protocoles Internet ce que XML a fait pour les données.

Messagerie

Ces normes et spécifications de messagerie sont destinées à donner un cadre pour l'échange d'informations dans un environnement décentralisé et distribué.

Description et découverte

Les services Web n'ont de sens que si les utilisateurs potentiels peuvent trouver des informations suffisantes pour permettre leur exécution. L'objectif de ces spécifications et normes est la définition d'un ensemble de services prenant en charge la description et la découverte d'entreprises, d'organisations et d'autres fournisseurs de services Web; les services Web qu'ils mettent à disposition; et les interfaces techniques qui peuvent être utilisées pour accéder à ces services.

Sécurité

En utilisant ces spécifications de sécurité, les applications peuvent s'engager dans une communication sécurisée conçue pour fonctionner avec le cadre général des services Web.

La gestion

La gérabilité des services Web est définie comme un ensemble de capacités permettant de découvrir l'existence, la disponibilité, l'intégrité, les performances, l'utilisation, ainsi que le contrôle et la configuration d'un service Web dans l'architecture des services Web. Alors que les services Web deviennent omniprésents et essentiels aux opérations commerciales, la tâche de les gérer et de les mettre en œuvre est impérative pour le succès des opérations commerciales.

Dans ce didacticiel, vous avez appris à utiliser les services Web. Cependant, un service Web comprend également des composants tels que WSDL, UDDI et SOAP qui contribuent à le rendre actif. L'étape suivante consiste à apprendre WSDL, UDDI et SOAP.

WSDL

WSDL est un langage basé sur XML pour décrire les services Web et comment y accéder.

WSDL décrit un service Web, ainsi que le format du message et les détails du protocole pour le service Web.

Pour en savoir plus sur WSDL, consultez notre didacticiel WSDL .

UDDI

UDDI est une norme basée sur XML pour la description, la publication et la recherche de services Web.

Pour en savoir plus sur UDDI, visitez notre didacticiel UDDI .

SAVON

SOAP est un protocole basé sur XML simple qui permet aux applications d'échanger des informations via HTTP.

Pour en savoir plus sur SOAP, visitez notre didacticiel SOAP .