Services Web dans Java SE, Partie 1: Présentation des outils

Java Standard Edition (SE) 6 incluait la prise en charge des services Web. Cet article commence une série en quatre parties sur les services Web dans Java SE en expliquant ce que sont les services Web et en présentant la prise en charge de Java SE. Les futurs articles utiliseront cette prise en charge pour créer des services Web basés sur SOAP et RESTful, et couvriront également des sujets avancés sur les services Web.

Java XML et JSON

Dans cette série, je suppose que vous comprenez XML et JSON. Sinon, vous voudrez peut-être consulter mon livre Java XML et JSON , qui est annoncé à la fin de cet article.

Que sont les services Web?

Wikipedia définit le service Web comme «un système logiciel conçu pour prendre en charge une interaction interopérable de machine à machine sur un réseau». Une définition plus détaillée peut être obtenue en définissant d'abord les parties de ce terme:

  • Web: un énorme réseau interconnecté de ressources, où une ressource est une source de données nommée URI (Uniform Resource Identifier), comme un document PDF, un flux vidéo, une page Web ou même une application. Ces ressources sont accessibles à l'aide de protocoles Internet standard tels que HyperText Transfer Protocol (HTTP) ou Simple Mail Transfer Protocol (SMTP).
  • Service: Une application ou un composant logiciel basé sur un serveur qui expose une ressource aux clients via un échange de messages selon un modèle d'échange de messages (MEP). Le MEP demande-réponse est typique.

Compte tenu de ces définitions, un service Web est un composant logiciel / application basé sur un serveur qui expose une ressource Web aux clients via un échange de messages. Ces messages peuvent être formatés selon Extensible Markup Language (XML) ou JavaScript Object Notation (JSON). En outre, ces messages peuvent être considérés comme appelant des fonctions de service Web et recevant des résultats d'appel. La figure 1 illustre cet échange de messages.

Figure 1. Un client accède à une ressource en échangeant des messages avec un service Web

Entreprises et services Web

Les entreprises utilisent les services Web parce qu'elles surmontent les problèmes de middleware traditionnels (par exemple, coûteux à obtenir et à maintenir, incapables de communiquer avec les logiciels backend et les applications client sur Internet, et inflexibles) en se basant sur des normes libres et ouvertes, par leur maintenabilité, en impliquant le Web, et en étant flexible. En outre, ils aident les grandes entreprises à préserver leurs investissements souvent importants dans les logiciels existants.

Les services Web peuvent être classés comme simples ou complexes. Les services Web simples n'interagissent pas avec d'autres services Web (par exemple, une application serveur autonome avec une seule fonction qui renvoie l'heure actuelle pour un fuseau horaire spécifié). En revanche, les services Web complexes interagissent souvent avec d'autres services Web. Par exemple, un service Web de réseau social généralisé peut interagir avec les services Web Twitter et Facebook pour obtenir et renvoyer à son client toutes les informations Twitter et Facebook d'une personne spécifique. Les services Web complexes sont également connus sous le nom mashups parce qu'ils écrasez (Combine) les données de plusieurs services Web.

Architecture orientée services

Les services Web sont une implémentation de l' architecture orientée services (SOA) , qui est un style de conception logicielle dans lequel les services sont fournis à divers composants logiciels via un protocole de communication sur un réseau. Considérez SOA comme un ensemble de principes de conception ou un cadre pour la mise en œuvre de la logique métier en tant que services réutilisables qui peuvent être combinés de différentes manières pour répondre aux besoins évolutifs de l'entreprise.

Services Web basés sur SOAP

Un service Web basé sur SOAP est une catégorie de service Web largement utilisée qui est basée sur SOAP , un langage XML pour définir des messages (appels de fonctions abstraites ou leurs réponses) qui peuvent être compris par les deux extrémités d'une connexion réseau. Un échange de messages SOAP est appelé une opération , qui correspond à un appel de fonction et à sa réponse, et qui est illustrée à la figure 2.

Figure 2. Une opération de service Web implique des messages d'entrée et de sortie

Les opérations associées sont souvent regroupées dans une interface , qui est conceptuellement similaire à une interface Java. Une liaison fournit des détails concrets sur la manière dont une interface est liée à un protocole de messagerie (en particulier SOAP) pour communiquer des commandes, des codes d'erreur et d'autres éléments via le câble. L' URI de liaison et d' adresse réseau (une adresse IP et un port) est appelé point de terminaison , et une collection de points de terminaison est un service Web . La figure 3 présente cette architecture.

Figure 3. Les interfaces des opérations sont accessibles via leurs terminaux

SOAP est souvent utilisé avec le langage de description de services Web (WSDL, prononcé whiz-dull) , un langage XML pour définir les opérations d'un service Web. Un document WSDL est un contrat formel entre un service Web SOAP et ses clients, fournissant tous les détails pour interagir avec le service Web. Ce document vous permet de regrouper les messages en opérations et les opérations en interfaces. Il vous permet également de définir une liaison pour chaque interface ainsi que l'adresse du point de terminaison.

Outre la prise en charge des documents WSDL, les services Web SOAP ont les propriétés suivantes:

  • La capacité de répondre à des exigences non fonctionnelles complexes telles que la sécurité et les transactions: ces exigences sont rendues disponibles via diverses spécifications. Pour promouvoir l'interopérabilité entre ces spécifications, l' Organisation d'interopérabilité des services Web (WS-I) (un consortium industriel) a été créée. WS-I a établi un ensemble de profils, où un profil est un ensemble de spécifications de service Web nommées à des niveaux de révision spécifiques, ainsi qu'un ensemble de directives d'implémentation et d'interopérabilité recommandant la manière dont les spécifications peuvent être utilisées pour développer des services Web interopérables. Par exemple, le tout premier profil, WS-I Basic Profile 1.0 , se compose de l'ensemble suivant de spécifications de services Web non propriétaires:
  • SAVON 1.1
  • WSDL 1.1
  • Découverte et intégration de description universelle (UDDI) 2.0
  • XML 1.0 (deuxième édition)
  • Schéma XML Partie 1: Structures
  • Schéma XML, partie 2: types de données
  • RFC2246: Le protocole de sécurité de la couche de transport version 1.0
  • RFC2459: Certificat d'infrastructure à clé publique Internet X.509 et profil CRL
  • RFC2616: Protocole de transfert HyperText 1.1
  • RFC2818: HTTP sur TLS
  • RFC2965: Mécanisme de gestion d'état HTTP
  • Le protocole Secure Sockets Layer version 3.0

Des exemples de profil supplémentaires incluent WS-I Basic Security Profile et Simple SOAP Binding Profile. Pour plus d'informations sur ces profils et d'autres, visitez le site Web WS-I. Java SE prend en charge le profil de base WS-I.

  • La possibilité d'interagir avec un service Web de manière asynchrone: les clients de service Web doivent pouvoir interagir avec un service Web de manière non bloquante et asynchrone. La prise en charge des appels asynchrones côté client des opérations de service Web est fournie dans Java SE.

Les services Web SOAP s'exécutent dans un environnement qui comprend un demandeur de service (le client), un fournisseur de services et un courtier de services. Cet environnement est illustré à la figure 4.

Figure 4. Un service Web basé sur SOAP implique un demandeur de service, un fournisseur de services et un courtier de services (par exemple, UDDI)

Le demandeur de service, généralement une application cliente (par exemple, un navigateur Web), ou peut-être un autre service Web, localise d'abord le fournisseur de services d'une manière ou d'une autre. Par exemple, le demandeur de service peut envoyer un document WSDL à un courtier de services, qui répond par un autre document WSDL identifiant l'emplacement du fournisseur de services. Le demandeur de service communique ensuite avec le fournisseur de services via des messages SOAP.

Les prestataires de services doivent être publiés pour que d'autres puissent les localiser et les utiliser. En août 2000, une initiative industrielle ouverte connue sous le nom d' UDDI (Universal Description, Discovery, and Integration) a été lancée pour permettre aux entreprises de publier des listes de services, de se découvrir mutuellement et de définir comment les services ou les applications logicielles interagissent sur Internet. Cependant, ce registre basé sur XML et indépendant de la plate-forme n'a pas été largement adopté et n'est actuellement pas utilisé. De nombreux développeurs ont trouvé l'UDDI trop compliqué et manquant de fonctionnalités, et ont opté pour des alternatives telles que la publication des informations sur un site Web. Par exemple, Google a déjà rendu ses services Web publics (par exemple, Google Maps) disponibles sur //code.google.com/more/.

Les messages SOAP qui circulent entre les demandeurs de service et les fournisseurs de services sont souvent invisibles, étant transmis sous forme de demandes et de réponses entre les bibliothèques SOAP de leurs piles de protocoles de service Web. Cependant, il est possible d'accéder directement à ces messages, comme vous le découvrirez plus tard dans cette série.

Grands services Web

Les services Web SOAP sont également connus sous le nom de grands services Web car ils sont basés sur de nombreuses spécifications, telles que les profils WS-I mentionnés précédemment.

Services Web RESTful

Les services Web SOAP peuvent être fournis via des protocoles tels que HTTP, SMTP, FTP et le protocole d'échange extensible de blocs (BEEP). La distribution de messages SOAP via HTTP peut être considérée comme un type spécial de service Web RESTful.

Un service Web RESTful est une catégorie de service Web largement utilisée qui est basée sur Representational State Transfer (REST) , un style d'architecture logicielle pour les systèmes hypermédia distribués (systèmes dans lesquels les images, le texte et d'autres ressources sont situés autour des réseaux et sont accessibles via des hyperliens) . Le système hypermédia d'intérêt dans un contexte de services Web est le World Wide Web.

Historique REST

Roy Fielding (auteur principal des versions 1.0 et 1.1 de la spécification HTTP et cofondateur de l'Apache Software Foundation) a introduit et défini REST dans sa thèse de doctorat en 2000. Fielding envisageait REST comme le style architectural du Web, bien qu'il ait écrit il s'est installé longtemps après que le Web était une entreprise en cours. REST est largement considéré comme la solution à ce qui est considéré comme la complexité croissante des services Web SOAP.

La partie centrale de REST est la ressource identifiable par URI. REST identifie les ressources par leurs types MIME (Multipurpose Internet Mail Extensions) (tels que text / xml). En outre, les ressources ont des états qui sont capturés par leurs représentations. Lorsqu'un client demande une ressource à un service Web RESTful, le service envoie une représentation de type MIME de la ressource au client.

Les clients utilisent les verbes POST, GET, PUT et DELETE de HTTP pour récupérer les représentations des ressources et manipuler les ressources. REST mappe ces verbes sur les opérations de création, de lecture, de mise à jour et de suppression (CRUD) de la base de données, comme suit:

  • POST: Créez une nouvelle ressource basée sur les données de la demande.
  • GET: Lisez la ressource existante sans produire d'effets secondaires (ne modifiez pas la ressource).
  • PUT: mettre à jour la ressource existante avec les données de la demande.
  • SUPPRIMER: supprimer la ressource existante.

Chaque verbe est suivi d'un URI qui identifie la ressource. (Cette approche extrêmement simple est fondamentalement incompatible avec l'approche SOAP d'envoi de messages codés à une seule ressource.) L'URI peut faire référence à une collection, telle que //javajeff.ca/library, ou à un élément de la collection, tels que //javajeff.ca/library/9781484219157- ces URI ne sont que des illustrations.

Pour les demandes POST et PUT, les données de ressources basées sur XML sont transmises comme corps de la demande. Par exemple, vous pouvez interpréter POST //javajeff.ca/library HTTP/ 1.1(où HTTP/ 1.1décrit la version HTTP du demandeur) comme une demande d'insertion POSTdes données XML de la //javajeff.ca/libraryressource de collection.

Pour les demandes GET et DELETE, les données sont généralement transmises sous forme de chaînes de requête, où une chaîne de requête est la partie d'un URI commençant par un ?caractère. Par exemple, où GET //javajeff.ca/librarypourrait renvoyer une liste d'identificateurs pour tous les livres d'une libraryressource, GET //javajeff.ca/library?isbn=9781484219157renverrait probablement une représentation de la ressource de livre dont la chaîne de requête identifie le numéro international normalisé du livre (ISBN) 9781484219157.

En savoir plus sur les mappages HTTP-CRUD

Pour une description complète des mappages entre les verbes HTTP et leurs équivalents CRUD, consultez le tableau «Méthodes HTTP du service Web RESTful» dans l'entrée Representational State Transfer de Wikipedia.

REST s'appuie également sur les codes de réponse standard de HTTP, tels que 404 (ressource demandée non trouvée) et 200 (opération de ressource réussie), ainsi que sur les types MIME (lorsque les représentations de ressources sont récupérées).

RESTful vs grands services Web

Si vous vous demandez s'il faut développer un service Web à l'aide de SOAP ou REST, consultez RESTful Web Services vs "Big" Web Services: Making the Right Architectural Decision.

Prise en charge des services Web dans Java SE

Avant Java SE 6, les services Web basés sur Java étaient développés exclusivement avec le SDK Java Enterprise Edition (EE). Bien que Java EE soit préféré pour développer des services Web dans une perspective de production, car les serveurs basés sur Java EE offrent un très haut degré d'évolutivité, une infrastructure de sécurité, des fonctions de surveillance, etc. conteneur a souvent pris du temps, ce qui a ralenti le développement. Java SE 6 a simplifié et accéléré le développement de services Web en ajoutant des API, des annotations, des outils et un serveur HTTP léger (pour déployer des services Web sur un simple serveur Web et les tester dans cet environnement) dans son noyau.

Apis

Java SE fournit plusieurs API prenant en charge les services Web. Outre diverses API JAXP (SAX, DOM, StAX, etc.) dont je discute en Java XML et JSON , Java SE fournit les API JAX-WS, JAXB et SAAJ: