Architecture soa (architecture orientée services)

1.4.3 EAI

Les besoins de la fin des années 90 tendent vers une accélération des flux afin de décloisonner virtuellement les applications et de permettre des prises de décision plus rapides. L'EAI^6(*) apporte sa touche de simplification à l'architecture du SI, en fluidifiant les échanges d'informations, cette fois-ci au fil de l'eau, dans un mode évènementiel. Contrairement à l'ETL, l'EAI traite principalement de faibles volumes et n'opère que de légères transformations de données.

Illustration 7 : EAI : le plat de spaghettis semble plus ordonnancé et mieux distribué

De nouveaux concepts sont introduits tels que les messages en mode quasi-temps-réel, le workflow^7(*) et la prise en charge de ces messages dans une couche de transport appelée « Message Oriented Middleware » (MOM)^8(*) en mode asynchrone^9(*) ou Object Request Broker (ORB)^10(*) en mode synchrone11(*), ressemblant tous deux à une file d'attente. La première solution (MOM) offre l'avantage de pouvoir assurer une reprise d'activité propre en cas de panne réseau par exemple car le mode asynchrone est plus souple. Il permet à certaines applications de ne pas être disponibles au moment de l'alimentation du MOM.

1.4.3.1 Constitution de l'E.A.I.

La couche transport MOM

Le MOM fonctionne en mode « Publish and Subscribe » qui s'apparente à un mode d'abonnement où le bus d'échanges met les informations à disposition des applications abonnées. Les applications dites « publicatrices » ne font qu'alimenter ce bus sans avoir à connaître les applications « abonnées » à leur message. Le système d'échange présente l'avantage de la flexibilité, de la fluidité et de la robustesse. La qualité de service s'invite dans l'argumentaire des Editeurs d'EAI puisque de ce point de vue, les temps d'intégration d'un nouvel outil s'en trouvent diminués et que les flux sont davantage sécurisés. Mais le MOM reste un modèle d'échange point à point dans le sens où une application émettrice poste un message dans la file d'attente pour une et une seule application destinataire abonnée qui viendra, selon sa disponibilité, « consommer » ce message. Si le même message doit aussi être consommé par une autre application, alors il devra avoir été posté une seconde fois, d'où le risque d'un nouveau syndrome spaghetti.

Le Message Broker

C'est pour cela que le Message Broker, qui peut fonctionner en mode centralisé, trouve tout son sens dans l'architecture MOM. Il est constitué d'un hub^12(*) qui détient la connaissance des publicateurs et des abonnés. Aussi, un message devant être consommé par deux applications différentes, pourra n'être posté qu'une seule fois (principe de « content-based routing »). Ce Message Broker propose des services complémentaires permettant de simplifier la communication entre les applications.

* ⁶ EAI (Intégration d'applications d'entreprise) : architecture « intergicielle » permettant à des applications hétérogènes de gérer leurs échanges.

* ⁷ Workflow : décrit le circuit de validation, les tâches à accomplir entre différents acteurs d'un processus, les délais, les modes de validation, et fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche.

* ⁸ MOM (Message Oriented Middleware) : système de transmission de messages entre applications.

* ⁹ Communication asynchrone (Asynchronous Communication) : type d'échange non bloquant dans lequel une application envoie un message à l'autre sans attendre la réponse, afin que les applications puissent opérer indépendamment.

* ¹⁰ ORB : s'apparente à une tuyauterie permettant les échanges de messages entre objets.

* ¹¹ Communication synchrone : type d'échange bloquant dans lequel une application envoie un message à l'autre en attendant la réponse, de telle sorte que les applications opèrent en dépendance.

* ¹² Hub : point central où convergent les informations du système.