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