Découvrez en quelques minutes les enjeux essentiels des architectures orientées services (interopérabilité, agilité, disponibilité) et comment y répondre à l'aide d'un ESB.

1. Cas d’Usages d’unEnterprise Service Bus

2. 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 3

4. 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

5. 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

6. CAS D’USAGES d’UN ESB Enjeux de la l’Architecture Orientée Service 6

7. Les 4 enjeux de la SOA 7

8. 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

9. 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

10. 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

11. 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

12. CAS D’USAGES d’UN ESB L’Enterprise Service Bus : Approches, Concepts et Apports dans le SI, Topologies. 12

13. 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

14. 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

15. 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

16. 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

17. 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 : 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

18. Enterprise Service Bus : 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

19. Enterprise Service Bus : 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

20. 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

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 21

22. Enterprise Service Bus : 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

23. Enterprise Service Bus : 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

24. CAS D’USAGES d’UN ESB L’Architecture de Petals ESB 24

25. 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

26. 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

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 ê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

28. 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

29. PETALS ESB: Les Composants Connecteurs Persistance Transformation Orchestration 29

30. 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

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 31

32. CAS D’USAGES d’UN ESB Plateforme 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é 32

33. CAS D’USAGES d’UN ESB Plateforme d’échanges avec l’extérieur du SI Connectivité et Couplage faible 33

34. CAS D’USAGES d’UN ESB Plateforme d’échanges avec l’extérieur du SI Adaptation et Maintenabilité 34

35. CAS D’USAGES d’UN ESB Plateforme d’échanges avec l’extérieur du SI Sécurisation des flux et Mediation de Sécurité 35

36. CAS D’USAGES d’UN ESB 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 Il va permettre plus de maintenabilité et de flexibilité 36

37. CAS D’USAGES d’UN ESB Portail 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 37

38. CAS D’USAGES d’UN ESB Portail 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 38

39. CAS D’USAGES d’UN ESB Architecture 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é 39

40. CAS D’USAGES d’UN ESB Architecture Répartie Pilotage Centralisé 40