ARCHITECTURES
ORIENTÉES SERVICES
Heithem.Abbes@gmail.com
Chaque rôle s'approprie SOA différemment
Un ensemble de services que l'entreprise souhaite exposer à leurs
clients et part...
Introduction
 A quels besoins répond le SOA ?
 Quels sont les principes de base de SOA ?
 Quelle relation existe t’il e...
A quels besoins répond le
SOA ?
4
Problématique de l’intégration en
entreprise
 Les entreprises doivent s’adapter en permanence et être
de + en + réactives...
Besoins métier vs contraintes
techniques
 Création d'applications d'entreprise est très souvent
pilotée par des besoins à...
Réutilisation vs cloisonnement
 Découpage Prés./Log. Applicative/BD de l'arch. 3-tiers
favorise le cloisonnement en silos...
Silos et transversalité
8
 Entreprises découpées en départements fonctionnels y
compris le SI
 Processus métiers de + en...
e-store : exemple de processus
transverse
9
Sans SOA : plat de spaghettis
10
 Développements coûteux
 Interconnexions
redondantes (point à
point)
 Grande complexit...
Avec SOA : Architecture
urbanisée11
 L’urbanisation informatique définit l'organisation d’un SI
à l’image d’une ville
 d...
Vers toujours plus d'abstraction
 Procédures
 Modèles orientés objets
 Packages
 Encapsulation
 Composants logiciels
...
Quels sont les principes de base
du SOA ?
13
Principes fondamentaux de l’architecture
SOA
 SOA est une vision stratégique pour le système
d’information.
 Il n’existe...
Qu’est ce qu’un Service (au sens SOA)
?
 Partage les caractéristiques suivantes d’un objet
 Modulaire (ensemble de fonct...
 Un Service expose un Contrat
 Les services communiquent par
messages
Conditions Générales de Vente
Règlement Intérieur
...
Exemple - Gestion de prêts (par
composants)
LoanAgent
calculateRisk
LoanAccount
createLoan
checkCredit
LoanApproval SMSGat...
Exemple - Gestion de prêts (avec
services)
LoanProcess CreateLoanCheckAccount
Balance
Calculate
LoanRisk
Notify
ViaSMS
Ser...
Orienté applications vs orienté
services19
Business Process Management
(BPM)
 Objectif : donner à l’entreprise les moyens de gérer
ses processus métiers de manière ...
BPM par l’exemple
21
Standard BPMN
 BPMN = Business Process Modeling
Notation
 Standard OMG (Object Management Group)
 Représentation standa...
Standard BPMN
23
Exemple BPMN
24
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...
Quelle relation existe-t'il entre les
services et les composants ?
27
Convergence Composants /
Services
 Le service désigne le point de vue du
consommateur, c’est à dire la vue externe du
com...
Service Component Architecture
(SCA)29
 SCA fournit deux niveaux de modèle:
 un modèle d’implémentation : construire des...
SCA: modèle d’implémentation
30
 Les fonctionnalités sont exposées
en tant que services en vue de
leur utilisation par d’...
SCA: modèle d’assemblage
31
 Composé : deuxième élément définit par SCA qui est un assemblage
de composants (services, ré...
Types de couplage
32
Couches SOA
34
Quels sont les éléments clé
d’une architecture orientée services
?
35
Architecture triangulaire
36
37
Détails de l’architecture
technique
Consommateur
du service
Fournisseur
du service Registre
Couche de Médiation (ESB)
A...
Standards de l’architecture
38
 Les standards sont un élément clé d’une SOA, ils
assurent l’interopérabilité
Transporte
S...
SOA et web services
39
 Attention à ne pas confondre les 2 !
 SOA est un ensemble de concepts :
Une SOA peut se mettre e...
Langage BPEL
40
 Business Process Execution Language (BPEL)
 Standard de l’OASIS
 Norme permettant de décrire des proce...
BPEL : le chef d’orchestre
41
flow
PartnerLink
PartnerLink
PartnerLink
BPEL par l’exemple
loan.bpel
42
Enterprise Service Bus (ESB)
43
 C’est le point d’entrée vers un service : => invocation
indirecte du service au travers ...
Quelques manières d’implémenter un
ESB
44
 Intergiciels de type EAI (Enterprise Application
Integration)
 WebSphere ESB
...
Quel est le cycle de vie d’un service ?46
Découpage du cycle de vie d’un
service
 4 grandes phases :
 Identification
 Spécification
 Développement
 Gestion
 1...
- 48 -
Provider Interfaces Documented
Service/Process Workflow Created
Service Specification Created
Service
Specification...
La gouvernance en quelques
questions
 Qui définit et modifie les services ?
 Qui peut y accéder ?
 Quelle est la qualit...
Rôles associés au cycle de vie des services
• Définit les services pour
les use cases
• Modélise l’implementation
des serv...
Zoom sur la phase
d’identification
 Identification : problème central pour mettre en œuvre une SOA
 La granularité des s...
2 méthodologies d’identification des
services
 Approche Top-down :
 Pour démarrer un nouveau projet
 Dans le cadre d’un...
Approche « Top Down »
Use Cases
Orchestration
(business rules
and processes)
Requirements
Story Board
WSDL
Service
Specifi...
Approche « Bottom Up»
reusable code
Orchestration
(business rules
and processes)
WSDL
Service
Specification
Change Cases
I...
Approche « Meet in the
Middle »
 On utilise rarement une unique approche
 Dans la pratique :
 Faire l’analyse Top-down ...
“Meet in the Middle”: exemple du
prêt
business processes
process choreography
services
service
components
operational syst...
Conclusion
59
Du déjà vu ?
60
 SOA est une évolution des plate-forme passées, tout en
préservant les caractéristiques réussies des arch...
61
Synthèse
• Orienté fonctionnalités
• Conçu pour durer
• Cycle de développement long
Depuis… …Vers…
• Orienté processus
• C...
Prochain SlideShare
Chargement dans…5
×

Architectures orientés services (SOA)

535 vues

Publié le

Présentation des architectures orientés services (SOA).
Composant vs Service
Processus Metier
BMPN/BPEL

Publié dans : Formation
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
535
Sur SlideShare
0
Issues des intégrations
0
Intégrations
32
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Architectures orientés services (SOA)

  1. 1. ARCHITECTURES ORIENTÉES SERVICES Heithem.Abbes@gmail.com
  2. 2. Chaque rôle s'approprie 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, 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. 3. Introduction  A quels besoins 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. 4. A quels besoins répond le SOA ? 4
  5. 5. Problématique de l’intégration en 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. 6. Besoins métier vs contraintes 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. 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. 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. 9. e-store : exemple de processus transverse 9
  10. 10. Sans SOA : plat de spaghettis 10  Développements coûteux  Interconnexions redondantes (point à point)  Grande complexité  Maintenance difficile
  11. 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. 12. Vers toujours plus d'abstraction  Procédures  Modèles orientés objets  Packages  Encapsulation  Composants logiciels  Assemblages et configuration  Et maintenant les services ! 12
  13. 13. Quels sont les principes de base du SOA ? 13
  14. 14. Principes fondamentaux de l’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. 15. Qu’est ce qu’un Service (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. 16.  Un Service expose 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. 17. Exemple - Gestion de 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. 18. Exemple - Gestion de 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. 19. Orienté applications vs orienté services19
  20. 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. 21. BPM par l’exemple 21
  22. 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. 23. Standard BPMN 23
  24. 24. Exemple BPMN 24
  25. 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. 26. Quelle relation existe-t'il entre les services et les composants ? 27
  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. 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. 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. 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. 31. Types de couplage 32
  32. 32. Couches SOA 34
  33. 33. Quels sont les éléments clé d’une architecture orientée services ? 35
  34. 34. Architecture triangulaire 36
  35. 35. 37 Détails de l’architecture technique Consommateur du service 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. 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. 37. SOA et web services 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. 38. Langage BPEL 40  Business Process 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. 39. BPEL : le chef d’orchestre 41
  40. 40. flow PartnerLink PartnerLink PartnerLink BPEL par l’exemple loan.bpel 42
  41. 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. 42. Quelques manières d’implémenter un 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. 43. Quel est le cycle de vie d’un service ?46
  44. 44. Découpage du cycle de 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. 45. - 48 - Provider Interfaces 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. 46. La gouvernance en quelques 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. 47. Rôles associés au cycle 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. 48. Zoom sur la phase 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. 49. 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 52
  50. 50. Approche « Top Down » 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. 51. Approche « Bottom Up» 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. 52. Approche « Meet in 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. 53. “Meet in the Middle”: 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. 54. Conclusion 59
  55. 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. 56. 61
  57. 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

×