Conseil

Le rôle d’un ESB dans l’intégration RESTful

Les Enterprise Service Bus devraient cesser de jouer le rôle de pivot central d’intégration pour se spécialiser dans l’intégration des applications existantes vers une nouvelle architecture RESTful.

Todd Biske
par
Publié le: 03 mars 2015

Si certains comparent REST à XML, ces deux approches ne sont pas concurrentes. En fait, on peut probablement classer les approches actuelles en trois catégories :

  1. les services Web SOAP ;
  2. les services Web sans SOAP mis en œuvre avec XML/HTTP, avec ou sans schéma formel ;
  3. les véritables services REST qui recourent aux méthodes HTTP, aux types MIME et à HATEOAS (Hypermedia As The Engine Of Application State ; ou hypermédia en tant que moteur de l'état des applications).

D’après mon expérience, de plus en plus de services sont classés dans la 2ème catégorie.

La confusion naît du fait que cette catégorie est systématiquement associée aux services RESTful alors qu’elle n’en contient pas. Elle renferme simplement des services XML envoyés via l’opération HTTP POST, sans enveloppe SOAP; ni code WSDL.

Ces services sont plus facilement exploités par un consommateur qui s’appuie sur un navigateur et utilise JavaScript, que par un service SOAP. Ils peuvent être exposés via une technologie JSON/HTTP plutôt que XML pour faciliter leur compréhension par les navigateurs des consommateurs. Toutefois, ils recourent généralement à l’opération POST pour la plupart des fonctions, voire toutes.

L’utilisation de services Web SOAP reste assez courante au sein de l’entreprise. De nombreux produits intégrés exposent leurs services à l’aide de services SOAP et d’un code WSDL, pour profiter de l’excellente intégration d’outils que fournit une interface bien définie. Toutefois, ces services s’exposent de plus en plus couramment sous la forme XML/HTTP, voire sous celle de véritables services REST.

Mon expérience montre que la 3ème catégorie reste la moins courante, au moins dans l’entreprise, mais que son usage se développe.

Quelle est l’incidence de ces tendances sur le rôle de l’ESB ?

Le recours accru au protocole HTTP ne fait qu’encourager l’utilisation renforcée d’un intermédiaire. Pensez au nombre d’intermédiaires qui existent déjà dans l’espace HTTP. On trouve notamment des appliances de mise en cache, des équilibreurs de charge ou encore des produits de sécurité Web. La vraie question est de savoir si vous avez toujours besoin d’un ESB ou si vous pouvez vous en sortir avec les intermédiaires HTTP existants déjà présents dans la plupart des entreprises.

La problématique est la suivante : plus vous êtes proche de la 3ème option, moins vous êtes susceptible de disposer d’une spécification formelle des messages concernés.

La première option comprend des fichiers WSDL, et la deuxième des schémas XML. Mais la troisième n’inclura rien d’autre que la documentation de développement sur les réponses attendues à une requête GET ou les paramètres HTTP acceptés dans une méthode PUT ou POST. Ceci n’empêche pas l’utilisation d’un intermédiaire comme un ESB, mais la somme de travail pour arriver au même résultat peut se révéler plus importante.

Le scénario le plus probable est encore de s’appuyer sur un ESB pour faire le lien entre des systèmes des catégories 1 et 2 (SOAP/HTTP, XML/HTTP) et des consommateurs qui veulent des services de catégorie.

Par exemple, il n’y a aucune raison de ne pas recourir à un service Web SOAP avec une opération getOrder() et d’utiliser un ESB pour l’exposer comme un service REST accessible avec une requête GET à http://rest-services/order?id=xxxxx.

L’ESB se trouve alors clairement dans l’espace d’intégration où vous voulez exposer les services REST d’un système incapable de le faire, plutôt que dans un rôle d’intermédiaire à tout faire, traversé par tous les flux de trafic. 

En bref, les trois approches décrites ont certainement toutes une place pour les intermédiaires. Il suffit d’observer l’utilisation d’un équilibreur de charge HTTP dans pratiquement n’importe quel système Web pour le comprendre.

Quant aux ESB, ils devraient être relégués à la médiation entre les interfaces souhaitées de type REST et les interfaces exposées par les systèmes sous-jacents impliqués. Si ces systèmes ne sont pas modifiables, vous aurez besoin d’un intermédiaire pour combler les manques et il se pourrait qu’un ESB réponde à ce besoin.

Pour approfondir sur Middleware et intégration de données