Interfaces SOA et RESTful : quand et pourquoi les combiner

SOA et REST en détail

L'architecture SOA est conçue pour faciliter le développement d'applications flexibles et agiles en réutilisant des composants communs au sein d'un modèle général de gestion des processus métier. Le couplage des composants est peu contraignant ; en d'autres termes, les composants sont localisés via un processus d'enregistrement par publication/abonnement, tandis que leur association est assurée par un mécanisme général d'accès aux objets (le plus souvent, le protocole SOAP, Simple Object Access Protocol). Ce mécanisme utilise un langage de définition (WSDL, Web Services Description Language) pour décrire les caractéristiques et interfaces qui relient utilisateur et fournisseur. Le modèle reconnaît des mécanismes standard destinés aux processus d'identification, de sécurité et de récupération. Sa richesse fonctionnelle lui permet donc de prendre en charge des applications stratégiques complexes.

L'approche classique pour réaliser une symbiose REST/SOA consiste à ajouter un serveur Web frontal à une application SOA.

Le modèle RESTful a été conçu pour un accès utilisateur simple via un navigateur. Cette méthode de navigation via le langage HTML (HyperText Markup Language) s'est développée au point d'autoriser des échanges d'informations plus structurés en XML (eXtensible Markup Language), entre éléments de programme et pas uniquement entre utilisateurs. Pourtant, l'interface de base reste inchangée : les composants sont représentés par des URL (Uniform Resource Locator) et décodés au moyen de mécanismes DNS (Domain Name System) compatibles avec Internet.

On pourra soutenir que le couplage des composants est moins que contraignant ; il est inexistant. Sauf lorsque les utilisateurs eux-mêmes sont susceptibles de sélectionner des liens visuellement. Les services RESTful sont faciles à développer et à déployer, ils sont légers, leur hébergement et leur maintenance sont économiques, et ils constituent la solution idéale pour les applications en ligne typiques.

L'approche classique d'une symbiose REST/SOA consiste à ajouter un serveur Web frontal à une application SOA. Ainsi, les applications SOA sont directement prêtes pour Internet et accessibles au moyen d'outils de type navigateur/client léger. Cette approche est parfaite lorsqu'on souhaite privilégier la souplesse de composition d'applications de SOA. Toutefois, l'importance grandissante des clients légers, de la mobilité et de l'accès Web a conduit certains architectes à envisager d'intégrer davantage de concepts RESTful au sein même des applications.

Les clés d'une solution SOA RESTful

Chez les architectes d'applications, la définition des objets qui représenteront les ressources/éléments de traitement constitue la clé de la création d'une forme d'architecture SOA RESTful. Dans l'architecture REST, chaque objet est représenté par une URL, et l'utilisateur de l'objet est chargé d'inclure des informations d'état dans chaque message, de sorte que le traitement de l'objet s'effectue systématiquement sans état. Les objets trop complexes – dans la mesure où ils représentent des processus à plusieurs étapes – sont difficiles à coder dans un format RESTful, et leur utilisation nécessite des schémas de conception transformationnels ou d'autres mécanismes d'adaptation.

Dans une architecture SOA RESTful, la deuxième difficulté réside dans la gestion des processus de liaison et de composabilité. L'une des principales objections des entreprises à une solution SOA formelle (reposant sur SOAP) est que ce niveau de flexibilité en termes de découverte et de liaison n'est pas suffisamment utile pour en justifier la complexité. Les entreprises rapportent que la majorité des applications possèdent des composants relativement statiques. Si d'aventure des composants dynamiques sont introduits, ils représentent généralement les fonctionnalités exposées par une autre application, voire un autre utilisateur, via une interface de programmation d'application (API, Application Programming Interface) qui – ironie du sort – est souvent de type RESTful !

Les interfaces RESTful permettent de fournir des processus de découverte de composants fondés sur un annuaire dès lors que ce niveau de dynamisme est requis. Toutefois, de tels besoins peuvent être le signe qu'une approche hybride utilisant REST à l'avant-plan de l'application et SOA/SOAP en arrière-plan est justifiée.

Dépasser les inquiétudes

Certains architectes d'applications peuvent s'inquiéter de la sécurité des interfaces RESTful. Au sens strict, les deux architectures disposent des mêmes options de cryptage. Toutefois, SOA/SOAP offre au développeur un contrôle plus explicite de la sécurité. Il n'en demeure pas moins que les applications RESTful peuvent rendre obligatoires les connexions sécurisées, et que le développeur peut s'assurer de leur mise en oeuvre. Il est possible de vérifier qu'une sécurité est bien mise en place en testant des appels HTTP non sécurisés aux interfaces afin de s'assurer qu'aucune connexion n'est autorisée dans ce mode.

L'orchestration et la segmentation (threading) des processus métier sont parfois aussi pointées comme des sujets de préoccupation lorsqu'il s'agit de mettre en oeuvre une architecture SOA via des interfaces RESTful. Bien sûr, de nombreux protocoles de bus de messages prennent en charge l'usage d'interfaces RESTful (la prise en charge spécifique va dépendre à la fois du bus de messages et du langage de programmation choisi). Peut se poser le problème de garantir la mise en oeuvre de procédures de rétroaction en cas d'échec d'une transaction lié à la défaillance d'un composant.

Il n'existe aucun processus intermédiaire explicite REST ni aucun mécanisme spécifique permettant de garantir qu'un processus RESTful donné, dont l'exécution a abouti, puisse faire l'objet d'une rétroaction, pas plus que n'existent les informations nécessaires à cette opération. Il est relativement facile d'élaborer un mappage de processus dans un message RESTful et de le transmettre d'étape en étape, afin de remonter à la source d'une éventuelle défaillance. Toutefois, il peut s'avérer nécessaire de développer cette fonctionnalité, plutôt que de simplement recourir à un outil ou à une fonctionnalité standard.

La grande majorité des « services » mis en oeuvre aujourd'hui repose sur l'architecture REST et non sur le tandem SOA/SOAP, même si les entreprises font désormais confiance à l'architecture SOA formelle pour les applications stratégiques. Dans les applications où la gestion de la sécurité/des identités, la composabilité et la conformité constituent des paramètres absolument vitaux, il peut s'avérer difficile de remanier la structure en termes RESTful. Cependant, pour l'entreprise moyenne, la vraie question consiste à savoir si les composants applicatifs actuels exigent une architecture SOAP, ou s'ils sont accessibles via une approche RESTful.

Dès lors que l'architecture REST est disponible, elle offre une déploiement plus rapide, une intégration plus facile auprès des clients, fournisseurs et employés mobiles, et un paramétrage plus souple de l'IUG pour la prise en charge des utilisateurs. Même ses partisans en conviendront, l'architecture REST n'est pas parfaite, mais pour nombre d'applications SOA, elle constitue la meilleure solution.