SOA et EDA

SOA est sur toutes les lèvres. A tel point que trop de SOA peut parfois tuer le SOA :-). Certains responsables informatiques ont maintenant peur de l'entendre ou de le prononcer.

Je travaille actuellement sur les architectures d'intégrations et notamment celles autour des ESBs. La plupart des présentations que j'ai pu voir sur les ESBs les définissent comme une infrastructure permettant de "faire du SOA". "Faire du SOA" implique de mettre en oeuvre des architectures où un applicatif appelle un service d'un autre applicatif de manière synchrone (pour simplifier...). Cette démarche implique alors une dépendance en terme de disponibilité entre les 2 systèmes. Elle implique aussi de déporter les exigences en terme de temps de réponse de l'application consommatrice vers l'application qui fournit le service.

C'est normalement à ce moment que le responsable des applicatifs en production vous dit :"heuuu et comment je fais si je veux que mes applicatifs soit indépendants en terme de disponibilité pour pouvoir continuer à travailler si un d'entre eux crash?..."

EDA permet ce genre de fonctionnement. EDA, pour Event Driven Architecture, propose des échanges asynchrones de messages unitaires (ayant seul un sens métier au sein du SI) au fil de l'eau. Ce type d'architecture permet de rendre indépendant les applicatifs en terme de disponibilités et de performance, tout en offrant la possibilité de diffuser les messages au fil de l'eau dans le SI. La plupart des ESBs permettent de faire de l'EDA même si en général le focus est mis sur les partie SOA qu'offre le bus.

Je pense, et je crois que je ne suis pas le seul (enfin j'espère...), que ces 2 types d'architectures font partis d'un SI moderne.

Vous en pensez quoi???

Voici d'ailleurs un blog intéressant :
http://soa-eda.blogspot.com/
Le nom du blog est assez porteur de sens...