La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Foutse Khomh ©Occello, 2007; Khomh, 2013 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture.

Présentations similaires


Présentation au sujet: "Foutse Khomh ©Occello, 2007; Khomh, 2013 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture."— Transcription de la présentation:

1 Foutse Khomh ©Occello, 2007; Khomh, 2013 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture logicielle et conception avancée Introduction à lArchitecture Orientée Service (SOA)

2 2/55 Introduction à lArchitecture Orientée Service (SOA) 1. Contexte: Intégration en entreprise. 2. Principes de base du SOA. 3. Points clés de larchitecture SOA. 4. Cycle de vie dun service. 5. Avantages et inconvénients. 6. Méthodes et outils permettent la mise en œuvre dune architecture orientée services. 7. Références.

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

4 4/55 Développements coûteux Interconnexions redondantes (point à point) Grande complexité Maintenance difficile Réutilisation difficile (couplage fort) 1. Contexte: Intégration en entreprise

5 5/55 1. Contexte: Intégration en entreprise Développements coûteux Interconnexions redondantes (point à point) Grande complexité Maintenance difficile Réutilisation difficile (couplage fort)

6 6/55 1. Contexte: Intégration en entreprise Les entreprises doivent sadapter en permanence aux variations des marchés… Leurs systèmes logiciels ne doivent pas être un frein à ces changements lactivité qui pilote la technologie et non linverse

7 7/55 1. Contexte: Intégration en entreprise

8 8/55 1. Contexte: quest ce quune SOA? Chaque rôle s'approprie les SOA différemment… Un ensemble de services que l'entreprise souhaite exposer à leurs clients et partenaires, ou d'autres parties de l'organisation Un modèle de programmation avec ses standards, paradigmes, outils et technologies associées 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é Un intergiciel offrant des fonctionnalités en terme d'assemblage, d'orchestration, de surveillance et de gestion des services DirigeantsAnalystes métier Architectes DéveloppeursIntégrateurs

9 9/55 * * objets * services composants Assembleur Langages machine Langages procéduraux La SOA est une évolution des paradigmes précédents… 1. Contexte: quest ce quune SOA?

10 10/55 SOA est une évolution des plates-formes passées, 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 larchitecture 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. 2. Principes de base du SOA

11 11/55 La SOA représente une architecture ouverte, extensible, fédérée et composable qui promeut une orientation service et qui est composée de services Autonomes Capables de QOS Non liés à des vendeurs Interopérables Potentiellement réutilisables 2. Principes de base du SOA

12 12/55 Dans SOA il y a Service => Quest ce quun service? Un service doit être "abstrait" : il nest pas lié à une implémentation Exemples de services: Service d'enregistrement d'un abonné Vidéotron. Service de réservation d'un billet davion. Service de diffusion d'information. 2. Principes de base du SOA

13 13/55 Partage les caractéristiques suivantes dun objet Modulaire (ensemble de fonctionnalités qui font sens) Partage les caractéristiques suivantes dun composant 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 lon souhaite exposer à des consommateurs Est faiblement couplé (indépendant des autres services) Expose un petit nombre dopérations offrant un traitement de bout en bout Sans état Quest ce quun Service (au sens SOA)?

14 14/55 Un Service expose un contrat Conditions Générales de Vente Règlement Intérieur Vos droits/Vos devoirs in out Un Service est autonome et sans état Quatre propriétés du service à retenir… Les frontières entre services sont explicites Les services communiquent par messages

15 15/55 Conséquences de ces propriétés Une SOA véhicule des messages et non des objets Le consommateur (client) est découplé de larchitecture technique du service quil invoque Le consommateur et le fournisseur n'ont pas forcément les mêmes technologies

16 16/55 Exemple de couplage fort : Gestion de prêts LoanAgent calculateRisk LoanAccount createLoan checkCredit LoanApprovalSMSGateway sendConfirmation Entités LoanAgent est lié à LoanApproval et Loan LoanApproval est lié à Account Loan est lié à SMSGateway

17 17/55 Gestion de prêts en couplage faible LoanProcess CreateLoan CheckAccount Balance Calculate LoanRisk Notify ViaSMS Services Quest ce que LoanProcess ? Un processus métier ! Il permet dorchestrer les services => couplage faible

18 18/55 Au cœur des SOA on a donc: des Services et des processus =>Comment gérer les processus? 2. Principes de base du SOA

19 19/55 Business Process Management (BPM) 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 composé de sous processus, de décisions (Business rules) et dactivités Un sous processus a son propre but, entrées et sorties Les activités correspondent aux parties du processus métier qui nincluent pas de décision et sont associées à des rôles Sont réalisées par des systèmes ou des humains Des mesures (KPI pour Key Performance Indicators) permettent de capturer les performances du processus Un processus est le résultat dune orchestration de service Le processus est lui-même accessible en tant que service

20 20/55 BPM par lexemple

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

22 22/55 Presentation Layer CartControllerAccountController Business Logic Layer AccountCartInventoryItemOrderInsertOrderReadProductProfile Category Check out Create Account Default ErrorHelp Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOutShopping Cart SearchSignIn Exemple dun e-store : Couches Data Access Layer IAccountIInventoryIItemIOrderIProductIProfile

23 23/55 Data Access Layer IAccountIInventoryIItemIOrderIProductIProfile Exemple dun e-store : Domaines Presentation Layer Business Logic Layer AccountCartInventoryItemOrderInsertOrderReadProductProfile Category Check out Create Account Default ErrorHelp Item Details Items My Account Edit Account Order Billing Order Process Order Shipping SignOutShopping Cart SearchSignIn Catalog Inventory ShoppingCustomer Billing

24 24/55 Data Access Layer Presentation Layer Business Logic Layer Exemple dun e-store : Domaines CatalogInventoryShoppingCustomerBilling

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

26 26/55 SOA :des applications, Vue comme des clients d'autres applications

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

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

29 29/55 SOA et web services Attention à ne pas confondre les deux ! –SOA est un ensemble de concepts : Une SOA peut se mettre en œuvre sans Web Services –Les WS sont de lordre 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 webservice

30 30/55 Le langage BPEL Standard de lOASIS Norme permettant de décrire des processus en XML Propose les fonctions basiques dun langage de programmation: –sequence, flow, loop, switch… Identification des Instances de Process Gestion des transactions longue durée (scope, compensation) Gestion des fautes

31 31/55 BPEL le chef dorchestre

32 32/55 flow PartnerLink BPEL par lexemple references to the services participating in the process flow a credit rating service synchronously catch and manage exceptions when customer has a bad credit history initiates asynchronous loan processors in parallel of execution asynchronous callbacks from longrunning loan processors to the lowest loan offer loan.bpel

33 33/55 4. Cycle de vie dun service 4 grandes phases : Identification Spécification Développement Gestion 1 aspect tranversal : la gouvernance Les architectures orientées service impliquent une vision globale La gouvernance permet de casser les silos de lentreprise

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

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

36 36/55 Zoom sur la phase didentification Un des problèmes centraux pour mettre en œuvre une SOA La granularité des services est fondamentale détermine en grande partie la réutilisabilité des services Or succès SOA = % de réutilisation des services Éviter une granularité trop fine qui entraîne : –beaucoup dinteractions –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…

37 37/55 2 méthodes didentification des services Une première phase d'indentification doit être effectuée sur l'ensemble du Système en s'appuyant sur la cartographie des domaines métiers de l'entreprise et sur le code existant. 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 Bottom-up : –On part des briques informatiques, on rassemble les bouts (abstraction) –Plus adéquat pour réutiliser lexistant non SOA-isé Approche Top-down : –On part des interactions métier pour aboutir aux interactions techniques –Plus adéquat pour démarrer un nouveau projet

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

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

40 40/55 Approche Outside in Dans la pratique on utilise rarement une seule approche Pour obtenir une granularité pertinente des services, il est nécessaire de concilier les 2 –Faire lanalyse Top-down sans se préoccuper de lexistant –Faire lanalyse Buttom-up en ne considérant que lexistant –Comparer les services remontés avec ceux déduits des processus –Faire les compromis nécessaires pour réutiliser le maximum de code

41 41/55 Les services identifiés ne doivent pas être tous 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 Zoom sur la phase de spécification

42 42/55 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ésuette – supporte des besoins non fonctionnels (sécurité, logging, monitoring,...) Quelques critères d' exposabilité

43 43/55 Location de véhicules : services exposés

44 44/55 Exemple : 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

45 45/55 8 principes de bases dune 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 dune relation réduisant les dépendances. Service abstraction: labstraction des services dois dissimuler la logique du service à lextérieur. Service reusability: réutilisation des services partageant la logique entre plusieurs services avec lintention de promouvoir la réutilisation.

46 46/55 8 principes de bases dune 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 the size and complexity of the composition.

47 47/55 5. Avantages des SOA: Bénéfices métier Améliorer lagilité 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.

48 48/55 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é.

49 49/55 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.

50 50/55 6. Méthodes de conception des services SOMA (IBM) SODA (De Gamma) Praxeme (Unilog Management et Orchestra Networks) + toutes les formations proposées par les éditeurs tels que Softeam (SEA), DreamSoft, etc sur leur savoir-faire Autant doffres que de méthodes différentes : de quoi sy perdre !

51 51/55 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

52 52/55 Moteurs dexécution de processus Plate-forme dintégration –IBM Websphere Process Server –BEA Weblogic Integrator/Acqualogic –Microsoft Biztalk –De Gamma Workflow –Oracle BPEL PM –Bull Orchestra –SAP Netweaver –Apache ODE 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)

53 53/55 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

54 54/55 Exemple: Gamme d'outils IBM couvrant le cycle de vie complet WebSphere Process Server WebSphere ESB WebSphere Business Modeler WebSphere Integration Developer Rational Software Architect WebSphere Business Monitor WSDLBPEL KPIs WebSphere Service Repository & Registry WebSphere Business Services Fabric Service Specification Service Development Service execution & Management Business Analyst Integration Developer Rational Application Developer DeveloperService Architect Service RegistrarGovernance Manager Performance Manager Server Administrator

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


Télécharger ppt "Foutse Khomh ©Occello, 2007; Khomh, 2013 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture."

Présentations similaires


Annonces Google