Téléchargé parHeithem Abbes
Architectures orientés services (SOA)
L'architecture orientée services (SOA) propose un cadre pour intégrer les systèmes d'information des entreprises en s'appuyant sur des services modulaires et encapsulés. Elle vise à répondre aux défis d'intégration et à favoriser la réutilisation tout en facilitant la gestion des processus métiers. Les essentiels de la SOA incluent des principes de découplage, de modularité et une gouvernance efficace pour assurer l'évolution synchronisée des systèmes avec les objectifs stratégiques de l'entreprise.
Contenu connexe
Similaire à Architectures orientés services (SOA)
Architectures orientés services (SOA)
- 1.
- 2. Chaque rôle s'approprieSOA 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, 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 Dirigeants Analystes métier Architectes Développeurs Intégrateurs 2
- 3. Introduction A quelsbesoins répond le SOA ? Quels sont les principes de base de SOA ? Quelle relation existe t’il entre les services et les composants ? Quels sont les éléments clé d’une architecture orienté services (SOA) ? Quel est le cycle de vie d’un service ? 3
- 4. A quels besoinsrépond le SOA ? 4
- 5. Problématique de l’intégrationen entreprise Les entreprises doivent s’adapter en permanence et être de + en + réactives aux variations des marchées Fusions Acquisitions Scissions Diversification des offres commerciales Changement technologiques Ces opérations ont un impact sur le système d'information (SI) des entreprises L'intégration difficile des SI est un frein à ces changements 5 C’est l’activité qui doit piloter la technologie et non l’inverse
- 6. Besoins métier vscontraintes techniques Création d'applications d'entreprise est très souvent pilotée par des besoins à très court terme Développement d'une application sous tel délai avec telles fonctionnalités 6 Pas de place pour la prise en compte de l'évolution des besoins fonctionnels au niveau de l'application Modélisation et développement dirigé par les choix/contraintes techniques Peu de discussion entre maitrise d'ouvrage (MOA) et maitrise d'œuvre (MOE) Décalage entre besoins métier et leur réalisation
- 7. Réutilisation vs cloisonnement Découpage Prés./Log. Applicative/BD de l'arch. 3-tiers favorise le cloisonnement en silos applicatifs indépendants (blocs monolithiques) Certaines fonctions sont redondantes : une version pour chaque application 7 Pas de mutualisation des développements entre projets et peu de
- 8. Silos et transversalité 8 Entreprises découpées en départements fonctionnels y compris le SI Processus métiers de + en + inter-départementaux Les processus franchissent les frontières de l'entreprise qui doit pouvoir prendre en compte les activités et processus des partenaires pour être réactive Coûts considérables dans la gestion des flux entre départements et dans l’intégration de
- 9. e-store : exemplede processus transverse 9
- 10. Sans SOA :plat de spaghettis 10 Développements coûteux Interconnexions redondantes (point à point) Grande complexité Maintenance difficile
- 11. Avec SOA :Architecture urbanisée11 L’urbanisation informatique définit l'organisation d’un SI à l’image d’une ville découper le SI en modules autonomes (zone, quartier, bloc) localiser les zones d’échange d’informations (routes, ponts, tunnels) qui permettent de découpler les différents modules Objectif : faire évoluer le SI au même rythme que la stratégie et l'organisation des métiers de l'entreprise
- 12. Vers toujours plusd'abstraction Procédures Modèles orientés objets Packages Encapsulation Composants logiciels Assemblages et configuration Et maintenant les services ! 12
- 13. Quels sont lesprincipes de base du SOA ? 13
- 14. Principes fondamentaux del’architecture SOA SOA est une vision stratégique pour le système d’information. Il n’existe pas une recette pour garantir le succès de la mise en place d’une SOA mais des principes à respecter : Discussion entre métier et IT (Technologie de l’Information) Utilisation des use case métier Utilisation de standards Pas de remise en cause de l’existant lors d’évolutions technologiques Découplage entre fournisseur et consommateur de services Indépendance des ressources vis à vis de ceux qui les 14
- 15. Qu’est ce qu’unService (au sens SOA) ? Partage les caractéristiques suivantes d’un objet Modulaire (ensemble de fonctionnalités qui font sens) Partage les caractéristiques suivantes d’un 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 l’on souhaite exposer à des consommateurs (granularité plus forte qu’un composant) Est faiblement couplé (indépendant des autres services) Expose un petit nombre d’opérations offrant un traitement de bout en bout Sans état 15
- 16. Un Serviceexpose un Contrat Les services communiquent par messages Conditions Générales de Vente Règlement Intérieur Vos droits/Vos devoirsin out Un Service est Autonome Les Frontières entre services sont Explicites 4 propriétés du service à retenir 16
- 17. Exemple - Gestionde prêts (par composants) LoanAgent calculateRisk LoanAccount createLoan checkCredit LoanApproval SMSGateway sendConfirmation Composants LoanAgent est lié à LoanApproval et Loan LoanApproval est lié à Account Loan est lié à SMSGateway 17 Couplage fort
- 18. Exemple - Gestionde prêts (avec services) LoanProcess CreateLoanCheckAccount Balance Calculate LoanRisk Notify ViaSMS Services Qu’est ce que LoanProcess ? Un processus métier ! Il permet d’orchestrer les services 18 Couplage faible
- 19. Orienté applications vsorienté services19
- 20. Business Process Management (BPM) Objectif : donner à l’entreprise les moyens de gérer ses processus métiers de manière informatisée (modélisation, simulation, exécution et sécurité) Optimisation, adaptation aux besoins en temps réel Un processus métier a son propre but, entrées et sorties, il est composé de décisions ou règles métier (Business rules) et d’activités métier Les activités correspondent aux parties du processus métier qui n’incluent pas de décision et sont associées à des rôles sont réalisées par des systèmes ou des humains Un processus est le résultat d’une orchestration de services Un processus est lui-même accessible en tant que service 20
- 21.
- 22. Standard BPMN BPMN= Business Process Modeling Notation Standard OMG (Object Management Group) Représentation standard Modélisation autour de la notion de processus métier Création de modèles graphiques du processus métier Réseau d'objets graphiques où les objets représentent des activités qui interviennent dans le processus BPMN et UML 22
- 23.
- 24.
- 25. Bénéfices Bénéfices métier Améliorer l’agilité et la flexibilité du métier Faciliter la gestion des processus métier Réduire en temps le cycle de développement des produits Offrir la capacité à casser les barrières organisationnelles (silos) Améliorer le retour sur investissement Accroître les opportunités de revenu 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é 26
- 26. Quelle relation existe-t'ilentre les services et les composants ? 27
- 27. Convergence Composants / Services Le service désigne le point de vue du consommateur, c’est à dire la vue externe du composant Norme SCA (Service Component Architecture) : un ensemble de spécifications visant à simplifier la création et la composition de services Principe : Notion de composé/composant (composite/component) Initiative : IBM, Oracle, BEA, SAP, Sun, TIBCO, … But : structurer l'implémentation des architectures SOA Implémentations : Apache Tuscany, IBM Websphere, 28
- 28. Service Component Architecture (SCA)29 SCA fournit deux niveaux de modèle: un modèle d’implémentation : construire des composants qui fournissent et consomment des services Un modèle d’assemblage : construire une application métier en liant entre eux un ensemble de composants SCA insiste sur une séparation forte entre l’implémentation des services et leur assemblage SCA permet de décrire des services et leur assemblage indépendamment de toutes considérations techniques d’implémentation
- 29. SCA: modèle d’implémentation 30 Les fonctionnalités sont exposées en tant que services en vue de leur utilisation par d’autres composants Les entrées nécessaires pour le fonctionnement du composant sont appelés références Le composant peut être paramétrable au travers de propriétés qui influencent le Composant : élément de base de SCA, unité élémentaire de construction de l’application une instance configurée d’implémentation (ensemble de fonctionnalités)
- 30. SCA: modèle d’assemblage 31 Composé : deuxième élément définit par SCA qui est un assemblage de composants (services, références, propriétés et des liens qui existent entre ces éléments) Un composé est un composant de plus haut niveau que ceux qui le compose Il fournit des services, dépends de références et a des propriétés Un composé peut à son tour être référencé par d’autres composants et utilisé au sein d’autres composés
- 31.
- 32.
- 33. Quels sont leséléments clé d’une architecture orientée services ? 35
- 34.
- 35. 37 Détails de l’architecture technique Consommateur duservice Fournisseur du service Registre Couche de Médiation (ESB) Annuaire 2.c Récupérer la référence (point d’accès) du service Contrat Orchestrateur des services métiers 1.a Chercher service 1.b Retourner le contrat 2.a créer une instance de processus 2.b Exécuter le processus 2.d Envoyer une demande Description des processus métiers
- 36. Standards de l’architecture 38 Les standards sont un élément clé d’une SOA, ils assurent l’interopé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
- 37. SOA et webservices 39 Attention à ne pas confondre les 2 ! SOA est un ensemble de concepts : Une SOA peut se mettre en œuvre sans Web Services Les services web (WS) sont de l’ordre de la technologie : On peut utiliser les WS sans faire de SOA (Architecture point à point sans réutilisation) Les WS constituent la meilleure solution standardisée disponible Un service métier = un service web
- 38. Langage BPEL 40 BusinessProcess Execution Language (BPEL) Standard de l’OASIS Norme permettant de décrire des processus « métier » en XML Propose les fonctions basiques d’un langage de programmation: sequence, flow, loop, switch… Identification des Instances de Processus
- 39. BPEL : lechef d’orchestre 41
- 40.
- 41. Enterprise Service Bus(ESB) 43 C’est le point d’entrée vers un service : => invocation indirecte du service au travers du bus Infrastructure qui optimise les échanges entre consommateurs et fournisseurs de services. Il peut prendre en charge : Routage transformation des données transactions, sécurité, qualité de service, … Le but d’un ESB est de communiquer de manière simple et standardisée entre des applications hétérogènes
- 42. Quelques manières d’implémenterun ESB 44 Intergiciels de type EAI (Enterprise Application Integration) WebSphere ESB Intergiciels de type Bus CORBA Integiciels de type Web services WebSphere Web Services Gateway Intergiciels de type MOM (Message Oriented Middleware) OpenJMS L’ESB n’est pas obligatoire : mais il est fortement recommandé pour éviter le couplage entre fournisseur et consommateur
- 43. Quel est lecycle de vie d’un service ?46
- 44. Découpage du cyclede vie d’un service 4 grandes phases : Identification Spécification Développement Gestion 1 aspect traversal : la gouvernance Les architectures orientées service impliquent une vision globale La gouvernance permet de casser les silos de l’entreprise 47
- 45. - 48 - ProviderInterfaces Documented Service/Process Workflow Created Service Specification Created Service Specification Review Develop Components Integrate & Test Create Deployment Unit Code in repository Acceptance Test Monitor SLA Compliance Certify & Publish Service Plan New Service Version Deprecate Service Decommission Service Reusable Service Specification Reusable Service Development Reusable Service Management Legacy Systems Candidate Consumers Identified Search for Existing Implementation Solution requirements Process Models Service Identification Service Specification Service Owner Approval Operational Service in use Service Identified Service reusability Commission Service outlines Service outlines Service in registry Code in repository ok ko Cycle de vie des services Process Governance Service Specification
- 46. La gouvernance enquelques questions Qui définit et modifie les services ? Qui peut y accéder ? Quelle est la qualité que les services doivent offrir ? Qui paie pour ces services ? Qui est responsable de l’infrastructure ? Qui gère les interdépendances entre les services ? Comment exposer les services aux entreprises partenaires ? 49
- 47. Rôles associés aucycle de vie des services • Définit les services pour les use cases • Modélise l’implementation des services Solution Architect • Définit les processus métiers • Identification des services métiers • Optimiser les processus via la simulation Business Analyst • Assemble les services Integration Developer • Implémente les services Developer Business Requirements Business Design Model Business Goals and Objectives Service Design Model Software Architecture Enterprise Architecture Service Flow Model Service Assembly Model Implementation Model Deployment Model Shared Assets Management • Publie/supprime les services dans/de l’annuaire • Gère les cycle de vie de services métiers Service Lifecycle approval/rejections • Contrôle la qualité d’exécution de service Service Registrar, Governance & Performance Managers
- 48. Zoom sur laphase d’identification Identification : problème central pour mettre en œuvre une 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 Granularité trop fine : beaucoup d’interactions , des problèmes de performance Granularité trop épaisse : un service qui fait trop de chose, risque de ne pas être réutilisable Trouver le juste milieu 2 méthodologies d’identification des services Approche Top-down Pour démarrer un nouveau projet Dans le cadre d’un SI urbanisé Approche Bottom-up Pour réutiliser l’existant (non SOA) On part des morceaux, on rassemble les bouts 51
- 49. 2 méthodologies d’identificationdes services Approche Top-down : Pour démarrer un nouveau projet Dans le cadre d’un SI urbanisé Approche Bottom-up : Pour réutiliser l’existant (non SOA) On part des morceaux, on rassemble les bouts 52
- 50. Approche « TopDown » Use Cases Orchestration (business rules and processes) Requirements Story Board WSDL Service Specification New Application Receive Invoke Invoke Invoke Reply Reply Fault Non- Interruptible Receive Invoke Invoke Invoke Reply Reply Fault Non- Interruptible or process model New & reusable Services 53
- 51. Approche « BottomUp» reusable code Orchestration (business rules and processes) WSDL Service Specification Change Cases Interface Specification New Requirements Legacy application Receive Invoke Invoke Invoke Reply Reply Fault Non- Interruptible Receive Invoke Invoke Invoke Reply Reply Fault Non- Interruptible New Application Story Board or process model 54 54
- 52. Approche « Meetin the Middle » On utilise rarement une unique approche Dans la pratique : Faire l’analyse Top-down sans se préoccuper de l’existant Faire l’analyse Buttom-up en ne considérant que l’existant Comparer les services « remontés » avec ceux déduits des Uses case Faire les compromis nécessaires pour réutiliser le maximum de code 55
- 53. “Meet in theMiddle”: exemple du prêt business processes process choreography services service components operational systems Lending Loan Origination Loan Closure Loan Servicing IMS DB LOS (Loan Origination System) Modify Application Receive Application Check Credit Negotiate Loan Receive Application Adjudicate Loan Close the Loan Application Processing Customer Accounting Credit Administration Permissions Component Loan Product Consolidated Book/Position Correspondence Doc Mgmt & Archive Book the Loan Collateral Handling Fair Issac Blaze Calculate Risk Score Enterprise Content Mgmt Image Documents Decline Reasons Notify Customer of Decision Domain Analysis & Decomposition Process Decomposition Top Down Analysis Bottom up Analysis Service Identification Interview Documentation Code Analysis Services Identified From Top Down and Bottom up Analysis 56
- 54.
- 55. Du déjà vu? 60 SOA est une évolution des plate-forme passées, tout en préservant les caractéristiques réussies des architectures traditionnelles Contractualisation des services Desing by contrat (Meyer) Découplage Interface/Implémentation, interopérabilité, transparence des communications, … Middlewares à la CORBA Couplage faible Message Oriented Middleware (MOM) Orchestration des services Travaux autour des workflows, langages de coordination SOA est une évolution plutôt qu’une révolution
- 56.
- 57. Synthèse • Orienté fonctionnalités •Conçu pour durer • Cycle de développement long Depuis… …Vers… • Orienté processus • Conçu pour changer • Développement et déploiement interactif • Silos applicatifs • Couplage fort • Orienté Objet • Orchestration de Services • Couplage faible • Orienté message