En tant que développeur Java d'entreprise, vous passerez plus de temps à intégrer des systèmes via les services Web et la messagerie Java. Les concepts de base des web services Java sont indispensables aux développeurs Java.

#1 : Les différents styles de web services utilisés aujourd’hui pour intégrer les applications sont SOAP Web Service et RESTful Web Service. Les services Web sont très populaires et largement utilisés pour intégrer des systèmes similaires (applications Java) et disparates (applications anciennes et applications écrites en .Net, etc.) car ils sont indépendants du langage.


SOAP Web Service

RESTfull Web Service

SOAP (Simple Object Access Protocol) est un protocole de communication standard au-dessus des protocoles de transport tels que HTTP, SMTP, Messagerie, TCP, UDP, etc.

REST (Representational state transfer) est un style architectural par lequel les données peuvent être transmises via un protocole de transport tel que HTTP (S).

Chaque URL unique est une représentation d’une ressource (par exemple, un objet tel que Compte, Client, etc.), et vous pouvez obtenir le contenu des ressources (par exemple, Objets) via les commandes HTTP "GET" et les modifier via "DELETE", "POST ”Ou“ PUT ”.

SOAP utilise son propre protocole et vise à exposer des éléments de logique applicative (et non des données) en tant que services. SOAP expose les opérations. SOAP est axé sur l'accès aux opérations nommées, qui implémentent une logique métier via différentes interfaces.

REST consiste à exposer une API publique sur Internet pour gérer les opérations CRUD (Créer, Lire, Mettre à jour et Supprimer) sur des données. REST est axé sur l'accès aux ressources nommées via une interface cohérente unique.

SOAP n'autorise que les formats de données XML.

REST autorise de nombreux formats de données différents, tels que XML, JSON, texte, HTML, atom, RSS, etc. JSON est moins verbeux que XML et convient mieux aux données et analyse beaucoup plus rapidement.

Les opérations de lectures basées sur SOAP ne peuvent pas être mises en cache. L'application qui utilise SOAP doit fournir la mise en cache.

Les opérations de lectures basées sur REST peuvent être mises en cache et donc mieux scalables.

Prend en charge à la fois la sécurité SSL et la sécurité WS, qui ajoute certaines fonctionnalités de sécurité d'entreprise. Prend en charge l'identité par le biais d'intermédiaires, pas seulement le protocole SSL point à point.

- WS-Security conserve son cryptage jusqu'au moment du traitement de la demande.

- WS-Security vous permet de sécuriser des parties (par exemple, uniquement les détails de carte de crédit) du message à sécuriser. Étant donné que le cryptage / décryptage n'est pas une opération peu coûteuse, cela peut améliorer les performances des messages plus volumineux.

- Il est également possible avec WS-Security de sécuriser différentes parties du message à l'aide de différentes clés ou algorithmes de cryptage. Cela permet à différentes personnes de lire différentes parties du message sans exposer d’autres informations inutiles.

- La sécurité SSL ne peut être utilisée qu'avec HTTP. WS-Security peut être utilisé avec d'autres protocoles tels que UDP, SMTP, etc.

Prend en charge uniquement la sécurité SSL point à point.

- Le mécanisme de base derrière SSL est que le client chiffre toutes les demandes en fonction d'une clé extraite d'un tiers. Lorsque la demande est reçue à la destination, elle est déchiffrée et présentée au service. Cela signifie que la demande est uniquement cryptée lorsqu'elle se déplace entre le client et le serveur. Une fois arrivé au serveur (ou un proxy qui a un certificat valide), il est déchiffré à partir de ce moment.

- Le SSL chiffre tout le message, qu'il soit sensible ou non.

Prise en charge complète de la gestion des transactions basée sur ACID pour les transactions de courte durée et de la gestion des transactions basée sur la compensation pour les transactions de longue durée. Il prend également en charge la validation en deux phases sur des ressources distribuées.

REST prend en charge les transactions, mais il n'est ni conforme à ACID, ni capable d'effectuer une validation en deux phases sur des ressources transactionnelles distribuées, car il est limité par son protocole HTTP.

SOAP intègre une logique de success/retry et offre une fiabilité de bout en bout, même via des intermédiaires SOAP.

REST n'a pas de système de messagerie standard et attend des clients qui invoquent le service qu'ils gèrent les échecs de communication en tentant une nouvelle tentative.


Lequel à privilégier? En général, un service Web basé sur REST est préféré en raison de sa simplicité, de ses performances, de son évolutivité et de la prise en charge de plusieurs formats de données. SOAP est privilégié lorsque le service nécessite une prise en charge complète de la sécurité et de la fiabilité transactionnelle.

Une bonne architecture SOA concerne davantage RESTFul + JSON, privilégiant les approches plus légères pour la transmission des messages que les ESB lourds utilisant WSDL + XML qui ont donné une mauvaise réputation à SOA.


2 # Différence entre SOA (Service Oriented Architecture) et WOA (Web Oriented Architecture)


WOA étend l'architecture SOA à une architecture légère utilisant des technologies telles que REST et POX (Plain Old XML). POX complimente REST. JSON est une variante pour les données renvoyées par les services Web REST. Il consomme moins de bande passante et est facilement manipulé par les développeurs Web maîtrisant le langage Javascript.



SOA et WOA diffèrent en termes de couches d'abstraction. La SOA est un style architectural au niveau système qui tente d'exposer les fonctionnalités métier de manière à ce qu'elles puissent être utilisées par de nombreuses applications. WOA est un style architectural de niveau interface qui met l'accent sur les moyens par lesquels ces fonctionnalités de service sont exposées aux consommateurs. Vous pouvez commencer avec une WOA puis évoluer vers la SOA.


Selon Nick Gall, «WOA = SOA + REST + WWW». Dans le diagramme ci-dessus du niveau Service Orchestration, responsable du découplage des services,


Pour la SOA =>, vous créerez des services Web de style SOAP dans le «niveau de service».


Pour la WOA =>, vous allez créer des services Web de style REST plus légers dans le «niveau de service».


3 # : Quel style de service Web à utiliser? SOAP WS ou REST ?

En général, un service Web basé sur REST est préféré en raison de sa simplicité, de ses performances, de son évolutivité et de la prise en charge de plusieurs formats de données. SOAP est privilégié lorsque le service nécessite une prise en charge complète de la sécurité et de la fiabilité transactionnelle.

La réponse dépend vraiment des exigences fonctionnelles et non fonctionnelles. Poser les questions énumérées ci-dessous vous aidera à choisir :


1) Le service expose-t-il des données ou une logique métier? (REST est un meilleur choix pour exposer des données, SOAP WS pourrait être un meilleur choix pour la logique).


2) Les consommateurs et les fournisseurs de services ont-ils besoin d'un contrat formel? (SOAP a un contrat formel via WSDL).


3) Devons-nous prendre en charge plusieurs formats de données?


4) Faut-il faire des appels AJAX? (REST peut utiliser XMLHttpRequest).


5) L'appel est-il synchrone ou asynchrone?


6) L’appel a-t-il un état ou est-il stateless ? (REST convient aux opérations CRUD stateless).


7) Quel niveau de sécurité est requis? (SOAP WS supporte mieux la sécurité).


8) Quel niveau de support de transaction est requis? (SOAP WS prend mieux en charge la gestion des transactions).


9) Avons-nous une largeur de bande limitée? (SOAP est plus bavard).


10) Quel est le meilleur choix pour les développeurs qui créer des clients pour le service?

(REST est plus facile à implémenter, à tester et à maintenir).


4# : Quels outils utilisez-vous pour tester vos services Web?


Outil SoapUI pour les tests de services Web SOAP WS & RESTFull et sur le navigateur le plug-in «poster» de Firefox ou l’extension «Postman» de Google Chrome pour les services RESTFull.


5# : Pourquoi ne pas privilégier les middlewares traditionnels tels que RPC, CORBA, RMI et DCOM plutôt que les services Web?


Les middlewares intermédiaires traditionnels créent un couplage fort aux applications. Les applications avec un couplage fort sont difficiles à maintenir et moins réutilisables. Généralement, ne supportent pas l’hétérogénéité, ne fonctionnent pas sur Internet et peut être plus coûteux et difficiles à utiliser.


Les services Web sont moins couplés aux applications. L'interface du service Web fournit une couche d'abstraction entre le client et le serveur. Les applications faiblement couplées réduisent les coûts de maintenance et augmentent la possibilité de réutilisation. Les services Web présentent une nouvelle forme de middleware basée sur XML et le Web. Les services Web sont indépendants du langage et de la plateforme. Vous pouvez développer un service Web en utilisant n’importe quel langage et le déployer sur n’importe quelle plate-forme, du petit appareil au plus grand supercalculateur. Le service Web utilise des protocoles indépendants du langage, tels que HTTP, et permet la communication entre différentes applications en passant des messages XML ou JSON via une API Web. Fonctionnent mieux sur Internet, moins cher et plus facile à utiliser.


6# : Quelle est la différence entre SOA et un service Web?


La SOA est un principe de conception de logiciel et un modèle architectural permettant de mettre en œuvre des services à faible couplage et réutilisables. Vous pouvez implémenter SOA à l'aide de protocoles tels que HTTP, HTTPS, JMS, SMTP, RMI, IIOP (c'est-à-dire que EJB utilise IIOP), RPC, etc. Les messages peuvent être au format XML ou DTO (Data Transfer Objects).


Le service Web est une technologie d'implémentation et l'un des moyens d'implémenter la SOA. Vous pouvez créer des applications SOA sans utiliser de services Web - par exemple, en utilisant d'autres technologies traditionnelles telles que Java RMI, EJB, messagerie basée sur JMS, etc. Mais les services Web sont des services basés sur des normes et indépendants de la plateforme via HTTP, XML, SOAP , WSDL et UDDI, permettant ainsi l’interopérabilité entre des technologies hétérogènes telles que J2EE et .NET.