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

1. ARCHITECTURES
ORIENTÉES SERVICES
Heithem.Abbes@gmail.com

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. 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. A quels besoins répond le
SOA ?
4

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. 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. 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 : exemple de 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 plus d'abstraction
 Procédures
 Modèles orientés objets
 Packages
 Encapsulation
 Composants logiciels
 Assemblages et configuration
 Et maintenant les services !
12

13. Quels sont les principes de base
du SOA ?
13

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. 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.  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. 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. 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. Orienté applications vs orienté
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. BPM par l’exemple
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. Standard BPMN
23

24. Exemple BPMN
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'il entre 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. Types de couplage
32

32. Couches SOA
34

33. Quels sont les éléments clé
d’une architecture orientée services
?
35

34. Architecture triangulaire
36

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. 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 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. 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. BPEL : le chef d’orchestre
41

40. flow
PartnerLink
PartnerLink
PartnerLink
BPEL par l’exemple
loan.bpel
42

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é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. Quel est le cycle de vie d’un service ?46

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. - 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. 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. 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. 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. 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. 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. 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. 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. “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. Conclusion
59

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. 61

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