LOG8430 : Architecture logicielle et conception avancée

Transcription

1 LOG8430 : Architecture logicielle et conception avancée Yann-Gaël Guéhéneuc Introduction à aux architectures orientées services (Contributeurs : Occello, 2007; Khomh, ; Soh, 2014; Guéhéneuc, 2015) This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported License

2 Introduction aux architectures orientées services (SOA) Contexte d intégration Principes de base du SOA Points clés de l architecture SOA Cycle de vie d un service Avantages et inconvénients Méthodes et outils permettent la mise en œuvre d une architecture orientée services Références 2/54

3 1. Contexte d intégration Les systèmes logiciels reflètent très souvent l organisation de l entreprise Processus métiers des entreprises sont de plus en plus multi-départementaux Quels problèmes? Redondance dans les systèmes logiciels Coûts considérables dans la gestion des flux entre départements et dans l intégration de leurs systèmes logiciels 3/54

4 1. Contexte d intégration Développements coûteux Interconnexions redondantes (point à point) Grande complexité Maintenance difficile Réutilisation difficile (couplage fort) 4/54

5 1. Contexte d intégration Les entreprises doivent s adapter en permanence aux variations des marchés Fusions Acquisitions Etc. Les variations du marché ont un impact sur les systèmes des entreprises Leurs systèmes logiciels ne doivent pas être un frein à ces changements 5/54

6 Qu est ce qu une SOA? Un ensemble de services que l'entreprise souhaite exposer à leurs clients et partenaires, ou d'autres parties de l'organisation Dirigeants Analystes métier Un style architectural basé sur un fournisseur, un demandeur et une description de service, et supporte les propriétés de modularité, encapsulation, découplage, réutilisation et composabilité Architectes Un modèle de programmation avec ses standards, paradigmes, outils et technologies associées Développeurs Un intergiciel offrant des fonctionnalités en terme d'assemblage, d'orchestration, de surveillance et de gestion des services Chaque rôle s'approprie les SOA différemment Intégrateurs 6/54

7 Qu est ce qu une SOA? Assembleur Langages machine Langages procéduraux objets * * composants services services Les SOA sont une évolution des paradigmes précédents 7/54

8 2. Principes de base des SOA SOA est une évolution des plates-formes Elle préserve les caractéristiques réussies des architectures traditionnelles Tout en y ajoutant quelques principes nouveaux SOA est un paradigme abstrait, base de l architecture distribuée sans aucune référence à une implémentation technique Elle est souvent implémentée sous forme de Web Services, mais pas obligatoirement 8/54

9 2. Principes de base des SOA Dans SOA il y a «Service» Qu est ce qu un service? Un service doit être "abstrait" : il n est pas lié à une implémentation Ex. : Service d'enregistrement d'un abonné Service de réservation d'un billet d avion Service de diffusion d'information 9/54

10 Qu est ce qu un service? Partage des caractéristiques des objets Modulaire (fonctionnalités cohérentes) Partage des caractéristiques des composants Boite noire (séparation interface/implémentation) Indépendant de la localisation Neutralité vis-à-vis des protocoles de transport Correspond à un périmètre fonctionnel que l on souhaite exposer à des consommateurs Expose un petit nombre d opérations offrant un traitement de bout en bout Est sans état Est faiblement couplé (indépendant d autres services) 10/54

11 Exemple de couplage fort Entités LoanAgent LoanApproval Account Loan SMSGateway calculaterisk checkcredit createloan sendconfirmation LoanAgent est lié à LoanApproval LoanApproval est lié à Account Loan est lié à SMSGateway 11/54

12 Gestion de prêts en couplage faible Services LoanProcess CheckAccount Balance Calculate LoanRisk CreateLoan Notify ViaSMS Qu est ce que LoanProcess? Un processus métier! Il permet d orchestrer les services => couplage faible 12/54

13 Application vs. Service 13/54

14 Quatre propriétés des services Un Service est autonome et sans état Un Service expose un contrat in out Conditions d utilisation, Contraintes (contrat opérationel) Vos droits/vos devoirs Les frontières entre services sont explicites Les services communiquent par messages 14/54

15 Conséquences de ces propriétés Une SOA transmet des messages Pas des objets Le consommateur (client) est découplé de l architecture technique du service qu il invoque Le consommateur et le fournisseur n'ont pas forcément les mêmes technologies 15/54

16 2. Principes de base du SOA Au cœur des SOA on a donc Des services Des processus 16/54

17 2. Principes de base du SOA Processus métier «Un ensemble d'activités qui s'enchaînent de manière chronologique pour atteindre un objectif, généralement délivrer un produit ou un service, dans le contexte d'une organisation de travail» Wikipédia Un flux d'informations au sein d'une organisation Une vue transversale sur les activités de l'entreprise 17/54

18 Exemple de processus (notation informelle) 18/54

19 Business Process Management But : donner à l entreprise les moyens de gérer ses processus métiers de manière informatisée (modélisation, simulation, exécution et audit) Optimisation, adaptation aux besoins en temps réel Un processus est le résultat d une orchestration de service Le processus est lui-même accessible en tant que service Un processus est composé de sous processus, de décisions (Business rules) et d activités Un sous processus a son propre but, entrées et sorties Les activités Correspondent aux parties du processus métier sans décision, associées à des rôles Sont réalisées par des systèmes ou des humains Des mesures (KPI: Key Performance Indicators) permettant de capturer les performances du processus 19/54

20 BPM par l exemple 20/54

21 Les couches SOA * Ces différents modes de couplage sont nécessaires et dépendent du niveau dans l architecture Couplage fort Couplage faible au niveau technique ou au niveau logique : vision composants Ex: 21/54 Couplage faible au niveau logique

22 22/54 Presentation Layer CartController AccountController Business Logic Layer Account Cart Inventory Item OrderInsert OrderRead Product Profile Category Check out Create Account Default Error Help Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOut Shopping Cart Search SignIn Exemple d un e-store : couches Data Access Layer IAccount IInventory IItem IOrder IProduct IProfile

23 Exemple d un e-store : domaines Default Presentation Layer SignOut SignIn Search Category Items Item Details Shopping Cart Help Error My Account Edit Account Create Account Check out Order Billing Order Shipping Order Process Business Logic Layer Account Profile Product Item Inventory Cart OrderInsert OrderRead Data Access Layer IAccount IProfile IProduct IItem IInventory IOrder Customer Catalog Inventory Shopping Billing23/54

24 Exemple d un e-store : domaines Presentation Layer Business Logic Layer Data Access Layer Customer Catalog Inventory Shopping Billing24/54

25 Exemple d un e-store : Services Presentation Layer Business Logic Layer Service Layer Manage Customer Show Catalog Make Inventory Shop Bill Data Access Layer 25/54

26 3. Points clés de l architecture SOA 1.a Search for service Service consumer 1.b Return contract Contract Repository 2.a Create a process instance Mediation layer/service bus Service provider 2.d Send request 2.b Execute process Business service orchestrator 2.c Retrieve service end-point Business process description Registry 26/54

27 3. Standards de l architecture Les standards sont un élément clé d une SOA, ils assurent l interopérabilité SOAP W3C Simple Object Access Protocol WSDL W3C Web Services Description Language UDDI Microsoft, IBM, HP Universal Description Discovery and Integration BPEL Oasis Business Process Execution Language Transporte Décrit le contrat Spec pour Repository/Registry Décrit les processus métier Les trois piliers des Services Web 27/54

28 SOA et web services Attention à ne pas confondre les deux! SOA est un ensemble de concepts Une SOA peut être mise en œuvre sans Web Services Les WS sont de l ordre de la technologie On peut utiliser les Web Services sans faire de SOA Les WS constituent la meilleure solution standardisée disponible Un service métier = un Web Service 28/54

29 Le langage BPEL Standard de l OASIS Permet de décrire des processus en XML Propose les fonctions basiques d un langage de programmation Sequence, flow, loop, switch Identification des instances de processes Gestion des transactions longue durée (scope, compensation) Gestion des fautes 29/54

30 BPEL, le chef d orchestre 30/54

31 BPEL par l exemple <PartnerLink> references to the services participating in the process flow <invoke> a credit rating service synchronously PartnerLink <faulthandlers> catch and manage exceptions when customer has a bad credit history <flow> initiates asynchronous loan processors in parallel of execution PartnerLink flow PartnerLink <switch> to the lowest loan offer <receive> asynchronous callbacks from longrunning loan processors 31/54 loan.bpel

32 4. Cycle de vie d un service 4 grandes phases Identification Spécification Développement Gestion Un aspect transversal : la gouvernance Les architectures orientées service impliquent une vision globale La gouvernance permet de casser les barrières organisationnelles de l entreprise 32/54

33 4. Cycle de vie des services (gouvernance) Service Identified Search for Existing Implementation exists? yes no Service Identification Service Owner Approval Service reusability Commission Candidate Consumers Identified Service Specification Created Provider Interfaces Documented Service/Process Workflow Created Service Specification Service Specification Review Develop Components Integrate & Test Create Deployment Unit Acceptance Test Code in repository Service Development Certify Service Service in registry Service in use Monitor service Plan New Version Decommis sion Service Deprecate Service Service Management 33/54

34 Rôles associés au cycle de vie Identification Analyste métier Définit les processus métiers et les KPI associées Identification des services métier Optimise les processus via la simulation Assemble les services Développement Intégrateur Spécification Définit les services pour les use cases Modélise les services Implémente les services Développement Architecte Développeur Gestion Gestionnaire Publie les services Gère le cycle de vie des services Contrôle la qualité de service 34/54

35 Phase d identification Un des problèmes principaux pour mettre en œuvre SOA La granularité des services est fondamentale Détermine en grande partie la réutilisabilité des services Succès SOA = % de réutilisation des services Éviter une granularité trop fine qui entraîne Beaucoup d interactions Des problèmes de performance On recommande des services à gros grain Attention à une granularité trop épaisse Un service qui fait trop de chose, risque de ne pas être réutilisable Trouver le juste milieu 35/54

36 Méthodes d identification Une première phase d'indentification doit être effectuée sur l'ensemble du système en s'appuyant sur les domaines métiers de l'entreprise et sur le code existant Approche bottom-up On part des briques informatiques, on rassemble les bouts (abstraction) Plus adéquat pour réutiliser l existant non SOA Approche incrémentale : une phase d'identification est nécessaire au démarrage de chaque nouveau projet SOA en s'appuyant sur les processus et services répertoriés précédemment Approche Top-down On part des interactions métier pour aboutir aux interactions techniques Plus adéquat pour démarrer un nouveau projet 36/54

37 Approche Bottom Up Besoins Legacy applications Diagrammes d'activités Décomposition du diagramme de classes Orchestration Specification des services Nouveaux Services + services réutilisables (l'existant) Nouvelle application 37/54

38 Approche Top Down Besoins Analyse des domaines métiers Décomposition du processus métier Orchestration Specification des services Nouveaux Services + services réutilisables (l'existant) Nouvelle application 38/54

39 Approche Outside in Dans la pratique, on utilise les deux approches Pour obtenir une granularité pertinente des services, il est nécessaire de concilier les deux Faire l analyse Top-down sans considérer l existant Faire l analyse Bottom-up en ne considérant que l existant Comparer les services remontés avec ceux déduits des processus Faire les compromis nécessaires pour réutiliser le maximum de code 39/54

40 Phase de spécification Tous les services identifiés ne doivent pas être publiés Chaque service a un coût et un risque Il faut éviter la prolifération des services Le Service Litmus Test d'ibm aide à trouver les bons services à exposer Candidate Services Business Alignment Composability Externalized Service Description Redundancy Elimination SLT Services (exposed) 40/54

41 Quelques critères d'exposabilité Le potentiel d'un service est d'autant plus important qu'il Permet d'automatiser un processus métier critique Est réutilisable par plusieurs domaines métiers Remplace une application désuète Supporte des besoins non fonctionnels (sécurité, logging, monitoring...) 41/54

42 Location de véhicules : services exposés 0.Rent Vehicle 1.1 Reserve Vehicle 1.2 Check-out Vehicle 1.3 Check-in Vehicle Check Rates Make Reservation Locate Reservation Modify Reservation Create Rental Agreement Sign-out Vehicle from Lot Locate Rental Agreement Process Return Information Process Payment Return Vehicle to Lot Confirm Rental Information Get Customer Information Get Payment Information Confirm Reservation Create Reservation Get Location (Pick-up/drop-off) Get Date / time (Pick-up/drop-off) Choose Vehicle Get Options Information Check Vehicle Availability Offer Rates For Selection 42/54

43 Quels sont les services exposables? A basic calculator for performing simple arithmetic operations (+, -, *, /) A printing application, shared by multiple applications, running in multiple environments A credit card authorization application A database lookup that returns application-specific data A composite database lookup for customer information, searching across multiple databases 43/54

44 Huit principes de bases d une SOA Standardized service contract : le contrat de service adhérent à un accord de communication, collectivement défini avec un ou plusieurs documents de description Service loose coupling : faible couplage des services avec la maintenance d une relation réduisant les dépendances Service abstraction : l abstraction des services doit dissimuler la logique du service à l extérieur Service reusability : réutilisation des services partageant la logique entre plusieurs services avec l intention de promouvoir la réutilisation 44/54

45 Huit principes de bases d une SOA Service autonomy: services have control over the logic they encapsulate Service statelessness: services minimize resource consumption by deferring the management of state information when necessary Service discoverability: services are supplemented with communicative meta data by which they can be effectively discovered and interpreted Service composability: services are effective composition participants, regardless of composition size and complexity 45/54

46 5. Avantages des SOA : bénéfices métier Améliorer l agilité et la flexibilité du métier Faciliter la gestion des processus métier Offrir la capacité à casser les barrières organisationnelles (silos) Réduire en temps le cycle de développement des produits Améliorer le retour sur investissement Accroître les opportunités de revenu 46/54

47 5. Avantages des SOA : bénéfices techniques Réduire la complexité de la solution Construire les services une seule fois et les utiliser fréquemment Garantir une intégration standardisée et le support de clients hétérogènes Faciliter la maintenabilité 47/54

48 5. Inconvénients des SOA Difficile à tester Risque de prolifération des messages (entre services) Risque liés à la sécurité des messages provenant de sources diverses 48/54

49 6. Conception des services SOMA (IBM) SODA (De Gamma) Praxeme (Unilog Management et Orchestra Networks) Plus toutes les formations proposées par les éditeurs tels que Softeam (SEA), DreamSoft, etc sur leur savoir-faire Autant d offres que de méthodes différentes : de quoi s y perdre! 49/54

50 Modeleurs de processus Outils de modélisation des processus métier IBM WebSphere Business Modeler Bull Bonita De Gamma BPM MEGA Aris Corporate Modeler WinDesign Power AMC Popkin System Architecture 50/54

51 Moteurs d exécution de processus Plate-forme d intégration IBM Websphere Process Server BEA Weblogic Integrator/Acqualogic Microsoft Biztalk De Gamma Workflow Oracle BPEL PM Bull Orchestra SAP Netweaver ESB IBM Websphere ESB Celtix hosted on ObjectWeb/IONA Technologies OpenESB (java.net) Mule (codehaus.org) Sonic ESB EBM Web Sourcing Distributed Petals Bus (on OW2) 51/54

52 Contrôleurs/moniteurs BAM (Business Activity Monitoring) IBM WebSphere Business Monitor Oracle BAM Systar Business Bridge BMC Service Impact Manager Composants de sécurité Oracle Web Service Manager Oblix 52/54

53 Business Analyst WebSphere Business Modeler BPEL Service Specification Rational Software Architect WSDL Service Architect Developer KPIs Integration Developer WebSphere Integration Developer Service Development Rational Application Developer WebSphere Service Service Registrar Repository & Registry Business Analyst WebSphere Business Monitor Server Administrator WebSphere Process Server WebSphere ESB Service execution & Management Governance Manager Performance Manager WebSphere Business Services Fabric 53/54

54 7. Références Robert Daigneau, Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services Occello Audrey, Introduction à l Architecture Orientée Service, SAR O2/SAR O3 SOA, 2007 Gilbert Raymond, SOA : Architecture Logique :Principes, structures et bonnes pratiques SOA à la sauce IBM 54/54