LES ESB (ENTERPRISE SERVICE
BUS)
La définition de l'ESB permet de se rendre compte que
c'est l'environnement parfait pour appliquer SOA. L'ESB est le médiateur
: c'est une technologie informatique intergicielle permettant à des
applications hétérogènes d'interagir au travers de
services standards qu'elles mettent à disposition. Les principes sont la
découverte dynamique (notre annuaire de services), la
chorégraphie et l'orchestration de services (pas de coordinateur central
dans la chorégraphie, chaque service connaît les services qu'il
doit appeler) et la communication par messages. Les standards sont ceux des
services web (SOAP, WSDL, ...) mais aussi la norme JBI (ESB est une
implémentation de cette norme qui permet à des composants de
communiquer via des messages), les messages JMS (Java Message Services) que je
vais décrire plus tard, ... L'ESB permet de surveiller le trafic
(« monitoring », console d'administration, fichiers de log,
...), d'imposer une qualité de service (gestion des transactions, assure
la réception, permet de mettre en place des sécurités).
On peut voir l'ESB s'intégrer très bien en tant
que médiateur :
L'ESB se place en médiateur entre les fournisseurs et
les consommateurs de service.
Schéma simplifié d'un ESB (beaucoup de
possibilités sont offertes).
Il existe beaucoup de patterns d'intégration - le terme
français patron est peu utilisé - pour un ESB, qui modifient un
peu le schéma ci-dessus et le complètent. J'ai
détaillé ces patterns en annexe. Ils m'ont alors permis
d'identifier, pour chaque projet dont on m'a donné la documentation, le
pattern utilisé. J'ai d'ailleurs pu me rendre compte qu'un des projets
ne faisait pas non plus vraiment du SOA mais plutôt des Web Services sans
respecter l'architecture. Chaque pattern s'applique dans des conditions
particulières et tout est possible si l'architecture SOA est
respectée. Il est même possible, même si ce n'est pas
recommandé, d'avoir plusieurs ESBs sous certaines conditions.
Les ESBs sont devenus très importants dans
l'architecture SOA, ils offrent des possibilités qui deviennent
indispensables à toute architecture. Parmi ces possibilités, il
est possible de compléter SOA avec EDA (Event-Driven Architecture) qui
est l'architecture dirigée par les évènements.
EDA (EVENT-DRIVEN
ARCHITECTURE)
Un ESB permet aussi de faire de l'EDA qui est parfois vu
comme un mode d'implémentation asynchrone de SOA ou juste une extension
permettant de compléter l'architecture. Le fonctionnement est ici un peu
différent : nous avons été habitués au
« Request and Reply » (envoi d'une requête et
réception de la réponse) alors qu'ici le principe est
« Publish and Subscribe » (les informations sont
publiées et si on veut les recevoir, on s'y abonne).
Une application publie des évènements dans un
topic. Toutes les applications peuvent s'abonner à ce topic pour
recevoir les évènements quand ils sont publiés.
La publication est dynamique : si jamais il y a de
l'information à transmettre, elle est publiée et tout le monde
peut souscrire à ce service à n'importe quel moment.
Les messages sont envoyés par une application dans une
queue. Une autre application peut lire un message dans cette queue : elle
le consomme. (Point à Point)
Le format des messages échangés pour utiliser
cette fonctionnalité est, par exemple, JMS (Java Message Services). JMS
permet deux modes de fonctionnement : le « Publish and
Subscribe » - cela s'appelle un Topic -, et le « Send and
Receive » - la Queue, envoi et récupération de messages
-.
Les queues et les topics sont hébergés sur
l'ESB. Un message JMS peut contenir un objet java ou du texte (donc du XML ou
même des messages SOAP). Ce même message contient un en-tête
permettant d'ajouter des informations (durée de vie, queue ou topic de
retour de réponse, ...)
Pour comparer avec les Web Services appelés avec des
messages SOAP sur HTTP, on a, d'un côté les Web Services avec des
fichiers générés des 2 côtés pour faire le
lien entre les messages échangés, et de l'autre une queue ou un
topic faisant le lien :
· Web Service (HTTP)
Web Service
Skeleton
Stub
Client
· Queue (JMS)
Queue
Application
Application
En expliquant cette possibilité, on comprend que ce
qui est important est la conception du service. L'idéal serait de
proposer plusieurs moyens pour accéder au service selon la situation. On
peut imaginer un objet natif qui gère les achats et utilise des
applications de l'entreprise pour propager l'information. Cet objet peut avoir
des méthodes pour acheter, ajouter des produits au panier, donner les
informations de l'acheteur, etc. Appeler ces méthodes à un niveau
local ne pose pas de problème mais, comme évoqué dans la
définition des services, ce n'est pas une solution.
La solution est de fournir une méthode unique pour
ajouter un ordre d'achat contenant toutes les données
nécessaires. Cette méthode peut être décrite par le
biais d'une interface et accessible par diverses technologies. Le service ne
change pas, seulement le protocole de communication et le format des
données échangées. Au consommateur du service de choisir
le meilleur moyen d'accéder au service.
| 
