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é