I.8.3 Middleware orienté
objet (Le MOO)
Pour permettre à différentes applications de
communiquer entre elles, il faut des règles et des formats communs
d'appels de services pour permettre aux différents objets de communiquer
entre eux car les composants peuvent être de natures différentes.
Tout d'abord ils peuvent être sur des machines différentes ayant
des OS différents. Ils peuvent aussi avoir été
conçus dans des langages différents.
Il existe trois modèles de composants objets qui sont
complémentaires et interopérable. Il s'agit du modèle
CORBA, des composant Java EJB et enfin de DCOM de Microsoft.
Ø Gestion d'applications distribuées :
Une fonction est sur une machine et collabore au sein de l'application
avec une fonction sur une autre machine ;
Ø Une vision très différente de
l'interopérabilité:
· Parfois accessible par plusieurs langages ;
· Parfois accessible par plusieurs plateformes ;
· Parfois les deux.
Ø Couplage fort (technique,
métier) ;
Ø Points forts
(Fiabilité ;Capacité d'intégrer les messages
et les transactions)
Ø Points faibles (L'extension
(scalability) est limitée).
I.8.4 Middleware orienté
message (MOM)
I.8.4.1 Définition
Les middlewares orienté messages sont des outils
permettant aux applications d'interagir en échangeant des messages de
manières asynchrone et fiable.
On l'a vu, les MOMs sont des middlewares, des outils
d'échange qui permettent à des applications de communiquer en
échangeant des messages. Une application « A » doit adresser
un message à une application « B », qui tourne
(peut-être) sur un serveur différent.
I.8.4.2 Descriptions
L'application « A » confie son message au MOM, qui
se charge de l'acheminer et de le remettre à l'application « B
».L'objet véhiculé par le MOM entre deux applications est
appelé message.Mais rien n'est imposé quant à ce que
représente ce message, sa taille, ou encore le format des données
qu'il véhicule.
Pour l'essentiel, ces questions ne concernent que
l'application « A » et l'application « B », qui doivent
partager un certain nombre de conventions, afin de se comprendre.
Le MOM, quant à lui, ne s'intéresse donc pas au
contenu du message, il ne fait que le transmettre, et il le remet au
destinataire sans y avoir apporté de changement.
I.8.4.3 Différences
a. MOM, EAI, ESB
À la différence d'un MOM, un outil d'EAI
(Enterprise Application Integration), est aussi en charge de réaliser
transformations sur lesinformations portées par les messages, afin
d'adapter les données del'émetteur aux formats
gérés par le destinataire.
Un EAI englobe donc les fonctionnalités du MOM, et y
ajoute des possibilités facilitant l'intégration des applications
au niveau des données transférées.
Dans un MOM, comme on l'a vu, les applications doivent parler
le même langage, tandis qu'un EAI au contraire prend en charge les
traductionsentre représentations différentes.
Un EAI est donc un middleware qui a comme principales
fonctions :
· L'interconnexion des systèmes
hétérogènes.
· La gestion de la transformation des messages.
· La gestion du routage des messages.
L'ESB, Enterprise Service Bus, est un concept plus ambitieux
encore, qui se présente comme le socle uniforme d'une architecture SOA
globale. Là où l'EAI peut prendre en charge des transformations
de formats permettant à une application A d'interopérer avec une
application B.L'ESB généralise le concept, en posant pour
principe qu'il suffit qu'uneapplication A soit interfacée à l'ESB
pour qu'elle puisse interopérer par son intermédiaire avec toute
autre application interfacée à l'ESB.
Et par ailleurs, la connexion à l'ESB n'est pas
exclusivement à base de messages, elle doit supporter une grande
diversité de modes d'échange et de protocoles.
b. EDA, Event Driven Architecture
Puisque nous évoquons quelques acronymes en vogue, il
faut parler aussi du concept EDA, « Event-Driven Architecture »,
architecture pilotée par les événements, qui est à
certains égards une alternative à l'approche SOA.
L'approche EDA part de l'idée que tout traitement est
d'une certaine manière exécuté en réaction à
un événement. Et bien sûr, tout traitement est par ailleurs
générateur d'événements.
Ainsi, la vente d'un produit est un événement,
qui induit un ensemble de traitements relatifs par exemple à la gestion
des stocks, à la comptabilité, à la logistique, à
la relation client, etc. Tout est événement, tout est
réaction à des événements, et il en va de
même pour nous-mêmes, êtres humains, qui agissent en
réaction à un ensemble de stimuli externes.
Dans l'approche EDA, la réaction à un
événement n'est pas un traitement synchrone. Elle peut avoir des
exigences de rapidité, mais elle est par essence asynchrone. Alors que
l'approche SOA, même si elle peut se décliner dans une logique
asynchrone, est malgré tout par essence une approche synchrone. Et bien
sûr, les MOMs sont le support naturel d'une approche EDA.
Un dernier acronyme à trois lettres pour la route: CEP,
pour « Complex Event Processing », traitement
d'événements complexes, consiste àidentifier, puis
traiter, des événements complexes à partir
d'unecombinaison d'événements simples. C'est donc un
conceptcomplémentaire à l'approche EDA, partant du principe qu'il
ne suffit pasde réagir à des événements
individuels, il faut être en mesure d'identifierdes
événements de plus haut niveau, comme résultante
d'événementsélémentaires. Par exemple: un ordre de
vente, plus un autre ordre devente, plus encore un ordre de vente...
égal une crise financière,événement complexe, s'il
en est.
| 
