Le document présente le rôle et les besoins des bus de services d'entreprise (ESB) dans une architecture orientée services (SOA). Il aborde les problématiques d'intégration entre sous-systèmes hétérogènes et les solutions offertes par les ESB pour la médiation, le routage et la gestion des messages. Le document souligne également l'importance de la normalisation et des standards pour faciliter l'interopérabilité et réduire le couplage fonctionnel entre services.

1. Enterprise Service Bus (ESB)
Chapitre 4 - eServices
GL5
2015/2016
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1

2. Besoins des ESB
Rôle des ESB dans une SOA
Cas d’utilisation d’un ESB
2
PLAN

3. Besoins des ESB
Rôle des ESB dans une SOA
Cas d’utilisation d’un ESB
3
PLAN

4. Problématique d’Intégration
Construction des SI
• Chaque domaine métier bâtit un sous-système qui lui est propre
• Utilisation de technologies hétérogènes, rarement interopérables
Problématiques d’intégration:
• Comment déclencher, en réponse à un sous-système donné, un traitement
dans un autre sous-système hétérogène?
• Comment assurer la consistance et propagation des données entre plusieurs
sous-systèmes?
Deux types de solutions:
• Les outils ETL (Extract-Transform-Load)
• Les solutions middleware
4
Besoins des ESB

5. Outils ETL: Extract-Transform-Load
Réponse à la problématique: Assurer la consistance et propagation des
données entre plusieurs sous-systèmes
Permettent la synchronisation, consolidation et propagation des données
entre sous-systèmes hétérogènes
• Extraction des données du système maître
• Transcodage et traitement de ces données
• Mise à jour des systèmes fils
Apparus à l’origine pour le chargement des datawarehouses
Inconvénients
• Approche centrée sur les données
• Ne permet pas de résoudre la problématique d’intégration des processus
5
Besoins des ESB

6. Middlewares Network Centric (1/2)
Fournissent une infrastructure technique pour la médiation
entre deux ou plusieurs systèmes
MOM (Message Oriented Middleware)
• Système Store and Forward
• Sémantique asynchrone : Le client construit un message et le
transmet au middleware, qui le route vers le ou les systèmes
cibles
• Pas de couplage technique entre les participants
• Solutions principalement propriétaires : Toutes les parties
doivent connaître le mode d’interfaçage du middleware
• Capacités de routage limitées, obligeant à configurer
explicitement les routes à prendre
6
Besoins des ESB

7. Middlewares Network Centric (2/2)
ORB (Object Request Broker)
• S’appuie sur la spécification CORBA
• Sémantique d’invocation point à point synchrone ou asynchrone,
avec un protocole et encodage standardisés
• Objectif : architecture d’intégration universelle
• Inconvénients : complexité de mise en œuvre, et problèmes
d’interopérabilité des implémentations (contrairement aux
promesses de la spécification)
Solutions très techniques
Couplage fonctionnel fort
7
Besoins des ESB

8. Les EAI : Enterprise Application Integration
Architecture Hub and Spoke (réseau en étoile): Un composant central :
• Assure la médiation physique entre le client et sa cible
• Prend en charge les problématiques techniques de bas niveau (localisation,
disponibilité, communication, transcodage, traces, sécurité…)
Permettent d’assurer la transformation des données pour limiter le couplage
fonctionnel entre systèmes
Permettent d’appliquer des règles de routage sophistiquées
Jouent le rôle d’orchestrateur : hébergent des processus métier de haut niveau
Inconvénients
• Architecture propriétaire :
• protocole d’échange et de transport
• technologie interne
• Formats et encodages des données
è besoin de connecteurs spécifiques aux éditeurs
• SPOF (Single Point of Failure)
• Mélange de rôles (médiation et orchestration) è Brique complexe
8
Besoins des ESB

9. Les ESB : Enterprise Service Bus
Les EAI se sont transformés en deux types de produits:
• Les ESB pour les fonctions d’interconnexion et de médiation
• Les solutions de type BPM pour l’orchestration des processus
Contrairement aux EAI, les données ne doivent pas être ramenées à l’ESB
pour être traitées, mais sont envoyées aux applications via des
connecteurs distants
Construit conformément aux principes SOA :
• Ses différentes parties sont faiblement couplées
• Peuvent être déployées séparément si nécessaire
ESB s’appuient en général sur des standards
9
Besoins des ESB

10. ESB : Définition
Architecture de services distribuée, qui inclut un modèle de
conteneur léger pour héberger des composants d’intégration
comme services distants
Permet de :
• Délivrer des messages entre applications et services
• Réaliser les transformations des données
• Router les messages selon leur contenu
Framework de sécurité flexible
Infrastructure de gestion qui permet de configurer, déployer et
gérer vos services distants
10
Besoins des ESB

11. Besoins des ESB
Rôle des ESB dans une SOA
Cas d’utilisation d’un ESB
11
PLAN

12. A quoi sert un ESB? (1/2)
Réconcilier les mondes hétérogènes
Standards d’interopérabilité ou connecteurs spécialisés
Découpler consommateurs et fournisseurs de services
Consommateur ne voit que l’ESB, et ne connaît ni le format ni le protocole utilisé
par le fournisseur
Agréger les services de niveau N pour construire des services de niveau N+1
Si l’agrégation est complexe ou nécessite des structures de contrôle de flux
d’exécution, il utilise un moteur d’orchestration (BPEL par exemple)
Tracer les messages
Traçabilité et monitoring des traitements
Peut utiliser une solution tierce pour adresser les problématiques de SLA, QoS,
BAM (Business Activity Monitoring)…
12
Rôle des ESB dans une SOA

13. A quoi sert un ESB? (2/2)
Exposer des services d’applications qui ne supportent pas la
fonctionnalité de médiation (Mainframes ou progiciels)
Mutualiser les accès aux applications
• Mieux gérer les ressources
• Contrôler la charge
• Appliquer des règles de sécurité ou priorité
Minimiser les coûts des connecteurs
Le connecteur est déployé une seule fois sur l’ESB au lieu d’être
déployé sur chaque application cliente
Implémenter un système de cache pour décharger certaines
applications
13
Rôle des ESB dans une SOA

14. Fonctionnalités d’un ESB
1. Adaptation aux environnements hétérogènes
• ESB apporte une couche d’abstraction vis à vis des technologies
utilisées dans le SI
• Ne dépend pas d’un SE ou d’un langage
• Supporte plusieurs standards : WS, XML, JCA
• Expose les services de manière uniforme quelque soit la technologie
sous-jacente
• Utilise XML comme langage standard de représentation et traitement
des données
• Offre un panel ouvert de connecteurs spécialisés vers les différentes
briques du SI (mainframes, applications propriétaires, progiciels…)
14
Rôle des ESB dans une SOA

15. Fonctionnalités d’un ESB
2. Médiation et Routage
• Support de différentes sémantiques d’échange (synchrone,
asynchrone…)
• Gestion des règles de routage sur les messages
• Gestion de la priorité des messages
• Transformation et conversion de messages
• Manipulation des messages : enrichissement, transformation,
combinaison, découpage…
• Validation des données entrantes ou sortantes
• Gestion des versions de services de façon transparente
15
Rôle des ESB dans une SOA

16. Fonctionnalités d’un ESB
3. Management, Monitoring, Contrat de Service
• Suivi et fiabilisation des échanges
• Garantie de livraison des messages en conservant les messages non
consommés
• Suivi des traitements effectués et messages reçus
• Gestion de la sécurisation des services
• Authentification
• Autorisation
• Confidentialité
• Audit
• Contrôle des SLA et aptitude à modifier le comportement du bus
(priorités…) pour assurer ces SLA
16
Rôle des ESB dans une SOA

17. Du Côté des Standards…
17
Rôle des ESB dans une SOA
Format
des
données
XML,
schémas
XSD
SDO
:
Service
Data
Object
:
norme
de
représenta;on
des
données
indépendamment
du
système
de
stockage,
u;lisée
dans
les
SOA
Transforma/on
des
données
XSLT
et
XQuery
(langage
de
requête
pour
l’extrac;on,
transforma;on
et
reconstruc;on
de
docs
XML
)
Exposi/on
de
services
WS,
WS-­‐Security
Accès
aux
brokers
de
messages
JMS
(Java
Message
Service)
pour
l’accès
aux
MOM
Accès
aux
applica/ons
JCA
(Java
Connector
Architecture)
:
interface
pour
l’accès
à
des
applica;ons
;erces
Architecture
des
composants
SCA
(Service
Component
Architecture)
Architecture
Interne
JBI
(Java
Business
Integra;on)
:
spécifica;on
pour
l'intégra;on
de
données.
-­‐ conteneur
de
services
dans
un
ESB
-­‐ gère
l’intégra;on
:
créa;on
de
services
à
par;r
des
applica;ons
et
en;tés
IT
(basée
sur
les
standards
de
WS)
-­‐ ne
gère
pas
le
routage,
l’agréga;on
et
l’administra;on

18. Synthèse
Connec/vité
«
Super-­‐connecteur
»,
supporte
plusieurs
protocoles
de
transport
synchrones
et
asynchrone
Routage
Routage
de
messages
basé
sur
des
règles
(de
contenu,
contexte..),
et
s’appuyant
sur
un
annuaire
de
services
et
moteur
de
règles
Média/on
Adapta;on
du
format
des
messages,
protocole
Exposi/on
de
services
Transforma;on
en
service
de
tout
composant
ou
traitement
d’applica;on
Agréga/on
simple
de
services
Agréga;on
simple
de
services
de
niveau
N
pour
construire
des
services
de
niveau
N+!.
Pour
les
agréga;ons
complexes,
u;lisa;on
d’un
moteur
d’orchestra;on
Traitement
d’évènements
complexes
Créa;on
de
règles
de
corréla;on
et
de
jointure
d’évènements
Contrat
de
Service
SLA,
QoS,
ges;on
des
priorités,
sécurisa;on
des
messages,
garan;e
de
livraison…
Supervision
et
Audit
Audit,
traçabilité,
mesure,
administra;on
et
exploita;on.
18
Rôle des ESB dans une SOA

19. Risques
Un ESB n’est pas nécessaire au démarrage d’une SOA
• Nécessité d’une réflexion plus large au niveau du SI et d’un certain
niveau de maturité de la SOA.
• Il faut d’abord définir la démarche, méthode, organisation et
implémentation de la SOA.
Un ESB ne doit pas être considéré comme un orchestrateur de
services
Un ESB ne doit pas embarquer trop de métier dans les
médiations qu’il propose.
L’ESB peut devenir un goulot d’étranglement
• Plus les médiations sont complexes, plus il y’a perte de performances
19
Rôle des ESB dans une SOA

20. Besoins des ESB
Rôle des ESB dans une SOA
Cas d’utilisation d’un ESB
20
PLAN

21. Couplage Lâche
Exposition : Le consommateur ne connaît que l’ESB, il invoque le service que ce dernier lui
expose
Routage : ESB détermine le fournisseur de service à invoquer
Transformation : ESB réalise une médiation de format vers celui pris en charge par le
fournisseur
Invocation : ESB invoque le fournisseur
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 21

22. Composition / Agrégation de services
ESB expose un service virtuel qu’il construit par composition ou agrégation de plusieurs
autres services
è Assemblage simple de services, pas une orchestration de processus
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 22

23. Gestion de versions
2 cas :
• Versions incompatibles : Le choix d’une version se fait par routage
• Versions compatibles : ESB appelle la nouvelle version en appliquant une transformation
des données.
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 23

24. Gestion de la QoS
QoS : temps de réponse moyen / fraîcheur des données
• ESB peut déterminer quelle implémentation invoquer en fonction de la QoS désirée
(utilisation d’un moteur de règles)
• ESB peut géolocaliser les services, pour choisir le plus approprié
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 24

25. Intégration avec solution d’orchestration
Éviter de lier fortement l’orchestrateur de processus avec les services qu’il appelle
• ESB convertit les données au format de conception du processus
• ESB expose tous les services avec la même technologie pour simplifier la réalisation du
processus
• ESB crée un nouveau service en agrégeant plusieurs services existants
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 25

26. Médiation Inter-domaine et Intra-domaine
Domaines :
• équipes différentes
• plannings différents
• budgets différents
• ESB introduit aux frontières des domaines
• Dé-corrélation et découplement des appels
entre domaines
• ESB peut être utilisé dans un échange B2B
comme douanier entre applications internes
et partenaires
• ESB gère :
• conversion des protocoles
• conversion des formats
• aspects de sécurité
• traçabilité des échanges
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 26

27. Exposition de services
• Exposition des services d’une application existante (legacy)
• Interrogation des systèmes existants pour créer les services du SI, grâce à des
connecteurs dédiés
• Possibilité de créer une instance d’ESB distincte du médiateur, si les services exposés
ont vocation à durer
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 27

28. Livre Blanc
Xebia Business Integration Architect, Comprendre et Savoir
utiliser un ESB dans une SOA, Xebia, 2007
28
Sources