Cas d'usages d'un ESB - Petals Link - 2011
-
Upload
petals-link -
Category
Technology
-
view
4.035 -
download
3
description
Transcript of Cas d'usages d'un ESB - Petals Link - 2011
CAS D’USAGES D’UN
ENTERPRISE SERVICE BUS
Cas d’Usages d’un Enterprise Service Bus (ESB)
Quelques Mots sur Petals Link
Enjeux de l’Architecture Orientée Service
L’Enterprise Service Bus : Approches, Concepts et Apports dans le SI, Topologies
L’Architecture de Petals ESB
Cas d’Usages :
Plateforme d’échanges avec l’extérieur du SI
Plateforme d’ Intégration : Portail et intégration FO et BO
Infrastructure de Services : Architecture de réparties
2
3
CAS D’USAGES d’UN ESB
Quelques Mots sur Petals Link
Quelques mots sur Petals Link 1/2
Éditeur de solutions Open Source innovantes pour l’infrastructure SOA
Petals ESB : l’ESB distribué « best of breed »
Petals Master : la solution pour la « gouvernance SOA »
Au sein d’une communauté Open Source dédiée au middleware
EBM WebSourcing devient Petals Link
Effectif : 35 personnes
Siège à Toulouse – Agence à Paris et Grenoble
Profils : Architectes Middleware, Consultants SOA, Développeurs Java / J2EE
EBM WebSourcing a pour ambition de devenir un des leaders en Europe des solutions Open Source pour la SOA et un acteur reconnu au niveau mondial.
4
Des investissements R&D constants et importantsIncubateur de futures solutions pour la SOA
13 projets R&D en cours
L’implication sur Java Business Integration
Membre de l’Expert Group JCP pour JBI
Une solution d’infrastructure distribuée et « Best of Breed »
La volonté de s’engager directement sur la mise en œuvre de nos solutions
Conseil et expertise en Architecture, Formation, Assistance et forfaits
Quelques mots sur Petals Link 2/2
5
6
CAS D’USAGES d’UN ESB
Enjeux de la l’Architecture Orientée Service
7
Les 4 enjeux de la SOA
Agilité
Réutilisation
Rationalisation
Ouverture & Interopérabili
té
8
Enjeux de la SOA : l’agilité
Agilité
Réutilisation
Rationalisation
Ouverture &
Interopérabilité
Agilité (sens général)Capacité à appréhender les changements de son environnement...... et à y apporter une réponse efficace
Agilité du système d’information (SI)Capacité du SI à prendre en compte les évolutions du métier de l’entreprise...... en y apportant des réponses simples et rapides
Les objectifs de l’agilité du SIAdéquation du SI aux besoinsMaîtrise de la complexitéFiabilité Maîtrise des coûts
9
Enjeux de la SOA : la réutilisation
Agilité
Réutilisation
Rationalisation
Ouverture &
Interopérabilité
La réutilisationObjectif des DSI depuis longtempsDemande qui découle de la complexité croissante des SI
Approches à base de composants réutilisables
Déjà mises en oeuvreN’évitent pas la construction de silos
10
Enjeux de la SOA : la rationalisation
Agilité
Réutilisation
Rationalisation
Ouverture &
Interopérabilité
Les connexions nécessaires entre applications amènent à des intégrations de type “spaghettis”, lourdes à mettre en oeuvre
Métier
Fonctionnel
Applicatif
Physique
Les objectifs de la rationalisation dans le SIUne application dans le SI = Seul fournisseur d’une fonctionnalité dans le SIUrbaniser les liens inter-applicatifsCouplage faible entre applications (réduire les dépendances)
Trop de modules logiciels dupliqués
11
Enjeux de la SOA : ouverture & interopérabilité
Agilité
Réutilisation
Rationalisation
Ouverture &
Interopérabilité
L’ouvertureIntégrer simplement les différentes fonctions de l’entrepriseExigence pour l’entreprise étendueOn parle alors d’interopérabilité
Deux systèmes sont véritablement interopérables s’ils peuvent collaborer sans se connaître intimement
Ces notions sont basées sur L’utilisation de standards ouverts (XML, web services, ...)Le couplage faible entre les composants du SI.
L’interopérabilitéPossibilité pour des systèmes, des composants ou des services, d’échanger des données et de l’information
12
CAS D’USAGES d’UN ESB
L’Enterprise Service Bus : Approches,
Concepts et Apports dans le SI,
Topologies.
Enterprise Service Bus : De l’intégration Ad-Hoc à l’ESB
Un peu d’histoire : depuis le début des années 90, 3 approches d’intégrations se sont succédées :
L’intégration « Ad-Hoc »,
Utilisant des middlewares le plus souvent propriétaires,
Sans approche méthodologique spécifique,
Cas par Cas.
L’approche EAI (Enterprise Application Integration)
Approche Rationalisation des Flux d’Information,
Contribution à l’émergence de l’approche orientée services,
Technologies propriétaires qui limitaient l’interopérabilité.
L’approche ESB (Enterprise Service Bus)
Approche SOA, infrastructure technique d’une Architecture SOA,
Reprend les Principes de l’EAI,
Se base sur des Standards,
Technologies libre et propriétaires.13
Enterprise Service Bus : Intégration Ad-Hoc
L’intégration « Ad-Hoc » :
Architecture « Accidentelle »
Amalgame de connexions propriétaires hétérogènes
Syndrome : Plat de Spaghetti
14
Enterprise Service Bus : Approche EAI
Approche Intégration de flux par l’EAI :
Intégration Application par Application via un connecteur
Routage et Transformation de Flux
Orchestration de processus Métier
Approche Propriétaire, Architecture centralisée, Coûts Importants
15
Enterprise Service Bus : Approche ESB
Approche SOA par l’ESB :
Couplage Lâche,
Médiation, Routage,
Transformation, Orchestration Technique ou Métier,
Utilisation des Standards.
16
Enterprise Service Bus : Définition et Apport d’un ESB
Définition :
Solution d’intégration implémentant une architecture distribuée.
Solution d’infrastructure middleware fournissant des Services de Connectivité, Routage, Transformation et d’Orchestration Technique ou Métier.
Interopérabilité en utilisant des Standards XML, Web Services (WS-* Oasis), JBI, WS-BPEL…
Apport :
Couplage faible, Flexibilité, Evolutivité et Maintenabilité
Performance : scalabilité et Haute Dispo
Approche Infrastructure, Gestion des Services, Sécurité
Supervision et Qualité de Service
Valorisation de l’existant 17
SE
Application
Serveur Appli 3
Application
Serveur ESB
JMSHTTP
Serveur Appli 2
Application
Serveur Appli 1
Application
FTPHTTP
18
Enterprise Service Bus : Topologie en îlots
Un serveur unique auquel se connectent les applications exposant ou consommant des services
Communication vers le serveur ESB
Point sensible de l’architecture
SE
Application
Serveur Appli 3
Application
Serveur ESB
JMSHTTP
Serveur Appli 2
Application
Serveur Appli 1
Application
FTPHTTP
19
Enterprise Service Bus : En îlots : communication avec d’autres ESB
Utilisation d’un connecteur standardL’autre ESB est vu comme n’importe quelle application
Possibilité d’utiliser une couche middleware supplémentaire inter-ESBExemple : JMS
Il faut savoir comment accéder à un service présent sur un autre ESBExemple : utiliser un pont HTTP
JMS
c
S
Sconsommateur
transformation
fournisseur
Flux httpConnecteur
http
Connecteur http
JMS
ESB 2
ESB 1 ESB 3
20
Enterprise Service Bus En îlots, pas de réelle infrastructure de services
Îlots d’intégrations ESB +/- interconnectésBesoins de ponts inter-ESB pour chaque service à accéder sur un autre ESB
Orchestration Pas d’annuaire global sur lequel se baser pour la construction des processus
Transaction Difficile à établir lorsque l’on passe par des ponts
Administration et supervisionVisibilité restreinte à chaque noeud
Orienté intégration d’applications Intégration au cas par cas
21
Enterprise Service Bus : Topologie unifiée
Nuage de noeuds sur plusieurs serveurs (« snowflake »)
Pour un consommateur ou un fournisseur de service, il n’y a qu’un ESB
On ne se soucie pas de la localisation physique du service à appeler
Répartition de la charge sur tous les noeuds
Nœud 4 Nœud 5
Nœud 1 Nœud 2 Nœud 6C
on
som
mat
eur
Nœud 3
22
Enterprise Service Bus : Topologie unifiée : les domaines
Dans une entreprise, chaque entité peut être vue comme un domaineExemples : comptabilité, gestion des stocks...
Une entité peut avoir plusieurs noeuds de l’ESB dans son parc informatiqueUn domaine contient alors l’ensemble des noeuds d’une entité
L’ESB peut être divisé en domaines tout en gardant son unicité
Entité A
1 seul ESBdécomposé en
Domaines
Ser
vice
A1
Ser
vice
An
domaine A
Entité B
Ser
vice
B1
Ser
vice
Bn
domaine B
Entité C
Ser
vice
C1
Ser
vice
Cn
domaine C
23
Enterprise Service Bus : Topologie unifiée : administration et supervision
AdministrationChaque domaine garde la maîtrise de ses noeuds
Déploiement de services et maintenance depuis une console centralisée
Vue d’ensemble de la topologie permettant de réguler les flux (load balancing, etc.)
SupervisionTraçage centralisé des messages entrant / sortant / transitant du domaine
Pas de limitation dans le suivi car l’ESB est présent de bout en bout des appels
Node 1 Node 2
co
ns
um
.
serv
ice
serv
ice
24
CAS D’USAGES d’UN ESB
L’Architecture de Petals ESB
25
Solution Open Source
Produit réalisé par les collaborateurs Petals Link
License LGPL
Souscription pour du Support
Une architecture à composants basé sur
Java et la norme J.B.I. : Java™ Business Integration
Léger et Modulaire et nécessitant pas de serveur d’application
Basé sur des standards reconnus, pour rester libre de ses choix logiciels
Java, J.B.I, WS-*, REST, BPEL, EIP, SCA, JSR 181, XSLT, XSD….
PETALS ESB
26
J.B.I. : Java™ Business Integration
Spécification définie par la JSR 208
Le standard Java™ pour la création de solutions d'intégration
Basé sur l'état de l'art des Web Services
Un conteneur à base de plugins
Un environnement JBI est un conteneur de composants
Permet l’échange de messages entre ces composants
Gestion du cycle de vie et de la configuration des composants
Un conteneur basé sur l'échange
Échanges de message faiblement couplés
Description des services en WSDL
Messages au format XML
PETALS ESB:Java Business Integration
27
PETALS ESB:JBI, un container de composants
Les solutions d’intégration sont construites par assemblage et configuration de composants J.B.I.
Les composants J.B.I. peuvent être de 2 types:
Binding Component (BC) ou Connecteur : Web Service, FTP, JMS…
Service Engine (SE) ou moteur de service : transformation, orchestration…
Le container J.B.I gère :
La communication entre ces composants (NMR)
Avec un registre de services interne
Le container J.B.I. permet aussi:
L’installation et le cycle de vie des composants JBI
Le déploiement d’artefacts de service sur les composants (feuille XSLT,
processus BPEL…)
28Binding Components : connecteurs vers des ressources externes
Service Engines : fournissent de la transformation et d'autres services d'intégration
Deux types de composants :
PETALS ESB:Le container J.B.I.
JBI container
SOAP
HTTP
JMS
MOM
AS1/AS2
EDIXSLT BPEL EIP
Services externes
Components
JBI
Artifacts
XS
L
XS
L
Process
Process
pattern
pattern
29
PETALS ESB:Les Composants
Connecteurs
Transformation Orchestration Persistance
30
PETALS ESB :Infrastructure Nativement Distribuée
Infrastructure de Services
NoeudPetalsESB
ServiceService
Service
Service
Service
NoeudPetalsESB
NoeudPetalsESB
Service
SI A
SI B
SI C
31
CAS D’USAGES d’UN ESB
Cas d’Usages d’un ESB: Plateforme d’échanges avec l’extérieur du SI
Plateforme d’Intégration : Portail et intégration FO et BO
Infrastructure de Services : Architecture répartie
32
CAS D’USAGES d’UN ESBPlateforme d’échanges avec l’extérieur du SI
Un cas d’usage fréquent, permettant aux DSI de
Déployer la technologie et de monter en compétences
Maitriser les flux et décharger la production
Faciliter la connectivité externe
Optimiser l’intégration avec le SI Interne
Sécuriser leurs flux externes
Description
L’ESB va venir urbaniser les échanges avec les partenaires de l’entreprise
Il va faciliter l’interropérabilité et l’adaptation entre le SI Interne et les
partenaires
Il va augmenter la QoS en découplant le SI Interne
Augmenter l’isolation et la sécurité
Il va permettre plus de maintenabilité et de flexibilité
33
CAS D’USAGES d’UN ESBPlateforme d’échanges avec l’extérieur du SI
Connectivité et Couplage faible
34
CAS D’USAGES d’UN ESBPlateforme d’échanges avec l’extérieur du SI
Adaptation et Maintenabilité
35
CAS D’USAGES d’UN ESBPlateforme d’échanges avec l’extérieur du SI
Sécurisation des flux et Mediation de Sécurité
36
CAS D’USAGES d’UN ESBPortail et intégration FO et BO
Un cas d’usage d’intégration classique permettant de
Accélerer l’intégration du FO et du BO
Ne pas faire porter la spécificité d’un SI Bo au FO
Cacher la complexité du SI BO
Apporter des fonctionnalités de plus haut niveau au FO
Faciliter la disponibilité d’un FO
Description
L’ESB va venir se placer entre le FO ou portail et le BO
Il va faciliter l’interopérabilité en se connectant aux différents BO
Proposer des Services au FO
Il va augmenter la QoS en découplant avec le BO
Il va permettre plus de maintenabilité et de flexibilité
37
CAS D’USAGES d’UN ESBPortail et intégration FO et BO
FO connecté au Bus
FO consomme ou expose des services
Technologie et Spécificité du BO cachée du FO
Possibilité de réaliser des services de plus haut niveau
38
CAS D’USAGES d’UN ESBPortail et intégration FO et BO
FO connecté au Bus FO
BO connecté au Bus BO
FO et BO consomme ou expose des services sur leur instance locale
Isolation permettant du SLA différencié
Architecture évolutive
39
CAS D’USAGES d’UN ESBArchitecture Répartie
Un cas d’usage moderne permettant
Architecture Répartie
Fédérer des SI réparties géographiquement ou logiquement
Apport de dynamicité et d’ouverture
Architecture atteignable avec un ESB open source
Description
L’ESB va venir se déployer dans chaque domaine ou région
Il va faciliter l’interopérabilité dans le SI
Il va augmenter la disponibilité en permettant des invocations alternatives
Il va permettre plus de maintenabilité et de flexibilité
40
CAS D’USAGES d’UN ESBArchitecture Répartie
Pilotage Centralisé