Les Esb Dans La Soa PDF

LIVRE BLANC
Comprendre et savoir utiliser

un ESB dans une SOA
http://blog.xebia.fr
http://www.xebia.fr
Copyright Xebia 2007

Xebia IT Architects SAS
10/12 Avenue de lArche
92419 Courbevoie Cedex
Tl : 01 46 91 76 16
Mail : info@xebia.fr
Comprendre et savoir utiliser un ESB dans le cadre dune SOA - Copyright Xebia 2007 Toute reproduction mme partielle interdite
Livre blanc
Comprendre et savoir utiliser un ESB dans une SOA

Les ESB (Enterprise Service Bus) visent, dune part assurer linterconnexion et dautre part grer la
mdiation des communications et des interactions entre services et applications dun SI. Quoique non
indispensables, ils nen demeurent pas moins une brique forte valeur ajoute dans le cadre dune mise en
place dune architecture oriente service (SOA) mature.
Nanmoins les ESB sont aujourd'hui victimes de leur succs et il est souvent difficile de dcrypter leur rle
exact.
L'objectif de ce livre blanc est de prsenter les fonctionnalits que l'on peut attendre d'un ESB et comment il
peut rpondre aux besoins d'adaptation inter-applications d'une SOA.
Table des matires

Intgration, SOA et ESBs..................................................................................................................................3
SOA et la problmatique d'intgration..........................................................................................................3
Les ESB, hritiers d'une grande famille d'outils d'intgration ......................................................................5
Rle et responsabilits d'un ESB dans une architecture oriente service .................................................9
A quoi sert un ESB ? ....................................................................................................................................9
Tour d'horizon des fonctionnalits d'un ESB..............................................................................................11
Les risques dans la mise en place dun ESB .............................................................................................15
Cas d'utilisation d'un ESB ..............................................................................................................................16
Couplage lche...........................................................................................................................................16
Composition / agrgation de services ........................................................................................................17
Gestion de version......................................................................................................................................18
Gestion de la QoS ......................................................................................................................................19
Intgration avec une solution d'orchestration.............................................................................................20
Mdiation intra-domaine et inter-domaines ................................................................................................21
Service Enablement : Exposition de service ..............................................................................................22
Conclusion .......................................................................................................................................................23
Intgration, SOA et ESBs
SOA et la problmatique d'intgration
La construction des systmes d'information s'est le plus souvent ralise de faon organique, chaque
domaine mtier btissant un sous-systme propre adapt ses besoins et adoss des technologies
htrognes, rarement interoprables. Rapidement, et pour rpondre aux besoins croissants
d'informatisation des procdures, les problmatiques d'intgration de systmes ont merg, et avec elles
deux questions centrales :
Comment dclencher, en rponse un vnement dans un sous-systme donn, un traitement

dans un autre sous-systme qui lui est tranger ?
Comment assurer la consistance et la propagation des donnes entre plusieurs sous-systmes ?
Comme nous le verrons plus loin, un certain nombre de solutions techniques ont t trouves pour rpondre
ces questions.
La mise en uvre de ces solutions d'intgration s'est le plus souvent faite de faon opportuniste, pour
rpondre aux besoins immdiats de telle ou telle application. A mesure que ces solutions ad hoc ont t
mises en uvre, les problmatiques de gouvernance ou de pilotage global sont apparues :
Les flux se sont multiplis, parfois de faon redondante, ainsi que les chanes de liaison techniques ;
Le couplage croissant des systmes amen son lot de problmes, synthtiss par le concept
d'effet spaghetti ;
Les organisations ont t confrontes des dfis organisationnels nouveaux : Si les chanes de
responsabilits taient claires pour chaque sous-systme mtier, quid des liaisons entre ces
systmes ?
Ces dfis de l'intgration l'chelle du SI ont t adresss avec plus ou moins de succs par les DSI au
travers de chantiers d'urbanisation et de schmas directeurs informatiques. Rcemment, le concept
d'Architecture Oriente Service (SOA) a permis de cristalliser les bonnes pratiques en matire d'urbanisation
et d'intgration du SI et, en les nommant, de fournir un horizon aux grands projets de rationalisation et
d'intgration.
Il n'est pas dans le primtre de ce document de prsenter en dtail les principes d'une SOA ce sujet a t
longuement trait par ailleurs. On retiendra cependant quelques lments cls de la mise en uvre d'une
Architecture Oriente Services :
SOA n'est pas une technologie, ni une recette, encore moins un produit. C'est une faon de penser
et de concevoir le Systme d'Informations. A ce titre, les enjeux organisationnels de sa mise en
uvre sont souvent des dfis autrement plus difficiles relever que les enjeux techniques qui la
sous-tendent.
3 / 23
Comme son nom le suggre, l'lment cl de SOA est le Service. Un Service est un composant
logiciel distribu, exposant les fonctionnalits forte valeur ajoute d'un domaine mtier. D'un strict
point de vue technique, un service possde les caractristiques suivantes :
Il propose une interface connue et prenne.

Il est logiquement unique (c'est -entre autre- ce qui le distingue d'un composant, qui peut tre
instanci plusieurs fois).
Il est invocable distance (c'est une notion classique des architectures distribues).
Il est localisable ( terme, il existe donc un annuaire permettant aux clients de le localiser).
Chaque domaine mtier est responsable des services qu'il propose ; il est propritaire des donnes
et doit se conformer au contrat de service qu'il a publi ; il est en charge de la maintenance et de
l'volution du service. Un service n'a de sens que s'il apporte une valeur mtier l'organisation.
Quelle que soit la mthode choisie, la mise en uvre d'une SOA ncessite un pilotage transverse,
articul autour des besoins mtiers. La construction de l'architecture doit se baser sur les
problmatiques mtier qu'elle tend rsoudre ; les besoins techniques sont infods aux besoins
mtier.
La formalisation du paradigme SOA a clairement eu le mrite de replacer le mtier au centre de l'architecture

du SI. Mais SOA reste aussi un projet d'intgration grande chelle. Comment ds lors viter les chausse-
trappes des grands projets d'architectures distribues ou intgres, et en particulier le couplage technique
et fonctionnel entre consommateurs et fournisseurs de services ?
Le couplage technique impose au consommateur de connatre le protocole d'change du fournisseur c'est

le propre, nous le verrons plus loin, des middlewares network centric. A grande chelle, un tel couplage
complique, voire interdit l'volution du socle technique, et risque de figer le SI dans une inertie sclrosante.
A la fois plus subtil et plus pernicieux, le couplage fonctionnel impose au client de connatre le format
d'change du fournisseur. Toute volution du fournisseur a un impact potentiel sur chacun des
consommateurs. Mal gre, cette dpendance peut conduire de vritables verrous fonctionnels dans le
Systme d'Informations interdisant toute volution ou, plus srement, augmentant de faon exponentielle le
cot de ces volutions.
Les ESB nous le verrons dans ce document offrent une solution technique ces problmatiques. Mais
rptons-le : une SOA est avant tout un chantier mtier, dont les dimensions techniques sont subsidiaires.
En cela, un ESB n'est ni ncessaire ni suffisant la mise en uvre d'une architecture oriente
services.
Nouveau Graal des Systmes d'Information, les Architectures

Orientes Services sont, dans leur dimension technique, des projets
d'intgration grande chelle. En cela, elles doivent s'appuyer sur
une solution d'intgration robuste et souple, permettant d'viter les
cueils du couplage technique et fonctionnel.
4 / 23
Les ESB, hritiers d'une grande famille d'outils d'intgration
Afin de bien comprendre le rle des ESB dans une architecture oriente service, il semble opportun de
revenir rapidement sur l'histoire des solutions d'intgration.
Comme nous le mentionnions plus haut, les problmatiques d'intgration peuvent tre synthtises par deux
questions primordiales :
Comment assurer la consistance et la propagation des donnes entre plusieurs sous-systmes ?
Comment dclencher, depuis un sous-systme donn, un traitement dans un sous-systme tiers ?
Assez naturellement, deux grandes catgories de solutions sont apparues : les outils d'ETL, permettant de
synchroniser de faon diffre, et souvent nuitamment, les donnes de plusieurs systmes ; et les solutions
dites middleware, destines assurer la communication temps rel entre systmes htrognes.
Les outils ETL
Les outils ETL rpondent exclusivement la premire question. Ils assurent la synchronisation, la
consolidation et la propagation des donnes entre sous-systmes disparates. Schmatiquement, ils extraient
les donnes du systme matre pour mettre jour, aprs un transcodage adquat, les systmes fils.
Bien qu'ils puissent fonctionner au fil de l'eau, les outils ETL sont plutt destins aux traitements de masse
en temps diffr (batch) ils sont au demeurant apparus l'origine pour assurer le chargement des
datawarehouses.
Leur relative simplicit de mise en uvre est leur plus grande force. Ils autorisent en outre un premier niveau
de rationalisation du SI, en dsignant des propritaires pour les donnes matres. Ces rfrents sont
d'ailleurs l'un des pr-requis critiques pour la mise en uvre d'une architecture oriente service (SOA).
Coupls des formats pivots, les outils ETL permettent de surcrot d'viter les cueils des liaisons point--
point et du couplage fonctionnel trop troit entre systmes.
Malheureusement, l'approche ETL reste exclusivement centre sur les donnes, et n'offre qu'une
smantique mtier rudimentaire. Elle choue en consquence rsoudre la seconde quation du diptyque,
celle de l'intgration de processus, et plus encore relever les dfis des architectures orientes service.
Les middlewares network centric
Comme leur nom le suggre, les solutions middleware fournissent quant elles une infrastructure technique
assurant la mdiation entre deux ou plusieurs systmes. Leur rle historique est d'assurer le transport d'un
message d'un sous-systme vers un autre, avec un niveau de couplage plus ou moins important.
Apparus ds le dbut des annes 80, les MOM (Message Oriented Middleware) ont une smantique
asynchrone : le client construit un message et le transmet au middleware, qui se charge de le router vers le
ou les systmes cibles. La communication est scinde en deux, vitant le couplage technique des
participants. La garantie de livraison du message est confie au MOM.
5 / 23
Pendant longtemps, cependant, les MOM sont rests des solutions largement propritaires, forant chaque
partie connatre les modalits d'interfaage avec le broker, et limitant la capacit d'intgration aux
environnements et langages supports par l'diteur de la solution JMS, le standard de messaging Java, n'a
lev que partiellement cette contrainte, et CosNotification, le service de notification CORBA est rest
confidentiel.
Les MOM offrent en outre des capacits de routage souvent limites, qui obligent des efforts de
configuration importants chaque route doit tre explicitement dfinie -, rendant leur mise en uvre difficile
grande chelle.
Les ORB (Object Request Broker), appuys par la spcification CORBA, ont propos ds le dbut des
annes 90 une approche plus riche et plus ambitieuse.
Plus riche en ce sens que la spcification CORBA supporte virtuellement tous les langages et enrichit
l'architecture d'intgration de services techniques de haut niveau, en particulier la localisation, les
transactions et la scurit ; CORBA propose une smantique d'invocation point--point synchrone ou
asynchrone, utilisant un protocole et un encodage standardiss ; CosNotification, le service de messaging
CORBA, spcifie un MOM interoprable.
Plus ambitieuse, ensuite, puisque l'OMG, l'organisme de tutelle de la spcification CORBA, envisageait rien
moins que fournir une architecture d'intgration universelle, allant jusqu' dfinir un ensemble de standards
verticaux destins aux acteurs institutionnels et industriels dsireux d'assurer l'intgration de leurs systmes
(banque, industrie automobile, sant, etc.). Sans entrer dans le dtail, le relatif chec de CORBA prend
racine dans sa complexit de mise en uvre et, plus srement encore, dans les dfauts d'interoprabilit
des diffrentes implmentations, trahison vidente des promesses du standard.
Malgr leurs qualits respectives, MOMs et ORBs restent des solutions trs techniques ; ils permettent
certes la fois la propagation des donnes et l'intgration des traitements, mais la smantique des
changes y reste fondamentalement point--point : le client doit connatre le format du message qu'il
adresse aux systmes tiers ; ce couplage fonctionnel des systmes devient rapidement un cauchemar pour
la maintenance et l'exploitation, en particulier s'il est tendu l'ensemble du SI ; enfin, la question de
l'interoprabilit n'est pas dfinitivement rsolue, en particulier lorsque le systme cible est trs ferm on
pense plus spcifiquement aux ERP et aux Mainframes.
Les EAIs
Pour faire face ces enjeux, une nouvelle catgorie de solutions middleware est apparue : les EAI
(Enterprise Application Integration). Tirant parti des deux prcdentes approches, les EAI proposent une
architecture hub and spoke opposer l'architecture network centric des ORBs et MOMs -, dans laquelle
un composant central assure la mdiation physique entre le client et sa cible. Ce composant central prend
son compte l'ensemble des problmatique techniques de bas niveau (localisation, disponibilit, cache,
communication, transcodage, interoprabilit au moyen de connecteurs spcialiss, audit, traces, scurit
voire transactions). A l'instar des ETL, ils sont de surcrot en mesure d'assurer la transformation des donnes
afin de limiter le couplage fonctionnel entre les systmes, et d'appliquer des rgles de routage sophistiques.
A ce rle de super-connecteur et de mdiateur, les diteurs ont souvent ajout celui d'orchestrateur : les EAI
peuvent hberger des processus mtier de haut niveau, agrgeant des traitements raliss dans plusieurs
sous-systmes.
6 / 23
Malgr leurs videntes qualits, les solutions d'EAI souffrent de leur caractre trs propritaire :
Le protocole utilis pour les changes et le transport des messages au sein d'un EAI est
propritaire.
La technologie interne aux EAI est propritaire. Ainsi, laccs aux applications se fait par
lintermdiaire de connecteurs encore largement spcifiques chaque diteur malgr des tentatives
1
de standardisation comme JCA dans le monde Java (ces connecteurs restant souvent trs
onreux).
Les formats et encodages de donnes utiliss dans les EAI sont propritaires.
Outre les problmes de cots, ce verrouillage est souvent vcu, parfois injustement, comme un risque
excessif concernant un composant aussi stratgique.
Plus perturbant encore, la multiplication des fonctionnalits des solutions d'EAI a brouill leur rle ; en
mlangeant les genres mdiation et orchestration -, les EAI sont devenu une brique trop complexe
recouvrant trop de responsabilits dans le SI. Ainsi, un grand nombre de projets de mise en uvre d'EAI ont
t douloureux et beaucoup plus long que prvu, ne tenant au final pas leurs promesses en terme de retour
sur investissement (ROI).
Les ESBs
Les ESB sont les hritiers directs des EAI il suffit de consulter la liste des principaux diteurs d'ESB pour
s'en convaincre : Bea, Tibco, Oracle, IBM, etc. sont prcisment des acteurs de l'EAI.
Reprenant les caractristiques architecturales des solutions d'EAI, les ESB se concentrent sur les fonctions
d'inter-connexion et de mdiation, et s'appuient pour cela sur un ensemble de standards parmi lesquels :
Les Web Services pour grer les communications synchrones.

XML pour dfinir les formats des messages
2
JMS pour adresser la communication asynchrone avec les MOM.
JCA pour la connexion aux progiciels et systmes exotiques (ERP, CRM, Mainframes, etc.)
EAI et ESB sont trs frquemment opposs par les analystes. Dans les faits, les produits d'EAI n'existent
quasiment plus. Ils se sont transforms en plusieurs produits qui en reprennent les fonctionnalits : d'une
part les ESB pour la mdiation et d'autre part les solutions de type BPM pour l'orchestration des processus.
Certains produits continuent de proposer les deux fonctionnalits mais elles restent bien dissocies.
1 JCA : Java Connector Architecture.

2 JMS : Java Message Service.
7 / 23
Figure 1 - Historique de l'intgration
Les ESB sont aujourd'hui la technologie d'intgration et de mdiation

inter-applicative privilgie pour la mise en uvre d'une architecture
oriente service. Mais ils restent avant tout une solution technique
lgante et sophistique aux problmatiques plus anciennes de
l'intgration inter-applicative. Leur utilisation ne garantit en rien le
succs ni mme la ralit de la mise en uvre d'une SOA.
Dans la suite de ce document, nous nous attacherons circonscrire le rle des ESB dans la mise en place
d'une architecture oriente service, et prsenter quelques architectures types rpondant certaines des
problmatiques techniques de ce chantier.
8 / 23
Rle et responsabilits d'un ESB dans une architecture oriente service
A quoi sert un ESB ?

D'un strict point de vue technique, le rle d'un ESB se rsume la connexion et la mdiation entre les
services et applications du Systme d'Informations.
A ce titre, ses principales responsabilits sont les suivantes :

Rconcilier des mondes htrognes, l'aide de standards d'interoprabilit ou de connecteurs
spcialiss c'est le rle classique d'un middleware d'intgration.
Dcoupler consommateurs et fournisseurs de services : Un consommateur ne connat que
l'ESB et ne connat ni les formats ni les protocoles d'change spcifiques utiliss par le fournisseur
du service.
Agrger des services de niveau N afin de construire des services de niveau N+1. Si l'agrgation
est complexe, ou ncessite des structures de contrle du flux d'excution, un moteur d'orchestration,
1
reposant par exemple sur le langage BPEL , est mis contribution.
Tracer les messages qui transitent. Devenant une zone de passage incontournable, lESB joue un
rle fondamental dans la traabilit et le monitoring des traitements. Une telle fonctionnalit peut
2
tre fournie par l'ESB ou par une solution tierce adressant galement les problmatiques de SLA ,
3 4
QoS , BAM , etc.
Le rle de mdiateur des ESB peut devenir plus large encore :
Exposer des services dapplications qui ne supportent pas nativement cette fonctionnalit, tels les
Mainframes ou certains progiciels.
Mutualiser les accs certaines applications afin de mieux grer les ressources, de contrler la
charge ou d'appliquer certaines rgles de scurit ou de priorit, etc.
Minimiser les cots des connecteurs legacy en mutualisant les licences. Ainsi dployer un seul
connecteur sur un ESB savre souvent moins coteux que de dployer ce mme connecteur sur
chaque application cliente (CICS Transaction Gateway, Connecteur SAP, etc.).
Implmenter un systme de cache permettant de dcharger certaines applications.
1 BPEL : Business Process Execution Language.

2 SLA : Service Level Agreement.
3 QoS : Quality Of Service.
4 BAM : Business Activity Monitoring.
9 / 23
L'une des difficults majeures de la mise en place d'une architecture oriente service est la gestion du
changement. Par nature, les diffrents lots du systme d'information ont des cycles de vie distincts, certains
tant soumis des rythmes d'volution soutenus quand d'autres n'voluent presque jamais. La gestion des
montes de version dans les architectures intgres est l'un des cueils sur lesquels ont chou un grand
nombre de projets d'intgration grande chelle.
Le rle de mdiateur technique des ESB peut tre mis contribution pour limiter l'impact des changements,
en "virtualisant" certains services, ou certaines versions de services, pendant les phases transitoires nous
analyserons plus spcifiquement cette approche dans la troisime partie de ce document.
Au del du rle classique d'un middleware d'intgration, l'ESB doit

tre considr comme un vritable tampon qui permet d'intgrer
toutes les applications en tenant compte de la complexit, du cot, de
la monte en charge et du cycle de vie des briques du SI.
10 / 23
Tour d'horizon des fonctionnalits d'un ESB
Afin de tenir pleinement son rle, un ESB doit possder un certain nombre de caractristiques et de
fonctionnalits dont nous vous proposons de faire l'inventaire dans les sections suivantes.
Adaptation aux environnements htrognes
L'ESB apporte une couche dabstraction vis vis des technologies utilises dans le SI et doit en
consquence s'adapter aux protocoles et aux formats d'changes des applications qui le composent. Par
exemple, un ESB :
Ne dpend pas d'un systme d'exploitation ou d'un langage.

Supporte autant de standards que possible, dont les Web Services, XML, JCA (et dans l'avenir
1 2 3
SCA / SDO et / ou JBI ).
Permet d'exposer les services de manire uniforme quelque soit la technologie sous-jacente.
Utilise XML (ou SDO) comme langage standard de reprsentation et de traitement des donnes.
Offre un panel ouvert de connecteurs spcialiss vers les diffrentes briques du SI (MainFrames,
application propritaire, progiciel, etc).
Mdiation et routage
La mdiation est la principale valeur ajoute d'un ESB. Dans ce domaine, il doit donc proposer une
smantique riche, susceptible de fiabiliser et de simplifier les changes, tout en offrant une grande souplesse
de mise en uvre. Voici les principales fonctionnalits que l'on peut attendre d'un ESB en matire de
mdiation et de routage :
Support de diffrentes smantiques d'change de messages (synchrone requte-rponse ,

asynchrone point--point, asynchrone selon le modle publication-souscription )
Gestion de rgles de routage sur les messages.
Mcanismes de gestion de la priorit des messages.
Services de transformation et de conversion de messages (ex : XML <-> EDI, etc).
Manipulation des messages (enrichissement, transformation, combinaison, dcoupage).
Validation des donnes entrantes ou sortantes.
Gestion de versions de services de faon transparente (systmes voluant des rythmes
diffrents).
1 SCA : Service Component Architecture.

2 SDO : Service Data Object.
3 JBI : Java Business Integration.
11 / 23
Management, Monitoring, Contrat de service
tant un point central, lESB doit permettre le suivi et la fiabilisation des changes qui transitent en son
sein grce notamment :
La garantie de livraison des messages tout en conservant les messages non-consomms

(application indisponible, chec d'une transaction ...).
Des fonctionnalits permettant de suivre les traitements effectus et les messages reus.
Une gestion de la scurisation des services (authentification, autorisation, confidentialit et audit).
Contrle des SLA et aptitude modifier le comportement du bus (priorits ...) pour assurer ces SLA
Du cot des standards
L'ESB est le successeur de l'EAI, quil amliore notamment grce la standardisation croissante de ses
diffrentes fonctionnalits.
Les tentatives de standardisation actuelle couvrent les besoins suivants :
Format des donnes.

Transformation des donnes.
Exposition de services.
Accs aux brokers de messages.
Accs aux applications.
Architecture des composants.
Pour le format des donnes, le standard incontournable est XML. Ce langage offre la possibilit de dfinir
des schmas (XSD) qui contraignent la structure les documents XML et permettent de valider les formats
d'change.
Un autre standard est apparu rcemment : SDO. Ce standard a t initi par IBM et BEA puis support entre
autres par Oracle, Sun et SAP. SDO n'est pas standard d'change, mais un modle de programmation
permettant de manipuler de faon unifie des graphes de donnes dconnects d'origine quelconque
Web Service, bases de donnes, annuaires, etc. SDO autorise la manipulation statique (fortement type) ou
dynamique (faiblement type) des donnes, et a t conu pour tre support par plusieurs langages de
programmation (il existe aujourd'hui pour java et C++).
SDO nest pour linstant pas trs rpandu dans les solutions du march.
XSLT et XQuery sont les standards de transformation associs XML. Mme si la transition est longue,
XQuery supplante petit petit XSLT en raison des nombreux avantages qu'il offre dans la dfinition des
rgles de transformation.
12 / 23
Les services reprsentent, bien videment, le cur d'une SOA. Il est donc logique de trouver des standards
concernant lexposition et linvocation de services. Le premier, et le plus important de ces standards, est celui
des Web Services (WS).
Attention : Mme si SOA, ESB et Web Services sont intimement lis, les Web Services ne sont pas le
seul moyen de d'exposer des services notamment dans le cadre d'environnements techniques
homognes.
Le standard Web Service entend fournir, l'instar de CORBA, une technologie unifie pour dcrire et
invoquer des services, quelque soit leur localisation physique ou leur technologie d'implmentation.
Le cur des Web Services est constitu des standards SOAP et WSDL. WSDL permet la description des
services offerts par le Web Service (1er niveau de contrat de service) et SOAP dfinit le protocole dchange
entre un client et un fournisseur de service, le plus souvent au dessus du protocole HTTP.
Il existe un grand nombre de standards dans la sphre des Web Services, souvent dsigns standards
WS-* . Citons en particulier WS-Security, qui permet de scuriser les changes XML (Authentification,
Signature & Cryptage). Son adoption par le march nest pas encore flagrante malgr son support croissant
dans la plupart des solutions d'diteurs.
Le monde WS souffre nanmoins du manque de rigueur des spcifications et des agendas divergents des
principaux acteurs qui n'hsitent pas tendre le standard pour proposer des fonctionnalits propritaires,
souvent au dtriment de l'interoprabilit on pense en particulier Microsoft.
Ces problmes d'interoprabilit qui, on s'en souvient, ont t fatals CORBA -, ont conduit la cration
d'un organisme ddi : la WS-I pour Web Services Interoperability Organization. Elle propose un "Basic
Profile" qui regroupe un ensemble de recommandations d'utilisation des standards suivre (sic) pour viter
les cueils lis au manque d'interoprabilit des implmentations.
La plateforme Java/JEE fournit un certain nombre de standards additionnels destins faciliter les changes
entre diffrents sous-systmes.
Cest le cas de JMS qui offre un moyen standard daccder la plupart des MOMs du march. Ce standard
a t trs largement adopt par les diteurs (IBM, Bea, Tibco, Oracle, Sonic Software, etc.).
Reprenant les principes de JDBC pour les bases de donnes, le standard JCA (Java Connector Architecture)
dfinit une interface programmatique unifie pour accder des applications tierces quelconques. Plusieurs
diteurs se sont lancs sur le march des connecteurs JCA. Il est donc facile de trouver des connecteurs
pour la plupart des applications courantes du march (SAP, Siebel, PeolpeSoft, CICS, etc.).
Dautres voix de standardisation sont en cours. La plus notable concerne la normalisation de la notion de
composant. On citera entre autre SCA : Service Component Architecture.
A lire sur ce sujet : "Introduction SCA" sur le blog de Xebia France :
http://blog.xebia.fr/2007/04/11/introduction-a-sca-service-component-architecture/
1
Citons enfin JBI , standard propos par Sun pour standardiser intgralement l'architecture interne des ESB
autour de XML et des Web Service.
1 JBI : Java Business Integration

13 / 23
Le monde de l'intgration d'applications fourmille dsormais de
standards sur lesquels peuvent s'appuyer les ESB. La maturit de ces
standards n'est pas toujours satisfaisante, et leur usage n'est pas la
garantie d'une intgration sans douleur.
Synthse des fonctionnalits
Le tableau suivant synthtise les principales fonctionnalits que l'on peut attendre d'un ESB.
Connectivit Supporte de multiples protocoles de transport synchrone ou

asynchrone. Il faut voir l'ESB comme un "super-connecteur". Son rle
est de se connecter tout type de ressources ou fournisseurs de
services. C'est grce cela qu'il permet une exposition en couplage
lche de fournisseurs de services.
Routage Permet d'effectuer des routages de message bass sur des rgles (de
contenu, de contexte, etc). Idalement ce routage s'appuie sur un
annuaire, sur un registre de services et ventuellement sur un moteur
de rgles.
Mdiation Adapte le format des messages, le protocole, effectue des

transcodifications entre l'appelant et l'appel.
Exposition de services Transforme en service(s) un composant ou un traitement d'une

application qui ne le peut pas facilement.
Agrgation simple de services Effectue des agrgations simples de services de niveau N pour
construire des services de niveau N+1. Si l'agrgation est complexe on
prfrera utiliser un moteur d'orchestration.
Traitement d'vnements Permet la cration des rgles de corrlation et de jointure

complexes d'vnements.
Contrat de service Permet la dfinition des contrats de services : SLA, niveau de QoS,
gestion des priorits, scurisation des messages (signature et
cryptage), garantie de la livraison et de l'intgrit des messages.
Supervision et audit Offre des fonctions d'audit, de traabilit, de mesure, d'administration et

d'exploitation qui permettent le suivi des traitements. Selon la qualit de
l'implmentation, cette fonctionnalit sera dlgue un outil tiers.
14 / 23
Les risques dans la mise en place dun ESB
Un ESB occupe un rle central dans la mise en place de SOA. Nanmoins, positionner un ESB au sein de
l'infrastructure du SI nest pas synonyme daboutissement. La dmarche, la mthode et l'organisation mise
en place jouent un rle tout aussi dterminant.
La mise en uvre d'un ESB dpend du niveau de maturit d'une SOA. Lutilisation dun ESB n'est pas
ncessaire au dmarrage d'une SOA. Sa mise en uvre simpose aprs une rflexion plus large au niveau
du SI. Lutilisation dun ESB se justifie essentiellement dans le cadre d'invocations inter ST (Systmes
Techniques) sur un SI technologiquement htrogne.
Un ESB seul ne permet pas de mettre en place du BPM ou du BAM. L'ESB prendra en charge l'agrgation
de services ou l'enrichissement de donnes mais il ne faut pas le considrer comme un orchestrateur de
processus. Pour cela, il est prfrable dutiliser une vritable solution d'orchestration. Certains diteurs
runissent dans une seule et mme suite les deux fonctionnalits.
Si l'architecture en place est complexe et mal matrise, l'ajout d'un ESB napportera pas de relles solutions.
Il risque mme de devenir un point critique, mettant en exergue tous les problmes et incohrences du SI
un seul et mme endroit. Comme voqu prcdemment, la dmarche, la mthode, l'organisation et
l'implmentation des briques dune SOA sont tout aussi importantes.
Un autre travers dans la mise en place dun ESB est dembarquer trop de mtier dans les mdiations quil
propose. Le mtier terme risque de se perdre entre lESB et lapplication cible. Il peut en rsulter une plus
grande complexit dans les volutions du mtier et dans la connaissance et le recensement des
fonctionnalits. Afin dviter ce phnomne, il faut garder en-tte que les mdiations dveloppes dans lESB
doivent tre majoritairement phmres. Leur but est de permettre aux applications dvoluer de manire
indpendante mais les fonctionnalits mtiers embarques dans lESB doivent tre rintgres dans les
applications concernes.
De part sa position centrale, lESB peut aussi devenir un goulet

dtranglement. Plus les mdiations sont complexes plus les pertes
de performances peuvent tre prononces.
15 / 23
Cas d'utilisation d'un ESB
Couplage lche
Problmatique
Comme voqu prcdemment, le couplage technique ou fonctionnel est l'un des risques les plus critiques
lors de la mise en uvre d'une architecture oriente service.
Le service invoqu peut tre expos dans une autre technologie, utiliser une autre reprsentation des
donnes, tre asynchrone ou en cluster, etc. LESB va prendre en charge ces adaptations pour librer
lapplication appelante des adhrences avec lapplication quelle appelle. Le problme dadhrence est bien
sur report dans lESB mais on considre quil est plus facile et plus rapide deffectuer des modifications
dans lESB que dans les applications du SI.
Principe de mise en uvre
Figure 2 - Cas d'utilisation d'un ESB : Couplage lche
Les responsabilits de l'ESB sont ici les suivantes :

Exposition : Le consommateur ne connat que l'ESB. Il invoque le service que ce dernier lui
expose. Cette invocation se fait sur un protocole et avec un format de donnes qui sont indpendant
du fournisseur de service.
Routage : L'ESB dtermine le fournisseur de service invoquer (ventuellement en s'appuyant sur
un registre ou annuaire de services).
Transformation : l'ESB ralise une mdiation de format vers celui pris en charge par le fournisseur
de service.
Invocation : C'est l'ESB qui invoque le fournisseur de service.
16 / 23
Composition / agrgation de services
Problmatique
La composition peut s'avrer ncessaire quand lapplication qui fournit les primitifs mtiers ne peut pas
exposer facilement ou rapidement des services conformes la dfinition mtier qui en a t faite.
Principes de mise en uvre
Figure 3 - Cas d'utilisation d'un ESB : Composition / agrgation de services
L'ESB expose un service virtuel qu'il construit par composition ou agrgation de plusieurs autres services.
Il sagit ici d'un assemblage simple de service, et non d'orchestration ou de processus.
17 / 23
Gestion de version
Problmatique
Comment limiter l'impact d'une monte de version d'un service dans une architecture intgre, quand un
nombre quelconques d'applications dpendent de la version courante de ce service ?
Ou, l'inverse, comment dployer en avance de phase une application cliente d'une version d'un service non
encore publie ?
Principe de mise en uvre
Figure 4 - Cas d'utilisation d'un ESB : Gestion de version
La gestion de version permet de faire voluer diffrents systmes des rythmes qui leur sont propres.
Plusieurs situations peuvent se prsenter :
Les versions sont incompatibles entre elles (il nest pas possible deffectuer une transformation vers
la version la plus rcente) : le choix d'une version se fait par routage.
La nouvelle version est une extension compatible avec la version prcdente : LESB effectue
lappel vers la nouvelle version en appliquant une transformation du format dentre, du format
de sortie ou des deux formats. Ceci vite de maintenir dans lapplication cible deux versions dun
mme service.
18 / 23
Gestion de la QoS
Problmatique
La QoS d'un service est considre comme un ratio entre son temps de rponse moyen et la fracheur des
donnes qu'il manipule (la QoD : Quality of Data).
L'ESB est en mesure (en s'appuyant ventuellement sur un moteur de rgles) de dterminer quelle
implmentation invoquer en fonction de la QoS dsire.
LESB pourrait aussi tre utilis pour de la "golocalisation" de services. Imaginons un service qui soit
dploy x fois dans diffrentes rgions ou diffrents pays. LESB peut dterminer partir du message qui
transite quel est le service le plus appropri.
Figure 5 - Cas d'utilisation d'un ESB : Gestion de la QoS
Il existe deux implmentations du mme service :
L'implmentation A est au plus proche des donnes mtiers qu'il manipule (le rfrentiel). De ce fait
il travail avec des donnes fraches (mises jour en temps rel). En revanche, son loignement de
l'ESB implique un temps de rponse long.
L'implmentation B est au plus prt de l'ESB. Les temps de rponse sont donc trs courts. En
revanche, il ne travaille pas avec le rfrentiel de donnes mais avec un cache mis jour chaque
nuit. Les donnes qu'il manipule peuvent donc potentiellement tre primes.
19 / 23
Intgration avec une solution d'orchestration
Problmatique
Comment dployer un workflow complexe, hbergeant les processus mtier de trs haut niveau ?
Principes de mise uvre
Figure 6 - Intgration avec une solution d'orchestration
Pour viter de lier trop fortement lorchestrateur de processus avec les services quil appelle, il est
recommand dinsrer un ESB qui joue encore une fois le rle de mdiateur.
Exemples :
Il convertit les donnes changes au format dfini par la conception du processus (alignement
avec les besoins mtiers)
Il peut exposer tous les services avec la mme technologie pour simplifier la ralisation du
processus.
Il cre un nouveau service en agrgeant deux services existants (ce nouveau service sera
ventuellement rintgr ultrieurement dans une des briques du SI l'occasion d'une phase de
rationalisation)
20 / 23
Mdiation intra-domaine et inter-domaines
Problmatique
Comment grer un ESB quand plusieurs domaines mtiers, fortement autonomes, l'utilisent pour intgrer
leurs applications ?
Les diffrents domaines dune

organisation sont amens
changer les uns avec les autres.
Ces domaines correspondent des
quipes diffrentes, des plannings
diffrents voire des budgets
diffrents. Lintroduction dun ESB
aux frontires des domaines permet
de dcorrler et de dcoupler les
appels entre ces diffrents
domaines. Les domaines peuvent
voluer leur vitesse avec leur
technologie en suivant leurs propres
contraintes et ventuellement avec
leur vision des donnes mtiers
(bien quune vision unifie des
donnes au niveau du SI, lorsqu'elle
est possible, simplifie grandement
les problmes de communication).
Figure 7 - Mdiation intra-domaine et inter-domaines
De mme lors dchange B2B, un ESB peut tre plac comme douanier entre les applications internes et
les applications des partenaires. LESB va grer encore une fois la conversion des protocoles, des formats
de donnes, centralis les aspects scurit et traabilit dans les changes.
21 / 23
Service Enablement : Exposition de service
Problmatique
Intgrer les applications existantes introduit bon nombre de problmatiques. Certains types d'application ne
peuvent pas exposer facilement des services (Mainframe, CICS, AS/400, etc.), d'autres offrent des cots de
dveloppement trop levs ou encore le cot des briques d'accs pour chaque service est rdhibitoire,
L'ESB ici va permettre d'exposer les services d'une application existante. Sa connectivit lui permet
d'interroger les systmes existants pour crer les services du SI.
Figure 8 - Service Enablement (Exposition de service)
Dans le cas o les services de l'ESB ont vritablement vocation durer dans le temps et constitue,
finalement, une "extension" de l'application dont il expose les services, on aura tendance crer une
instance de l'ESB distincte du rle de mdiateur habituel.
22 / 23
Conclusion
Utiliser un Enterprise Service Bus (ESB) dans son systme dinformations contribue lagilit vise lors de la
mise en uvre dune architecture oriente services (SOA). Son adoption se doit nanmoins dtre rflchie,
anticipe et matrise pour viter les cueils classiques. Un ESB peut apporter de la souplesse dans une
SOA grce au dcouplage entre consommateurs et fournisseurs de services et la mise disposition rapide
de nouveaux services.
Mettre en place un ESB alors que les changes entre les applications nont pas t normaliss et rflchis
de manire transverse peut gnrer plus de problmes quil napporte de solutions. Le ou les ESB sont au
centre du SI et mettent en relief tous les problmes dintgration.
Un autre point de vigilance est souligner. LESB ne doit pas tre quun mdiateur sans intelligence ("passe-
plat"). Dans ce cas, sa valeur ajoute est quasiment nulle. A loppos, si lESB prend sa charge trop de
mtier, il risque de dnaturer et dresponsabiliser les applications auxquelles il accde.
Dune manire gnrale, le contenu dun ESB doit tre en perptuelle volution : il sert donner de lagilit
et de la souplesse au SI pour "ponger" les changements et modrer les impacts en attendant que toutes
les applications du SI salignent sur les changements.
La plupart des mdiations dun ESB ont une dure de vie courte.
Ainsi, mettre en place une mthode agile ou plus gnralement
itrative pour conduire les projets ESB correspond tout fait la
philosophie des SOA.
23 / 23

Les Esb Dans La Soa PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Les Esb Dans La Soa PDF

Transféré par

Droits d'auteur :

Formats disponibles

LIVRE BLANC

Comprendre et savoir utiliser

Copyright Xebia 2007

10/12 Avenue de lArche

92419 Courbevoie Cedex

Comprendre et savoir utiliser un ESB dans une SOA

Table des matires

Comment dclencher, en rponse un vnement dans un sous-systme donn, un traitement

Il propose une interface connue et prenne.

La formalisation du paradigme SOA a clairement eu le mrite de replacer le mtier au centre de l'architecture

Le couplage technique impose au consommateur de connatre le protocole d'change du fournisseur c'est

Nouveau Graal des Systmes d'Information, les Architectures

Les outils ETL

Les middlewares network centric

Les Web Services pour grer les communications synchrones.

1 JCA : Java Connector Architecture.

Les ESB sont aujourd'hui la technologie d'intgration et de mdiation

A quoi sert un ESB ?

A ce titre, ses principales responsabilits sont les suivantes :

Le rle de mdiateur des ESB peut devenir plus large encore :

1 BPEL : Business Process Execution Language.

Au del du rle classique d'un middleware d'intgration, l'ESB doit

Adaptation aux environnements htrognes

Ne dpend pas d'un systme d'exploitation ou d'un langage.

Support de diffrentes smantiques d'change de messages (synchrone requte-rponse ,

1 SCA : Service Component Architecture.

La garantie de livraison des messages tout en conservant les messages non-consomms

Du cot des standards

Les tentatives de standardisation actuelle couvrent les besoins suivants :

Format des donnes.

1 JBI : Java Business Integration

Synthse des fonctionnalits

Connectivit Supporte de multiples protocoles de transport synchrone ou

Mdiation Adapte le format des messages, le protocole, effectue des

Exposition de services Transforme en service(s) un composant ou un traitement d'une

Traitement d'vnements Permet la cration des rgles de corrlation et de jointure

Supervision et audit Offre des fonctions d'audit, de traabilit, de mesure, d'administration et

De part sa position centrale, lESB peut aussi devenir un goulet

Principe de mise en uvre

Figure 2 - Cas d'utilisation d'un ESB : Couplage lche

Les responsabilits de l'ESB sont ici les suivantes :

Principes de mise en uvre

Figure 3 - Cas d'utilisation d'un ESB : Composition / agrgation de services

Il sagit ici d'un assemblage simple de service, et non d'orchestration ou de processus.

Principe de mise en uvre

Figure 4 - Cas d'utilisation d'un ESB : Gestion de version

Principes de mise en uvre

Figure 5 - Cas d'utilisation d'un ESB : Gestion de la QoS

Il existe deux implmentations du mme service :

Principes de mise uvre

Figure 6 - Intgration avec une solution d'orchestration

Principes de mise en uvre

Les diffrents domaines dune

Figure 7 - Mdiation intra-domaine et inter-domaines

Principes de mise en uvre

Figure 8 - Service Enablement (Exposition de service)

Vous aimerez peut-être aussi