Vous êtes sur la page 1sur 49

ARCHITECTURES ORIENTÉES

SERVICES
Source : cours de Occello Audrey

FST 2010-11 Heithem.Abbes@gmail.com


Chaque rôle s'approprie SOA différemment
2

Un ensemble de services que l'entreprise souhaite exposer à leurs


clients et partenaires, ou d'autres parties de l'organisation

Dirigeants
Un style architectural basé sur un fournisseur, un
demandeur et une description de service, et supporte
Analystes métier les propriétés de modularité, encapsulation,
découplage, réutilisation et composabilité

Architectes

Un modèle de programmation avec ses standards,


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
Intégrateurs
Introduction
3

  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 ?
4 A quels besoins répond le SOA ?
Problématique de l’intégration en entreprise
5

  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

 C’est l’activité qui doit piloter la technologie et non


l’inverse
Besoins métier vs contraintes techniques
6

  La création d'applications dans l'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

 Pas de place pour la prise en compte de


l'évolution des besoins fonctionnels au
niveau de l'application
Besoins métier vs contraintes techniques
7

  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
Réutilisation vs cloisonnement
8

  Le découpage présentation/logique applicative/base de données


de l'architecture 3-tiers facilite le travail de la MOE mais favorise le
cloisonnement en silos applicatifs indépendants (blocs monolithiques)
  Certaines fonctions sont redondantes : une version pour chaque
application

 Pas de mutualisation des développements entre projets


et peu de réutilisation possible
e-store : domaines métier et architecture
9
Silos et transversalité
10

  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 leurs SI
e-store : exemple de processus transverse
11
Hier : plat de spaghettis
12

  Développements
coûteux
  Interconnexions
redondantes (point à
point)
  Grande complexité

  Maintenance difficile
Demain : Architecture urbanisée
13

  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
Vers toujours plus d'abstraction
14

  Procédures
  Modèles orientés objets

  Packages

  Encapsulation

  Composants logiciels
  Assemblages et configuration

  Et maintenant les services !


15
Quels sont les principes de base
du SOA ?
Principes fondamentaux de l’architecture SOA
16

  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 utilisent
Qu’est ce qu’un Service (au sens SOA) ?
17

  Partage les caractéristiques suivantes d’un objet


  Modulaire (ensemble de fonctionnalités qui font sens)
  Partage les caractéristiques suivantes d’un composant
  Boitenoire (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 (il a une 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
4 propriétés du service à retenir
18

  Un Service est Autonome   Un Service expose un Contrat

Conditions Générales de Vente


Règlement Intérieur
in Vos droits/Vos devoirs

out

  Les Frontières entre services   Les services communiquent par


sont Explicites messages
Exemple de couplage fort : Gestion de prêts
Composants
19

LoanAgent LoanApproval Account Loan SMSGateway

calculateRisk
checkCredit

createLoan

sendConfirmation

  LoanAgent est lié à LoanApproval et Loan


  LoanApproval est lié à Account
  Loan est lié à SMSGateway
Gestion de prêts en couplage faible
Services
20

LoanProcess CheckAccount Calculate CreateLoan Notify


Balance LoanRisk ViaSMS

  Qu’est ce que LoanProcess ?


  Un processus métier !
Il permet d’orchestrer les services => couplage lâche
e-store : Couches
21

AccountController CartController

Default
SignOut SignIn Search Category Items Item Shopping Help Error
Details Cart
Presentation
Layer

Check Order Order Order


My Edit Create
out Billing Shipping Process
Account Account Account

Account Profile Product Item Inventory Cart OrderInsert OrderRead


Business
Logic
Layer

IAccount IProfile IProduct IItem IInventory IOrder


Data
Access
Layer
e-store : Domaines
22

Default
SignOut SignIn Search Category Items Item Shopping Help Error
Details Cart
Presentation
Layer

Check Order Order Order


My Edit Create
out Billing Shipping Process
Account Account Account

Account Profile Product Item Inventory Cart OrderInsert OrderRead


Business
Logic
Layer

1.0 1.0 10.0 5.1 1.0


1.1 2.0 11.2 5.2 6.0
1.2 3.5 11.5 5.3 7.0
IAccount IProfile IProduct IItem IInventory IOrder
Data
Access
Layer

Customer Catalog Inventory Shopping Billing


e-store : Domaines
23

Presentation
Layer

Business
Logic
Layer

Data
Access
Layer

Customer Catalog Inventory Shopping Billing


e-store : Services
24

Presentation
Layer

Business
Logic
Layer

Service Manage Show Make


Layer Shop Bill
Customer Catalog Inventory

Data
Access
Layer
Orienté application vs orienté services
25
Business Process Management (BPM)‫‏‬
26

  But : 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 a son propre but, entrées et sorties
  Un processus 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
  Le processus est lui-même accessible en tant que service
BPM par l’exemple

- 27 -
Standard BPMN
28

  BPMN = Business Process Modeling Notation


  Standard OMG (Object Management Group)
  La représentation est standard, la notation ne l'est pas
  Modélisation autour de la notion de processus métier
  Améliorer la communication entre les mondes “métier” et
“technique”
  Création de modèles graphiques de processus métier
  Réseau d'objets graphiques où les objets représentent des activités
qui interviennent dans le processus
  BPMN et UML
  A l'origine, les diagrammes d'activité UML étaient utilisés
  Pauvreté de ces diagrammes UML / métier ! => BPMN
  Similitudes dans les symboles
Exemple d'un processus de paiement en BPMN
29
Bénéfices métier
30

  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
Bénéfices techniques
31

  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é
32
Quelle relation existe-t'il entre les
services et les composants ?
Convergence Composants / Services
33

  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 (indépendamment de leur
implémentation)
  Principe : Notion de composé/composant (composite/
component)
  Initiative : IBM, Oracle, BEA, SAP, Sun, TIBCO, …
  But : structurer l'implémentation des SOA
  Implémentations : Apache Tuscany, IBM Websphere,
HydraSCA, fabric3, ...
Service Component Architecture (SCA)
34

  SCA fournit deux niveaux de modèle:


  unmodè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: modèle d’implémentation
35

  L’élément de base de SCA est le composant (component) qui constitue


l’unité élémentaire de construction.
  Un composant est une instance configurée d’implémentation (ensemble
de fonctionnalités)

  Les fonctionnalités sont exposées en tant


que services en vue de leur utilisation par
d’autres composants
  Un composant peut dépendre de services
fournis par d’autres composants. Ces
dépendances sont appelés références.
  Le composant peut être paramétrable au
travers de propriétés qui influencent le
comportement d’une fonctionnalité.
SCA: modèle d’assemblage
36

  Le deuxième élément définit par SCA est le composé (composite) 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 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
Exemple de composition de services
37
Les couches SOA
Ces différents
modes de couplage
** sont nécessaires
et dépendent du
niveau dans
l’architecture

38
Les couches SOA
39
41
Quels sont les éléments clé
d’une architecture orientée services ?
Architecture triangulaire
42
Détails de l’architecture technique
1.a Search for service

Service Repository
consumer 1.b Return contract
Contract

2.a Create a process instance

Mediation layer/Service bus

2.c Retrieve service


2.d Send request end-point
2.b
Execute
process
Service
provider Business service
orchestrator Registry
Business
43 process description
Standards de l’architecture
44

  Les standards sont un élément clé d’une SOA, ils assurent


l’interopérabilité

SOAP WSDL UDDI BPEL


W3C W3C Microsoft, IBM, HP Oasis
Simple Object Web Services Universal Description Business Process
Access Protocol Description Language Discovery and Integration Execution Language

Transporte Décrit le contrat Spec pour Décrit les


Repository/Registry processus métier

Les trois piliers des Services Web


SOA et web services
45

  Attention à ne pas confondre les 2 !


  SOA est un ensemble de concepts :
Une SOA peut se mettre en œuvre sans Web Services

  LesWS sont de l’ordre de la technologie :


On peut utiliser les Web Services 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
Le langage BPEL
46

  Standard de l’OASIS
  Norme permettant de décrire des processus en XML
  Propose les fonctions basiques d’un langage de
programmation:
  sequence, flow, loop, switch…
  Identification des Instances de Processus
  Gestion des transactions
  Gestion des fautes
BPEL : le chef d’orchestre
47
BPEL par l’exemple
48

PartnerLink

flow

PartnerLink
PartnerLink

loan.bpel
Enterprise Service Bus (ESB)
49

  C’est le point d’entrée vers un service : => invocation


indirecte du service au travers du bus
  Il doit être normalisé mais on ne sait pas qui fourni le service
et comment il le fourni (implémentation)
  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
Quelques manières d’implémenter un ESB
50

  Intergiciels de type EAI (Enterprise Application


Integration)
  Intergiciels de type Bus tel que CORBA

  Routeurs Web services tel que WebSphere Web


Services Gateway
  Intergiciels de type MOM (Message Oriented
Middleware)

  L’ESB n’est pas obligatoire : mais il est fortement


recommandé pour éviter le couplage entre
fournisseur et consommateur