Cas d'usages d'un ESB - Petals Link - 2011

Cas d’Usages d’unEnterprise 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

CAS D’USAGES d’UN ESB
Quelques Mots sur Petals Link
3

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 Europedes solutionsOpen Source pour la SOA et un acteur reconnu au niveau mondial.
4

Quelques mots sur Petals Link2/2
Des investissements R&D constants et importants
Incubateur de futures solutions pour la SOA
13 projets R&Den 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
5

Enjeux de la l’Architecture Orientée Service
6

Les 4 enjeux de la SOA
7

Enjeux de la SOA : l’agilité
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 SI
Adéquation du SI aux besoins
Maîtrise de la complexité
Fiabilité
Maîtrise des coûts
8

Enjeux de la SOA : la réutilisation
La réutilisation
Objectif des DSI depuis longtemps
Demande qui découle de la complexité croissante des SI
Approches à base de composants réutilisables
Déjà mises en oeuvre
N’évitent pas la construction de silos
9

Enjeux de la SOA : la rationalisation
Métier
Fonctionnel
Applicatif
Physique
Trop de modules logiciels dupliqués
Les connexions nécessaires entre applications amènent à des intégrations de type “spaghettis”, lourdes à mettre en oeuvre
Les objectifs de la rationalisation dans le SI
Une application dans le SI = Seul fournisseur d’une fonctionnalité dans le SI
Urbaniser les liens inter-applicatifs
Couplage faible entre applications (réduire les dépendances)
10

Enjeux de la SOA : ouverture & interopérabilité
L’ouverture
Intégrer simplement les différentes fonctions de l’entreprise
Exigence pour l’entreprise étendue
On parle alors d’interopérabilité
L’interopérabilité
Possibilité pour des systèmes, des composants ou des services, d’échanger des données et de l’information
Deux systèmes sont véritablement interopérables s’ils peuvent collaborer sans se connaîtreintimement
Ces notions sont basées sur
L’utilisation de standards ouverts (XML, web services, ...)
Le couplage faible entre les composants du SI.
11

L’Enterprise Service Bus :
Approches,
Concepts et Apports dans le SI,
Topologies.
12

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

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

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

Approche ESB
Approche SOA par l’ESB :
Couplage Lâche,
Médiation, Routage,
Transformation, Orchestration Technique ou Métier,
Utilisation des Standards.
16

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 :
Couplagefaible, Flexibilité, Evolutivité et Maintenabilité
Performance : scalabilité et Haute Dispo
ApprocheInfrastructure, Gestion des Services, Sécurité
Supervision et Qualitéde Service
Valorisationde l’existant
17

Topologieen îlots
Un serveur unique auquel se connectent les applications exposant ou consommant des services
Communication vers le serveur ESB
Point sensible de l’architecture
18

En îlots : communication avec d’autres ESB
Utilisation d’un connecteur standard
L’autre ESB est vu comme n’importe quelle application
Possibilité d’utiliser une couche middleware supplémentaire inter-ESB
Exemple : JMS
Il faut savoir comment accéder à un service présent sur un autre ESB
Exemple : utiliser un pont HTTP
19

Enterprise Service Bus
En îlots, pas de réelle infrastructure de services
Îlots d’intégrations
ESB +/- interconnectés
Besoins 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 supervision
Visibilité restreinte à chaque noeud
Orienté intégration d’applications
Intégration au cas par cas
20

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
21

Topologie unifiée : les domaines
Dans une entreprise, chaque entité peut être vue comme un domaine
Exemples : comptabilité, gestion des stocks...
Une entité peut avoir plusieurs noeuds de l’ESB dans son parc informatique
Un domaine contient alors l’ensemble des noeuds d’une entité
L’ESB peut être divisé en domaines tout en gardant son unicité
22

Topologie unifiée : administration et supervision
Administration
Chaque 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.)
Supervision
Traç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
23

L’Architecture de Petals ESB
24

PETALS ESB
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….
25

PETALS ESB:
Java Business Integration
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
26

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 êtrede 2 types:
Binding Component (BC) ouConnecteur : Web Service, FTP, JMS…
Service Engine (SE) oumoteur de service : transformation, orchestration…
Le container J.B.I gère :
La communication entre cescomposants (NMR)
Avec un registre de services interne
Le container J.B.I. permetaussi:
L’installation et le cycle de vie des composants JBI
Le déploiement d’artefactsde service surles composants (feuille XSLT, processus BPEL…)
27

PETALS ESB:
Le container J.B.I.
Services externes
Artifacts
XSL
XSL
Process
Process
pattern
pattern
Components
JBI
SOAP
HTTP
JMS
MOM
AS1/AS2
EDI
XSLT
BPEL
EIP
JBI container
Deux types de composants :
Service Engines : fournissent de la transformation et d'autres services d'intégration
Binding Components : connecteurs vers des ressources externes
28

PETALS ESB:
Les Composants
Connecteurs
Persistance
Transformation
Orchestration
29

PETALS ESB :
Infrastructure Nativement Distribuée
Infrastructure de Services
Service
Noeud
PetalsESB
Service
Noeud
PetalsESB
SI A
Service
Service
Noeud
PetalsESB
SI C
Service
Service
SI B
30

Cas d’Usages d’un ESB:
Plateforme d’Intégration : Portail et intégration FO et BO
Infrastructure de Services : Architecture répartie
31

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é
32

Connectivité et Couplage faible
33

Adaptation et Maintenabilité
34

Sécurisation des flux et Mediation de Sécurité
35

Portail et intégration FO et BO
Un cas d’usage d’intégration classique permettant de
Accélererl’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
36

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
37

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
38

Architecture Répartie
Un cas d’usage moderne permettant
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
39

Pilotage Centralisé
40

http://planet.petalslink.com	92
http://mickaelistria.wordpress.com	42
http://a0.twimg.com	1

Cas d'usages d'un ESB - Petals Link - 2011

by Petals Link on Oct 06, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 135

Statistics

Cas d’usages d’un ESB - Petals Link - 2011 — Presentation Transcript