Architectures Orientées Services Version 2.0

Transcription

1 Architectures Orientées Services Version 2.0 Principes de base et tour d horizon o Premières définitions et avantages o Enterprise Service Bus (ESB) o Standards (c) Leuville Objects. Tous droits de traduction, d adaptation et de reproduction par tous procédés, réservés pour tous pays. Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage, faite sans l autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété intellectuelle du 1er juillet 1992, articles L 122-4, L et L 335-2).

2 (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

3 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Quiproquos SOA? o Une application qui utilise des services web est de type SOA o Une application qui utilise des services web ainsi que des extensions WS-X est de type SOA o SOA est avant tout un terme marketing qui cache un concept ancien : les web services o SOA est un terme marketing qui cache un concept d informatique distribuée basée sur les web services o SOA simplifie l informatique distribuée o La connaissance des Web Services est suffisante pour bâtir une architecture SOA o Une fois l architecture SOA adoptée, toutes les applications deviennent interopérables SOA o La technologie n est pas suffisante o Le modèle architectural sous-jacent est complexe o La définition des services l est également o L interopérabilité n est pas automatique (c)leuville Objects 2-27

4 Quiprocos Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

5 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Premières définitions o Une architecture SOA crée des services réutilisables de niveau entreprise accessibles à travers des standards Web neutres et ouverts o L architecture orientée service ou SOA est une stratégie permettant de convertir les fonctions élémentaires des applications d entreprise en services normalisés et inter-opérables qui peuvent ensuite être rapidement combinés et réutilisés pour répondre aux besoins métier. Idées essentielles o orientation services et non pas fonctionnalités ou applications o réutilisabilité o granularité entreprise o importance des standards o adaptabilité o plus une stratégie d entreprise qu une nouvelle technologie (c)leuville Objects 2-29

6 Premières définitions Notes La seconde définition provient de BEA Systems. (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

7 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Définitions d un service et d une architecture SOA Service o MSDN : un composant capable d exécuter une tâche. o Microsoft : un programme qui interagit avec d autres programmes au moyen de messages o Gartner Group : Un service désigne une action exécutée par un composant "fournisseur" à l'attention d'un composant "consommateur", basé éventuellement sur un autre système. Web Service o W3C : système logiciel identifié par une URI dont les interfaces publiques et les liaisons sont définies et décrites en XML. Sa définition peut être découverte en utilisant d autres systèmes logiciels. Ces systèmes peuvent interagir avec le Web Service selon des modalités prescrites par sa définition, en utilisant des messages XML transportés par des protocoles Internet. Architecture Orientée Services o CBDI : Les stratégies, pratiques et frameworks qui permettent aux fonctionnalités applicatives d être consommées comme des ensemble de services publiés à un niveau de granularité dépendant du consommateur de ces services. Les services peuvent être invoqués, publiés et découverts et sont découplés de toute implémentation par l emploi d interfaces basées sur des standards. o Gartner Group : un modèle d'interaction applicative mettant en oeuvre des connexions en couplage lâche entre divers composants logiciels (ou agents). (c)leuville Objects 2-31

8 Définitions d un service et d une architecture SOA Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

9 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Avant SOA CORBA : une première tentative d établissement d un "bus logiciel" o une infrastructure de diffusion de messages orientée Objet o des services techniques évolués o une vision "métier" orientée Objets et Applications o une certaine indépendance vis-à-vis des plateformes Mais o très grande complexité o coûts de développement importants o refusé par un acteur important : Microsoft (c)leuville Objects 2-33

10 Avant SOA Notes CORBA = Common Object Request Broker Architecture OMA = Object Management Architecture IIOP = Internet Inter ORB Protocol ORB = Object Request Broker ou Courtier en Requêtes Objet (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

11 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Avant SOA Intégration avec liaisons Point-à-Point EAI CRM Siebel API Siebel API Niveau client o Nombreuses dépendances entre applications o Couplage fort «logique métier» Component1 Siebel «appli cliente» Component4 o Interfaces, données et messages propriétaires o Complexité o Travail identique fait plusieurs fois «logique métier» Component2 SAP API ERP SAP Serveur d'applications SAP API «appli cliente» Component5 o Adaptation aux changements délicate o Coûts de développement élevés Quelques acteurs «logique métier» Component3 Mainframe Appli J2EE API custom API Custom «appli cliente» Component6 o serveurs J2EE Appli API Custom spécifique API Custom o MS.NET (c)leuville Objects 2-35

12 Avant SOA Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

13 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Avant SOA EAI / BPM Niveau client o un bus centralise les connexions et diffuse les données «Appli VB» Component7 «Appli Java» Component8 «Appli web» Component9 o les connexions se font à travers des API propriétaires et/ou spécifiques o les échanges se font selon des formats propriétaires et/ou spécifiques Middleware ou bus de messages Quelques acteurs C / C++ JAM IDOCs/BAPI RMI o Weblogic Integration de BEA Systems CRM Mainframe ERP Serveur d'applications o Websphere MQ Worksflow d IBM Siebel Appli spécifique SAP Appli J2EE o BizTalk de Microsoft o webmethods, Tibco,... (c)leuville Objects 2-37

14 Avant SOA Notes EAI = Enterprise Applications Integration ou intégration d applications d entreprise BPM = Business Process Management (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

15 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 SOA Approche architecturale au niveau de l entreprise o Ensemble de services qui communiquent à travers un réseau o faiblement couplés o possédant des interfaces bien définies et indépendantes des plateformes o réutilisables o Développement organisé à un plus haut niveau d abstraction o centré sur les processus métier o tourné vers les échanges inter-entreprises et organisations o masque la complexité technique o Basé sur des technologies et mécanismes standards o XML o WebServices SOA = EAI + patterns normalisés? (c)leuville Objects 2-39

16 SOA Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

17 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Le nouveau modèle induit par SOA Des composants aux services Architecture de composants distribués Architecture orientée services - SOA Orientation fonctionnalités Orientation processus métier Prévus pour durer Prévue pour supporter le changement Cycles de développement plus longs Cycles plus courts et interactifs Centrée sur les coûts Centrée sur les activités métier Sémantique de haut niveau par agrégation et blocs applicatifs Couplage fort Couplage faible Orchestration et chorégraphie des services Technologie homogène Technologie hétérogène Orientation Objet Orientation message Dépendance avec l implémentation Abstraction plus forte (c)leuville Objects 2-41

18 Le nouveau modèle induit par SOA Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

19 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Avantages des stratégies SOA Organisation du SI autour de services et non d applications o agilité, capacité à s adapter rapidement au changement o meilleure productivité o réalisation rapide de nouveaux services métier o meilleure réactivité opérationnelle o interopérabilité (c)leuville Objects 2-43

20 Avantages des stratégies SOA Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

21 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Pièges liés à l adoption de SOA o Bâtir une architecture SOA comme une architecture distribuée o avoir des couplages forts, avec des services RPC et/ou synchrones o Ne pas standardiser SOA au niveau de l entreprise o choisir des extensions WS-X incompatibles o ne pas standardiser les formats de données o Ne pas planifier la transition vers SOA o Ne pas avoir normalisé l emploi de XML préalablement o plus important que l emploi de web services o n est pas implicitement lié à l utilisation de web services o Traîter tardivement les surcoûts en termes de temps de traitements o Minorer les problèmatiques de sécurité o Minorer l importance de l offre produit et ne pas tenir compte des différences techniques inhérentes à ces offres (c)leuville Objects 2-45

22 Pièges liés à l adoption de SOA Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

23 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Le bus ESB Enterprise Service Bus = le A de SOA o Gartner Group : "Une infrastructure adaptée aux services Web offrant un support intelligent du routage des communications et de l intermédiation entre des composants métier à liaison souple ou découplés." o Forrester : "Un bus ESB est une infrastructure logicielle essentielle aux SOA tenant lieu de couche intermédiaire de middleware à travers laquelle les services métiers réemployables sont rendus largement disponibles." Caractéristiques essentielles o Basé sur les Services Web et XML o Gestion fiabilisée des messages o Mécanismes de transformation des données o Routage intelligent des services et des messages o Gestion de nombreuses connectivités : J2EE JMS, JCA,... MS.NET,... o Outils d administration (c)leuville Objects 2-47

24 Le bus ESB Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

25 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Le bus ESB Composants-clé selon Gartner Group o un Middleware Orienté Messages ou MOM o distribution fiable de messages o couplage faible o des Web Services o abstraction de services métier o indépendants des technologies o un Routage Intelligent des messages o basé sur les contenus et les contextes o basé sur des règles métier o des Transformations XML o de type XSLT (c)leuville Objects 2-49

26 Un bus ESB Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

27 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Le bus ESB «application».net «application» J2EE «application» Legacy «connecteur» SOAP / HTTP «connecteur» JMS / JCA «connecteur» MQ Gateway Enterprise Service Bus «connecteur» SOAP / HTTP «connecteur» SOAP / HTTP Moteur de requêtes distribué «service» Partenaire «webservice» Fournisseur «base de données» SGBD (c)leuville Objects 2-51

28 Le bus ESB Notes Ce type de bus rappelle d anciennes propositions, comme les bus de type CORBA. (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

29 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Le bus ESB : mise en place incrémentale «application» J2EE «application» Legacy PHASE 3 «connecteur» JMS / JCA «connecteur» MQ Gateway ESB ESB ESB ESB «connecteur» SOAP / HTTP «connecteur» SOAP / HTTP «connecteur» SOAP / HTTP PHASE 2 Moteur de requêtes distribué PHASE 1 «service» Partenaire «webservice» Fournisseur «application».net «base de donné... SGBD (c)leuville Objects 2-53

30 Le bus ESB : mise en place incrémentale Notes Un bus ESB peut être mis en place progressivement: o d abord en interne : backend, frontend,... o puis en externe : partenaires, fournisseurs, clients. (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

31 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 Le routage des messages par le bus Service Client Bus ESB Service existant Service Métier Service Proxy Service existant routage Service Client Service Métier Service existant (c)leuville Objects 2-55

32 Le routage des messages par le bus Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

33 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 La standardisation Bases o XML o Web Services : SOAP, WSDL, UDDI Une évolution continue o Trois organismes de standardisation : W3C, OASIS, WS-I o Un grand nombre de spécifications d extensions WS-X o non stabilisé o propositions concurentes, exemple : WS-Reliability / WS-ReliableMessaging o Pas de spécification "chapeau" qui englobe l ensemble des spécifications WS-X o Maturité de certaines spécifications WS-X envisagée pour 2010 Attention : choix délicats (c)leuville Objects 2-57

34 La standardisation Notes (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

35 Architectures Orientées Services - Principes de base et tour d horizon Version 2.0 La standardisation W3C OASIS WS-I Date de création : SGML Open 1998 : OASIS Nombre de membres Objectifs Accompagner l évolution du web, en définissant les standards permettant d améliorer son usage professionnel et les échanges d informations. Travaux principaux XML, XML Schema, XQuery, XML Encryption, XML Signature, XPath, XSLT, WSDL, SOAP, WS-CDL, WS-Addressing, Web Services Architecture Promouvoir le commerce en ligne à l aide de standards appliqués au web services. UDDI, ebxml, SAML, XACML, WS-BPEL, WS-Security, ebsoa 2002 Promouvoir l interopérabilité à l aide de standards appliqués aux web services. Basic Profile, Basic Security Profile (c)leuville Objects 2-59

36 La standardisation Notes Les travaux de ces organismes sont souvent complémentaires, comme par exemple: o WS-Security qui s appuie sur XML Encryption, XML Sugnature,... o UDDI qui fait référence à WSDL, o... (c) Leuville Objects Architectures Orientées Services - Principes de base et tour d horizon 1/30/

37 Architectures Orientées Services Version 2.0 Enterprise Service Bus o Les constituants fondamentaux d un Enterprise Service Bus (ESB) o MOM / Message-Oriented Middleware o Web Services o Routage intelligent o Transformations XML (c) Leuville Objects. Tous droits de traduction, d adaptation et de reproduction par tous procédés, réservés pour tous pays. Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage, faite sans l autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété intellectuelle du 1er juillet 1992, articles L 122-4, L et L 335-2).

38 (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

39 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Le bus ESB Composants-clé selon Gartner Group «application».net «application» J2EE «application» Legacy o Middleware Orienté Messages ou MOM «connecteur» SOAP / HTTP «connecteur» JMS / JCA «connecteur» MQ Gateway o distribution fiable de messages Enterprise Serv ice Bus o couplage faible o Web Services «connecteur» SOAP / HTTP «connecteur» SOAP / HTTP Moteur de requêtes distribué o abstraction de services métier o indépendants des technologies «service» Partenaire «webservice» Fournisseur «base de données» SGBD o Routage Intelligent des messages o basé sur les contenus et les contextes o basé sur des règles métier o Transformations XML o de type XPath et XQuery et/ou XSLT (c)leuville Objects 5-129

40 Un bus ESB Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

41 Architectures Orientées Services - Enterprise Service Bus Version 2.0 MOM o Message-Oriented Middleware Caractéristiques principales MOM o Asynchronisme o Files de stockage des messages 3 Appli A Appli B 2 1 o Différentes modalités d émission / réception des messages Client producteur de message file d attente des messages Client consommateur de message Qualités o Hétérogénéïté des applications clientes o Couplage lâche o Fiabilisation des échanges o stockage des messages o gestion des acquittements et qualité de service (c)leuville Objects 5-131

42 MOM Définition o Un MOM permet de manipuler des messages et de les échanger d une application à une autre. o Les applications communiquent entre elles via ce système de messagerie et n ont donc pas besoin de se "voir" les unes les autres. Propriétés o Les implémentations sont nombreuses. Parmis les fournisseurs : o IBM WebSphere MQ o BEA WebLogic Server JMS o JBoss Messaging o OpenJMS o Ces systèmes proposent un fonctionnement en mode synchrone (attente et récupération des messages) ou asynchrone (modèle Listener). o Il est également possible de contrôler que tout message est traité une et une seule fois (politiques d acquittements). Le niveau de contrôle peut être réduit pour les applications acceptant la perte ou la duplication de messages. (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

43 Architectures Orientées Services - Enterprise Service Bus Version 2.0 MOM : domaines de messagerie Deux domaines de messagerie supportés, un type de destination pour chacun o Point à Point (PTP) o Publish / Subscribe Messagerie Point à Point (PTP) o Destination de type Queue msg envoie Client 1 Queue Client 2 msg consomme acquittement (c)leuville Objects 5-133

44 MOM : domaines de messagerie Messagerie Point à Point Messagerie Point à Point : Chaque message est adressé à une queue spécifique. Les clients lisent cette queue afin d en extraire les messages. Les queues conservent les messages qui leur sont envoyés jusqu à ce qu ils soient lus ou périmés. Un message est consommé dès qu il est lu par un client, quel qu il soit. Chaque message ne peut être consommé qu une seul fois Les processus emetteur et destinataire du message peuvent ne pas être exécutés en même temps. Le message envoyé sera conservé jusqu à ce que le destinataire l extrait de la queue. Le destinataire peut envoyer un message d acquittement pour signaler la fin du traitement du message (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

45 Architectures Orientées Services - Enterprise Service Bus Version 2.0 MOM : domaines de messagerie Système publication / souscription (publish/subscribe) o Mode permettant la diffusion à plusieurs destinataires o Destination de type Topic souscrit délivre Client 2 publie Client 1 Topic msg msg souscrit délivre Client 3 msg (c)leuville Objects 5-135

46 MOM : domaines de messagerie Système publication / souscription (pub/sub) Le message est publié dans un "Topic". Les destinataire du messages sont les clients ayant souscrit au topic. Le système transmet automatiquement tout message souscrit dans un topic aux clients y ayant souscrit. Les messages sont conservés le temps qu ils soient distribués à tous les clients. Chaque message peut être consommé plusieurs fois Les clients souscrivant à un topic ne peuvent consommer que les messages ayant été publiés après leur souscription. Le souscrivant doit être actif au moment de la publication du message pour que celui-ci lui soit délivré. (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

47 Architectures Orientées Services - Enterprise Service Bus Version 2.0 MOM : exemple JMS Java Message Service o spécification permettant de découpler les clients Java d un MOM d un type de MOM particulier o normalise: o les domaines de messagerie o les modalités de connexion au MOM o les modalités d émission / réception o les formats des messages o améliore la portabilité des applications o implémentée par de nombreux fournisseurs o IBM o BEA o JBoss o... (c)leuville Objects 5-137

48 MOM : exemple JMS Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

49 Architectures Orientées Services - Enterprise Service Bus Version 2.0 MOM : exemple JMS Java Message Service o Fournisseur JMS (JMS Provider) : implémentation de l API JMS o Client JMS : produit et/ou consomme des messages o Message : objet véhiculant des informations entre clients JMS o Objets administrés : les fabriques de connexion (Connection Factory) et les destinations sont configurées et placées dans un contexte JNDI par un administrateur (c)leuville Objects 5-139

50 MOM : exemple JMS Notes Les fabriques de connexion et les destinations sont placées dans un espace de nommage JNDI par un administrateur. Un client JMS peut alors récupérer une référence sur ces objets (look up) et établir une connexion logique via le fournisseur JMS. (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

51 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Web Services Les besoins o Permettre les échanges interentreprises et inter-systèmes o Avoir une réelle inter-opérabilité indépendante des contraintes techniques : système, langage,... o Ne pas perturber l existant au niveau des infrastructures de gestion de la sécurité La solution J2EE PERL C++ FOURNISSEUR FOURNISSEUR TRANSPORTEUR Coupe-feu Coupe-feu Coupe-feu Coupe-feu ADMINISTRATION J2EE PRODUCTION.NET o Utiliser l existant plutot qu imposer des changements : HTTP et XML o Constituants essentiels o Un protocole de requétage basé sur un format de données universel : XML et pouvant utiliser HTTP : SOAP o Un langage de description des services : WSDL o Un système d annuaire : UDDI (c)leuville Objects 5-141

52 Web Services Les besoins L inter-opérabilité des systèmes et des applications est un souhait partagé depuis très longtemps par de nombreuses organisations et entreprises. Jusqu à présent, les technologies permettant l invocation distante de services comportaient de très nombreuses contraintes qui rendaient difficile leur utilisation: o incompatibilité des protocoles de communication : CORBA avec DCOM par exemple, o incapacité à traverser les protections pare-feu des entreprises sans modification des règles de sécurité, o lourdeurs de développement et de mise en oeuvre. La solution L idée forte des services WEB consiste à utiliser ce qui existe déjà au niveau des entreprises plutôt qu à proposer de nouvelles solutions trop contraignantes en termes d équipements et de procédures: o XML qui est un format de données largement accepté et répandu, o HTTP qui est un procole de communication universel pour lequel les procédures de sécurité réseau des entreprises sont déjà adaptées. (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

53 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Routage Intelligent des messages Exemple de scénario Bus ESB Service "Montants spéciaux" routage Emprunteur Service de "haut niveau" Service "Montants normaux" o un client doit appeler un service permettant d obtenir une offre de crédit bancaire o en fonction du montant à emprunter, sa demande est routée soit vers un service "Montants spéciaux", soit vers un service "Montants normaux" Bus ESB = une sorte de routeur de messages o Fonctionnalités minimales o valider les messages entrants o acheminer les messages en fonction de leur contenu o agréger des résultats pour les retourner aux clients o gèrer les erreurs (c)leuville Objects 5-143

54 Routage intelligent des messages Notes Ces possibilités ne sont pas normalisées pour le moment. (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

55 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Routage Intelligent des messages Fonctionnalités avancées o Pouvoir formaliser des processus métier à l aide d un langage: o structurer un processus en plusieurs étapes o déclarer et affecter des variables, à portée locale ou globale o exécuter des tests o faire des itérations o gérer des états dépendants des utilisateurs o appeler différents types de services pré-existants o agréger des résultats intermédiaires BPEL : Business Process Execution Language o Permet de décrire des processus métier o Standard (c)leuville Objects 5-145

56 Routage Intelligent des messages Notes BPEL est étudié dans un autre chapitre. (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

57 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Routage Intelligent des messages Modalités de définition du routage o Langage propriétaire o Métaphore graphique o Diagrammes UML (diagrammes d activités) o Processus BPEL Possibilités très variables d un bus à l autre. (c)leuville Objects 5-147

58 Routage Intelligent des messages Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

59 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Routage Intelligent des messages: exemple Routage basé sur le contenu o Exemple BEA Aqualogic : routage en fonction d un taux présent dans la requête entrante (c)leuville Objects 5-149

60 Routage Intelligent des messages: exemple Routage basé sur le contenu L exemple présenté ici est exécuté au sein de Aqualogic Service Bus de BEA Systems. L expression permettant d extraire le taux d intérêt de la requête entrante est exprimé à l aide de XQuery/Xpath: $body/exam:processloanapp/loanrequest/java:rate (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

61 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Routage Intelligent des messages: exemple Appel de services intermédiaires o Communication assurée par des variables (c)leuville Objects 5-151

62 Routage Intelligent des messages: exemple Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

63 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Routage Intelligent des messages: exemple Itération (c)leuville Objects 5-153

64 Routage Intelligent des messages: exemple Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

65 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Transformations XML ESB et XML o un ESB héberge des web services qui traitent des requêtes SOAP = XML o des données sont extraites de ces requêtes SOAP o elles sont transformées o et renvoyées aux clients Opérations souhaitées o Ajout d éléments XML o Remplacement d éléments par d autres éléments o Suppression d éléments Moyens techniques o Langages basés sur XML o XPath & XQuery o XSLT (c)leuville Objects 5-155

66 Transformations XML Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

67 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Transformations XML XPath o Constituant principal du standard XSLT du W3C o Permet de naviguer au sein d un arbre XML XQuery o Permet d exécuter des requêtes au sein de données XML XSLT = XSL Transformations o Permet de transformer un document XML en un autre document XML (c)leuville Objects 5-157

68 Transformations XML Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

69 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Transformations XML : insertion Exemple <lg:creditrating> {data($creditrating)} </lg:creditrating>./exam:processloanapp/loanrequest/lg:notes (c)leuville Objects 5-159

70 Transformations XML : insertion Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

71 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Transformations XML : remplacement Exemple o renommage d un namespace dans un corps de requête SOAP (c)leuville Objects 5-161

72 Transformations XML : remplacement Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

73 Architectures Orientées Services - Enterprise Service Bus Version 2.0 Transformations XML : suppression Exemple o suppression de l élément CreditRating de la branche processloanappresponse/return./exam:processloanappresponse/return/lg:creditrating (c)leuville Objects 5-163

74 Transformations XML : suppression Notes (c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 1/30/

75 Architectures Orientées Services Version 2.0 Les pratiques SOA o Architecture SOA en couches o Modèles d intégration ou patterns (c) Leuville Objects. Tous droits de traduction, d adaptation et de reproduction par tous procédés, réservés pour tous pays. Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage, faite sans l autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété intellectuelle du 1er juillet 1992, articles L 122-4, L et L 335-2).

76 (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

77 Architectures Orientées Services - Les pratiques SOA Version 2.0 Architecture Le modèle architectural en couches ou Layered Architectural Model o Couche = regroupement de services similaires en termes de finalité o Couches typiques o Services d accès et d information o Services métier partagés o Services de présentation o Applications composites o Services d infrastructure Source BEA Systems (c)leuville Objects 6-167

78 Architecture Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

79 Architectures Orientées Services - Les pratiques SOA Version 2.0 Services d accès et d information o Couche d intégration des architectures multi-niveaux Accès standardisés o API et connecteurs normalisés : JCA, Web Services A l existant de l entreprise o Systèmes tiers o Serveurs d applications o Applications d entreprise o Systèmes existants : middlewares messages,... o Bases et entrepôts de données (c)leuville Objects 6-169

80 Services d accès et d information Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

81 Architectures Orientées Services - Les pratiques SOA Version 2.0 Services métier partagés Services de haut niveau o utilisent la couche des services d accès et d information o contiennent éventuellement de la logique d orchestration et de coordination Première des deux couches métier o processus métier simples o services à granularité fine (c)leuville Objects 6-171

82 Services métier partagés Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

83 Architectures Orientées Services - Les pratiques SOA Version 2.0 Services de présentation Services de fourniture d une interface utilisateur o Contient des composants réutilisables tels que des portlets o Permet de construire des interfaces orientées processus métier o Peut être utilisée par plusieurs application de type portail (c)leuville Objects 6-173

84 Services de présentation Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

85 Architectures Orientées Services - Les pratiques SOA Version 2.0 Applications composites Seconde couche métier du modèle o Contient des applications complètes ou des composants permettant de construire des applications o Comporte les implémentations des processus métier complexes multi-étapes o S appuie sur la couche des services métier partagés o Services à forte granularité (c)leuville Objects 6-175

86 Applications composites Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

87 Architectures Orientées Services - Les pratiques SOA Version 2.0 Services d infrastructure Services communs o Gestion d erreurs o Gestion des traces o Sécurité Bus ESB o Routage des messages o Transformation de données o Reprise sur panne Administration o Versionnage, gestion des déploiement,... o Qualité de service (c)leuville Objects 6-177

88 Services d infrastructure Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

89 Architectures Orientées Services - Les pratiques SOA Version 2.0 Le pattern VETO ou VETRO o VETO = Valider Enrichir Transformer Opérer o VETRO = Valider Enrichir Transformer Router Opérer Modèle d intégration o Permet de structurer l emploi du bus par les différents clients o Veille à limiter le couplage entre un service et ses utilisateurs o Sur un plan technique, permet d apparenter le processus d intégration à un ensemble d opérations de paramétrage o sélection des endpoints ou destinations des messages o paramétrage des processus de validation, enrichissement et transformation XSD - XPath - XQuery (c)leuville Objects 6-179

90 Le pattern VETO ou VETRO Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

91 Architectures Orientées Services - Les pratiques SOA Version 2.0 Le pattern VETO ou VETRO Modèle d emploi d un bus ESB o Validate : validation des données XML entrantes, par exemple avec un schéma XSD o Enrich : ajout éventuel de données compémentaires, par appel à une source externe telle qu un autre service, une base de données,... o Transform : modification des données en vue de respecter le structure imposée par le service cible o Route (optionnel) : choix du service cible en fonction de règles, par exemple sur le contenu... o Operate : envoi du message au service cible (c)leuville Objects 6-181

92 Le pattern VETO ou VETRO Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

93 Architectures Orientées Services - Les pratiques SOA Version 2.0 Praxeme Une méthode publique o Association loi 1901: Praxeme Institute o Objectifs : o aider les entreprises à mettre en oeuvre des architectures SOA o devenir un socle méthodologique de référence pour les architectures SOA o Origine : Unilog Management, Orchestra Networks, Softeam, Conix Consulting, Dreamsoft, Vistali o Contributeurs : Calyon, Armée de Terre, CNAF, SMABTP Caractéristiques o Méthode ouverte o Adaptable aux besoins et à la culture des entreprises o Permet de modéliser: architecture logique, architecture physique, architecture technique Nécessite plus de recul. (c)leuville Objects 6-183

94 Praxeme Notes (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

95 Architectures Orientées Services - Les pratiques SOA Version 2.0 Praxeme Topologie du Système d Informations o Règles de dérivation des modèles (c)leuville Objects 6-185

96 Praxeme Notes D après (c) Leuville Objects Architectures Orientées Services - Les pratiques SOA 1/30/

97 Les Services Web Version 1.3 Les extensions WS-X o WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity o WS-BPEL (BPEL4WS initialement) o WS-CDL (WS-Choreography initialement) o WS-Addressing o WS-ReliableMessaging o... (c) Leuville Objects. Tous droits de traduction, d adaptation et de reproduction par tous procédés, réservés pour tous pays. Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage, faite sans l autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété intellectuelle du 1er juillet 1992, articles L 122-4, L et L 335-2).

98 (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

99 Les Services Web - Les extensions WS-X Version 1.3 Les transactions et les Services Web Différents niveaux o Transaction "locale" à un Web Service o Transaction distribuée impliquant plusieurs Web Services Une spécification "Web Services Transactions" o Un framework de coordination : WS-Coordination o propagation de contextes transactionnels au sein des web services o protocoles de coordination o Deux types de coordinations: o WS-AtomicTransactions pour les transactions dites ACID o WS-BusinessActivity pour les transactions métier à longue durée de vie (c)leuville Objects 9-283

100 Les transactions et les Services Web Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

101 Les Services Web - Les extensions WS-X Version 1.3 WS-Coordination Concept d activité o Activité = tâche ou unité de travail assurée par un ensemble de Services Web o Informations de contexte associées : identifiants, données,... o Assimilable à un processus métier de haut niveau Complexité d une activité o liée au nombre de services participants o liée à la durée de l activité o liée à la fréquence des modifications de nature de l activité o liée à la possibilité d existence concurrente de plusieurs occurences de l activité Nécessité d un framework de gestion des activités : WS-Coordination o Gestion et transmission des informations de contexte entre les participants d une activité (c)leuville Objects 9-285

102 WS-Coordination Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

103 Les Services Web - Les extensions WS-X Version 1.3 WS-Coordination Architecture et services o Activation o permet la création de contextes o un contexte permet d inviter d autres services à participer à l activité o Enregistrement o permet à un participant de s enregistrer pour participer à une activité o l enregistrement nécessite le contexte envoyé par l application ayant réalisé l activation o fournit l adresse du service de coordination o Gestion de protocoles o propose un ensemble de protocoles de coordination o 2 par défaut : WS-AtomicTransaction et WS-BusinessActivity o Coordination : service de contrôle avec lequel tous les participants interagissent (c)leuville Objects 9-287

104 WS-Coordination Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

105 Les Services Web - Les extensions WS-X Version 1.3 WS-Coordination : activation et enregistrement Service Applicatif 1: demande de création contexte contexte Service d Activation 2: enregistrement 3: demande participation (contexte) adresse coordinateur Service Participant 4: enregistrement Service d Enregistrement adresse coordinateur (c)leuville Objects 9-289

106 WS-Coordination : activation et enregistrement Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

107 Les Services Web - Les extensions WS-X Version 1.3 WS-Coordination : fin d activité Service Applicatif requête de fin d activité acquittement Service de Coordination fin fin Service acquittement Participant Service Participant acquittement Autres services participants (c)leuville Objects 9-291

108 WS-Coordination : fin d activité Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

109 Les Services Web - Les extensions WS-X Version 1.3 Deux types de coordinations WS-AtomicTransaction o Transactions analogues aux transactions distribuées 2PC de type ACID o Transactions à durée de vie courte o Possibilités d annulation WS-BusinessActivity o Transactions à longue ou très longue durée de vie o Pas de possibilités d annulation... o... mais mécanismes de compensation fournis par chaque service participant o Une activité de ce type peut contenir plusieurs activités de type WS-AtomicTransaction (c)leuville Objects 9-293

110 Deux types de coordinations Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

111 Les Services Web - Les extensions WS-X Version 1.3 WS-Coordination : implémentation D après IBM DeveloperWorks (c)leuville Objects 9-295

112 WS-Coordination : implémentation Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

113 Les Services Web - Les extensions WS-X Version 1.3 Exemple de contexte WS-Coordination <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Header>... <wscoor:coordinationcontext xmlns:wsme=" xmlns:wscoor= xmlns:myapp=" <wsme:identifier> <wsme:expires> t13:20: :00</wsme:expires> <wscoor:coordinationtype> </wscoor:coordinationtype> <wscoor:registrationservice> <Address> </Address> <myapp:betamark>... </myapp:betamark> <myapp:ebdcode>... </myapp:ebdcode> </wscoor:registrationservice> <myapp:isolationlevel>repeatableread</myapp:isolationlevel> </wscoor:coordinationcontext>... </S:Header> (c)leuville Objects 9-297

114 Exemple de contexte WS-Coordination Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

115 Les Services Web - Les extensions WS-X Version 1.3 L orchestration des Services Web Un besoin : l intégration o Concept déjà présent dans d autres techniques : EAI, middleware,... o Fédérer différentes applications et systèmes d informations de l entreprise - > architectures SOA Caractéristiques d une orchestration o Service Web de haut niveau résultant de l assemblage d autres Services Web o Implémentation centralisée d un processus métier appartenant à une seule organisation o Décrite avec Business Process Execution Language (WS-BPEL) (c)leuville Objects 9-299

116 L orchestration des Services Web Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

117 Les Services Web - Les extensions WS-X Version 1.3 WS-BPEL Conçu pour modéliser des workflows o langage de définition de processus métier et de workflows o permet d écrire des programmes qui sont des services web, et qui consomment des services web o basé sur XML Eléments principaux o <process> : élément racine d une définition WS-BPEL d un processus métier, contient les éléments suivants o <partnerlink> : permet de décrire les échanges entre deux partenaires = deux services web o <variables> : permet de définir des moyens de stocker des informations d état relatives à la logique métier o <sequence> : permet de définir une série d activités à exécuter o <invoke> : invoque un service o <receive> et <reply> o <switch> <case> <otherwise> o <assign> o <copy> <from> <to> (c)leuville Objects 9-301

118 WS-BPEL Notes WS-BPEL définit un langage de programmation orienté workflow entre services web. (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

119 Les Services Web - Les extensions WS-X Version 1.3 La chorégraphie des Services Web Echanges entre organisations o concerne les interactions B2B par échanges de messages publics o autorise des collaborations entre orchestrations WS-CDL o Langage de Description de Chorégraphie o Considéré comme un complément à WS-BPEL (c)leuville Objects 9-303

120 La chorégraphie des Services Web Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

121 Les Services Web - Les extensions WS-X Version 1.3 Autres extensions WS-Addressing o Améliore la définition de l adressage des messages : origine, endpoint, identité d un destinataire,... WS-ReliableMessaging o Introduit des notions de qualité de service : distribution garantie WS-MetadataExchange o Définit un moyen d obtenir des méta-informations sur un service : WSDL,... WS-Security o Apporte un possibilité de sécuriser SOAP de façon intrinsèque WS-Policy o Lié à WS-Security o Permet de définir des règles d usage, des pré-requis, (c)leuville Objects 9-305

122 Autres extensions Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

123 Les Services Web - Les extensions WS-X Version 1.3 WS-Addressing Suivi du transport des messages SOAP o Provenance d un message o permet d identifier l émetteur o permet de lui envoyer une réponse (callbacks) o Adresse de destination o Identification du destinataire à cette adresse de destination o Adresse alternative en cas de problème Informations WSDL insuffisantes Caracteristiques o Headers SOAP dédiés (Message Information Headers) o Définition de la notion de référence à un endpoint Spécification W3C (c)leuville Objects 9-307

124 WS-Addressing Notes Le groupe de travail à l origine de la spécification comporte des acteurs tels que BEA, CA, HP, IBM, Iona, JBoss, Microsoft, Oracle et Sun. Cette spécification était en concurrence avec WS-MessageDelivery, initialement soutenue par Sun. (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

125 Les Services Web - Les extensions WS-X Version 1.3 WS-Addressing Permet l introspection d un endpoint o pour déterminer son nom <EndpointReference> <Address>xs:anyURI</Address> o pour connaître ses propriétés </EndpointReference> Utilisée par o WS-Eventing <NotifyTo>endpoint-reference</NotifyTo> o WS-Distributed Management (c)leuville Objects 9-309

126 WS-Addressing Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

127 Les Services Web - Les extensions WS-X Version 1.3 WS-Addressing: endpoint reference Se compose des éléments suivants o adresse : URL du service web destinataire o propriétés : ensemble de propriétés valuées o exemple : identification d un destinataire o paramètres : transmis au service appelé o service port type : informations permettant d élaborer une réponse o "policy" WS-Policy Seule l adresse est obligatoire. (c)leuville Objects 9-311

128 WS-Addressing: endpoint reference Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

129 Les Services Web - Les extensions WS-X Version 1.3 WS-Addressing : Message Information Headers Nouvel entête SOAP comportant : o destination : l adresse à laquelle est envoyé le message o source endpoint : référence au endpoint émetteur Service B Service A o reply endpoint : référence au endpoint destinataire des réponses o fault endpoint : référence au endpoint destinataire des notifications d erreurs o message id : identifiant unique d un message destination : B source : A réponse : pour C erreur : pour D Service C o relationship : identifiant du message auquel ce message est associé, dans le cas d un scénario requête-réponse o action : URI indiquant "l intention" du message, analogue à l entête HTTP SOAP-ACTION Service D Avantages o l acheminement des messages est porté par SOAP et non plus par le protocole de transport sous-jacent o plus de clarté o plus d indépendance o la logique d acheminement peut-être gérée dynamiquement : scalabilité (c)leuville Objects 9-313

130 WS-Addressing : Message Information Headers Notes Cet entête est parfois appelé MI header. (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

131 Les Services Web - Les extensions WS-X Version 1.3 WS-ReliableMessaging Fiabiliser la transmission des messages o savoir si un message est bien arrivé à destination o savoir qu un message n est pas arrivé et nécessite un nouvel envoi o contrôler qu un ensemble de messages est arrivé dans le même ordre que celui utilisé lors de l envoi o indépendamment du protocole de transport Contenu de la spécification o pas d utilisation d un service tiers de coordination o règles définies au sein d entêtes SOAP o notion d acquittement : sequence acknowledgement, request acknowledgement, negative acknowledgement,... o terminologie spécifique : o RM source, RM destination, application source, application destination o "send", "transmit", "receive", "deliver" (c)leuville Objects 9-315

132 WS-ReliableMessaging Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

133 Les Services Web - Les extensions WS-X Version 1.3 WS-ReliableMessaging Publiée en mars 2003 o Microsoft o IBM o BEA o Tibco Travaux similaires ou connexes o WS-Reliability de Sun Microsystems et Oracle o publiée en janvier 2003 o proposée à l OASIS o HTTP-R d IBM pour fiabiliser l emploi de SOAP sur HTTP (c)leuville Objects 9-317

134 WS-ReliableMessaging Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/

135 Les Services Web - Les extensions WS-X Version 1.3 WS-ReliableMessaging Principes et terminologie o application source : endpoint d envoi du message à un RM source Application source Application destination o RM source : endpoint de transmission qui effectue la transmission physique du message o RM destination : endpoint de réception qui distribue le message à l application destination send transmit RM source RM destination acknowledge receive o application destination : endpoint de distribution Acquittements o une séquence de messages est marquée par la présence d un identifiant de "dernier message" o RM destination émet alors une sequence d acquittements indiquant quels sont les messages effectivement reçus o RM source prend alors la responsabilité de renvoyer ou non les messages manquants o request acknowledgement : pour demander un acquittement intermédiaire, à l initiative de RM source o negative acknowledgement : transmis à l initiative de RM destination pour indiquer un échec (c)leuville Objects 9-319

136 WS-ReliableMessaging Notes (c) Leuville Objects Les Services Web - Les extensions WS-X 1/30/