Intro Concepts Principes Soa

Module Architecture SOA & Workflow
SI5/Master IFI
Audrey Occello
occello@polytech.unice.fr
http://anubis.polytech.unice.fr/cours/2012_2013:si5:soa:start
(c) 2012-2013, Occello Audrey, module SOA & Workflow
- 1 -
Vous avez dit SOA?

Service Oriented Architecture
Chaque rle s'approprie SOA diffremment :
Des services que l'entreprise souhaite exposer leurs clients et
partenaires, ou d'autres parties de l'organisation
Dirigeants
Analystes mtier
Une architecture base sur un fournisseur, un

consommateur et une description de service, et supportant
les proprits de modularit, encapsulation, dcouplage,
rutilisation et composabilit
Architectes
Un style de programmation avec ses standards,

paradigmes, technologies et outils associs
Dveloppeurs
Un intergiciel offrant des fonctionnalits en terme
d'assemblage, d'orchestration, de surveillance et
de gestion des services
Intgrateurs
- 2 -
Contenu du module
Les concepts que vous allez apprendre
des notions : composants, services, processus mtier ...
des principes : d'orchestration, de contratualisation,
d'urbanisation
tout en rvisant vos connaissances : bus, annuaire, web services ...
Les langages/technologies/outils que vous allez utiliser :
Un environnement de modlisation utilisant la notation BPMN

Le langage BPEL
Une plate-forme dexcution incluant un ESB
Et bien sr les web services (WSDL/XSD)
- 3 -
Plan et valuation du module
Des rendus de projet en groupe

Une soutenance de projet lors de la dernire sance
Un examen individuel sur table lors de la dernire sance
- 4 -
Introduction lArchitecture
Oriente Service
Module Architecture SOA
SI5 - Master 2 IFI
- 5 -
Plan du cours
A quels besoins rpond SOA ?
Quels sont les principes de base de SOA ?
Quels sont les liens entre objets et services ?
Quels sont les lments cl de larchitecture technique ?
- 6 -
A quels besoins rpond SOA ?
- 7 -
Problmatique de lintgration en entreprise

Les entreprises doivent sadapter en permanence et tre
de + en + ractives aux variations des marchs
fusions
acquisitions
scissions
diversification des offres commerciales
changement technologiques

Ces oprations ont un impact sur les systmes
d'informations (SI) des entreprises
L'intgration difficile des SI est un frein ces
changements
Cest lactivit qui doit piloter la technologie et non
linverse
- 8 -
Du "conu pour durer" au "conu pour changer"

Cration d'applications dans l'entreprise trs souvent
pilote par des besoins trs court terme
Dveloppement d'une application sous tel dlai avec telles
fonctionnalits
Pas de place pour la prise en compte de l'volution des
besoins fonctionnels au niveau de la conception de

l'application, cest la technologie dapporter la
flexibilit
- 9 -
Besoins mtier vs contraintes techniques

Problme de comprhension entre maitrise d'ouvrage
(MOA) et maitrise d'oeuvre (MOE)
Modlisation et dveloppements dirigs par les
choix/contraintes techniques
Dcalage entre besoins mtier et leur ralisation
(constituants informatiques)
Pas dimplication
de la MOA dans
le pilotage de la
variante
- 10 -
Rutilisation vs cloisonnement
Le dcoupage de l'architecture 3-tiers facilite le travail
de la MOE mais favorise le cloisonnement en silos
applicatifs indpendants (blocs monolithiques)
Certaines fonctions sont redondantes : une version pour
chaque application
Application 1
Application 2
Application 3
Prsentation
Prsentation
Prsentation
Logique applicative
Logique applicative
Logique applicative
Base de donnes
Base de donnes
Base de donnes
Pas de mutualisation des dveloppements entre projets
et peu de rutilisation possible
- 11 -
e-store : domaines mtier et architecture

Default
SignOut
SignIn
Search
Category
Items
Presentation
Layer
My
Account
Business
Logic
Layer
Data
Access
Layer
Edit
Account
Item
Details
Shopping
Cart
Check
out
Create
Account
Account
Profile
Product
Item
Inventory
IAccount
IProfile
IProduct
IItem
IInventory
Cart
Help
Order
Billing
OrderInsert
Error
Order
Shipping
Order
Process
OrderRead
IOrder
- 12 -
e-store : domaines mtier et architecture

Default
SignOut
SignIn
Search
Category
Items
Presentation
Layer
My
Account
Business
Logic
Layer
Data
Access
Layer
Edit
Account
Shopping
Cart
Check
out
Create
Account
Account
Profile
Product
Item
Inventory
IAccount
IProfile
IProduct
IItem
IInventory
Client
Item
Details
Catalogue
Inventaire
Cart
Help
Order
Billing
OrderInsert
Error
Order
Shipping
Order
Process
OrderRead
IOrder
Shopping
Facturation
- 13 -
Silos et transversalit
Entreprises dcoupes en dpartements fonctionnels
Mais :
Processus mtiers de + en + inter-dpartementaux
Les processus franchissent les fontires de l'entreprise
qui doit pouvoir prendre en compte les activits et
processus des partenaires pour tre reactive
Cots considrables dans la gestion des flux entre
dpartements et dans lintgration de leurs SI
- 14 -
Hier : plat de spaghettis
Dveloppements coteux
Interconnexions redondantes (point point)
Grande complexit
Rutilisation & maintenance difficile Source : DotNetGuru.org
- 15 -
Demain : Architecture urbanise

Lurbanisation informatique dfinit l'organisation dun SI
limage dune ville
dcouper le SI en modules autonomes (zone, quartier, lot, bloc)
localiser les zones dchange dinformations (routes, ponts, tunels) qui
permettent de dcoupler les diffrents modules
Objectif : faire voluer le SI au mme rythme que la stratgie

et l'organisation des mtiers de l'entreprise
legacy
services
portail
...
Canal d'change
donnes
processus
partenaires
NonInterruptible
Receive
Invoke
Invoke
Reply
Invoke
...
Reply
Fault
- 16 -
Vers toujours plus d'abstraction

Procdures
Modules
Modles orients objets
Packages
Encapsulation
Design patterns
Et maintenant les services !
- 17 -
Quels sont les principes de base du SOA ?
- 18 -
Principes fondamentaux de larchitecture SOA

Il nexiste pas une recette pour garantir le succs
de la mise en place dune SOA mais des principes
respecter :
Discussion entre mtier et IT
Utilisation des specifications mtier
Dcouplage entre fournisseur et
consommateur de services
Indpendance des ressources vis vis de
ceux qui les utilisent
Utilisation de standards
Conservation de lexistant lors dvolutions
technologiques
- 19 -
Quest ce quun Service (au sens SOA) ?

Correspond un primtre fonctionnel que lon souhaite
exposer un certain type de consommateurs (ensemble
de fonctionnalits qui font sens)
Expose un petit nombre doprations offrant un
traitement de bout en bout
Indpendant de la localisation
Neutralit vis--vis des protocoles de transport
Sans tat
En couplage faible
- 20 -
Exemple de couplage fort : Gestion de prts
LoanAgent
LoanApproval
calculateRisk
Account
Loan
SMSGateway
checkBalance
createLoan
sendConfirmation
LoanAgent est li LoanApproval et Loan

LoanApproval est li Account
Loan est li SMSGateway
- 21 -
Exemple de couplage fort : Gestion de prts

Entits = Objets
LoanAgent
LoanApproval
calculateRisk
Account
Loan
SMSGateway
checkBalance
createLoan
sendConfirmation
LoanAgent est li LoanApproval et Loan

LoanApproval est li Account
Loan est li SMSGateway
- 22 -
Gestion de prts en couplage faible

LoanProcess
CheckAccount
Balance
Calculate
LoanRisk
CreateLoan
Notify
ViaSMS
Est ce quune entit a un rle part ?
- 23 -

LoanProcess
CheckAccount
Balance
Calculate
LoanRisk
CreateLoan
Notify
ViaSMS

LoanProcess : un processus mtier !
Il permet dorchestrer les services => couplage lche
- 24 -

Que reprsentent ces entits ?
LoanProcess
CheckAccount
Balance
Calculate
LoanRisk
CreateLoan
Notify
ViaSMS

- 25 -

Des services !
LoanProcess
CheckAccount
Balance
Calculate
LoanRisk
CreateLoan
Notify
ViaSMS

- 26 -
Orient application vs orient services
- 27 -
e-store : Domaines
Presentation
Layer
Business
Logic
Layer
Data
Access
Layer
Client
Catalogue
Inventaire
Shopping
Facturation
- 28 -
e-store : Services
Presentation
Layer
Business
Logic
Layer
Service
Layer
Gerer
clients
Voir
catalogue
Faire
inventaire
Acheter
Facturer
Data
Access
Layer
- 29 -
e-store : Services
Presentation
Layer
Business
Logic
Layer
Service
Layer
Gerer
clients
Voir
catalogue
Faire
inventaire
Acheter
Facturer
Data
Access
Layer
- 30 -
Mais qu'est ce qu'un processus mtier ?

Un ensemble d'activits qui s'enchanent de manire
chronologique pour atteindre un objectif, gnralement
dlivrer un produit ou un service, dans le contexte
d'une organisation de travail - Wikipdia
Un flux d'informations au sein d'une organisation
Une vue transversale sur les activits de l'entreprise
permet d'identifier, de matriser et d'optimiser les

changes entre les diffrents dpartements et corps
de mtiers
- 31 -
Exemple de processus (notation informelle)
- 32 -
Business Process Management (BPM)

But : Donner l'Entreprise les moyens de grer ses processus
mtiers de manire informatise (modlisation, simulation,
excution et audit)
Optimisation, adaptation aux besoins en temps rel
Un processus est compos de sous processus, de dcisions

(Business rules) et dactivits
Un sous processus a son propre but, entres et sorties
Les activits
correspondent aux parties du processus mtier qui nincluent pas de

dcision et sont associes des rles
Sont ralises par des systmes ou des humains
Des mesures (KPI pour Key Performance Indicators) permettent

de capturer les performances du processus
Un processus est le rsultat dune orchestration de service
Le processus est lui-mme accessible en tant que service
- 33 -
Standard BPMN
BPMN = Business Process Modeling Notation
Standard OMG (Object Management Group)

La reprsentation est standard, la notation ne l'est pas
Modlisation autour de la notion de processus mtier
Amliorer la communication entre les mondes mtier et
technique
Cration de modles graphiques de processus mtier
Rseau d'objets graphiques o...
... les objets reprsentent des activits...
... qui interviennent dans le processus selon l'agencement
reprsent
BPMN et UML
A l'origine, les diagrammes d'activit UML taient utiliss
Pauvret de ces diagrammes UML / mtier !
Similitudes dans certains symboles
Source : ICARE'08
- 34 -
Exemple d'un processus de paiement en BPMN
Source : bpmn.org
- 35 -
4 proprits du service retenir

Un service est autonome
et sans tat
Un service expose
un contrat
in
Conditions Gnrales de Vente

Rglement Intrieur
Vos droits/Vos devoirs
out
Les frontires entre

services sont explicites
Les services communiquent

par messages
- 36 -
Bnfices mtier
Amliorer lagilit et la flexibilit du mtier
Faciliter la gestion des processus mtier
Offrir la capacit casser les barrires
organisationnelles (silos)
Rduire en temps le cycle de dveloppement
des produits/services
Amliorer le retour sur investissement
Accrotre les opportunits de revenu
- 37 -
Bnfices techniques
Rduire la complexit de la solution
Construire les services une seule fois et les
utiliser frquemment
Garantir une intgration standardise et le
support de clients htrognes
Faciliter la maintenance
- 38 -
Quels sont les liens entre objets et services ?
- 39 -
volution des paradigmes lis la rutilisation

1980
Technologie
procedurale
Procedures,
Pascal, C, ...
Raffinement
1995
Technologie
objet
Objects,
Classes,
Smalltalk, C++, ...
Encapsulation et
Spcialisation
Technologie
composant
Composants, Containers
Interfaces in et out,
EJB, CCM,
Composition par assemblage
- 40 -
XML parsing dans Tomcat
Copyright aspectj.org
En rouge, les lignes de code concernes par le parsing

Bonne modularisation : code concentr en un seul endroit
- 41 -
URL pattern matching dans Tomcat
En rouge, les lignes de code pour grer la correspondance dURLs

Bonne modularisation : code concentr en 2 endroits
- 42 -
Trace dans Tomcat
En rouge, les lignes de code pour tracer lexcution
Mauvaise modularisation : le code est mlang, parpill et redondant
- 43 -
Quelques unes des limites de la POO

programming in the small
Interactions entre objets enfouies dans le code
Structure et architecture de lapplication peu visibles
volution fastidieuse
Gestion de la consistance dun changement dlicate
- 44 -
Objets et encapsulation
Granularit encore trop fine
Mal adapte la programmation grande chelle
Couplage fort et primtre non dfini
Rend difficile la rutilisation
Accrot la complexit des Systmes OO
- 45 -
Programmation constructive (ou par composition)

programming in the large (programmation gros grain)
Motivation : le time to market
Amlioration de la productivit et de la qualit des logiciels
Rduction des cots
Approche : rduire la complexit et monter le niveau

d'abstraction
Dcrire l'architecture et les interactions entre instances
Assembler plutt que dvelopper
La modlisation des composants est intgre UML 2.0

- 46 -
Analogie avec les composants lectroniques, legos, puzzles
- 47 -
Analogie avec les composants lectroniques, legos, puzzles
Composants logiciels
Des units interchangeables
- 48 -
Structure dun composant
Configuration du composant
proprits (attributs publics)
connexions
cycle de vie (arret, redemarrage, ...)
contraintes techniques (transaction, persistance, scurit, ...)
Interfaces
requises
Interfaces
fournies
Interactions avec un composant

ce qui est fourni par le composant
ce qui est utilis par le composant
modes de communication
Interface de
configuration
Type de composants vs instance de composants
- 49 -
Notion dinterfaces & de contrats

Une interface est un contrat dutilisation
Quelles sont les conditions de dclenchement des exceptions ?

Quen est-il des accs concurrents ?
Quelles conditions y-a-t-il sur les valeurs des oprations ?
Dans quel ordre faut-il appeler les oprations ?
Diffrents niveaux de contractualisation
Syntaxique : signature dopration (interfaces Java)

Comportemental : assertions UML/OCL, Fractal/Confract, JML, ...
Synchronisation : automates (StateCharts, protocoles Sofa, ...)
Qualit de services : attributs spcifiques (temps de rponse,
prcision du rsultat, cout d'accs, ...)
Plus les interfaces dun composant sont dtailles, plus la

composition du composant avec son environnement est
dfinie et claire
- 50 -
Points de vue
Arbre
V.I. Nourriture
M.I. CalculDuVol
Arbre
V.I.
Couleurs,Taille
M.I.
Dessiner
Arbre
V.I. prixDeVente
Temps-De-Coupe
M.I. Calcul-Profit
Arbre
V.I. valeur-Estime
M.I.
Estimer-Valeur
Calculer-Taxe
Arbre
V.I.
Taille,Poids, Couleur,feuillage
M.I.
Grandir
Dcoupage de la spcification des fonctionnalits dun composant en

plusieurs interfaces
Localisation des dpendances inter-composants et rduction de
limpact des changements
Gestion des points de vue utilisateur
- 51 -
Interface requise, notion de port et utilisation des composants
Interface requise
Un composant prcise les interfaces fournies par d'autres

composants qu'il utilise pour raliser ses traitements
Moyen de composition des composants et meilleure visibilit des
dpendances
Port
Un composant fournit des mcanismes pour tre connect,

ventuellement dynamiquement, d'autres composants. Un port
correspond une interface fournie ou requise.
Utilisation dun composant
On ne sadresse pas directement un composant comme pour un

objet
Obligation de passer par lun de ses ports
- 52 -
Exemple de composant : distributeur de boissons

To use a vending machine, you put money into it and make a selection.
When you make your selection, the vending machine goes through
several steps; verifying that it has received sufficient amount,
computing change and making sure selected item is in stock.
The item you selected and change get out of the vending machine.
(http://www.cs.uct.ac.za/mit_notes_devel/Java/Latest/html/singlehtml.html)
De temps en temps la machine
doit aussi tre :
rapprovisionne
rpare
Que fournit la machine ?
Que require-telle ?
- 53 -
payer,
slectionner,
prendreProduit,
prendreMonnaie,
ouvrir,
remplir,
mettreMonnaie,
mettreProduit,
fermer
Distributeur de
boissons
encaisser,
calculerAppoint,
majStock
- 54 -
payer,
slectionner,
prendreProduit,
prendreMonnaie,
ouvrir,
remplir,
mettreMonnaie,
mettreProduit,
fermer
Distributeur de
boissons
encaisser,
calculerAppoint,
majStock
- 55 -
Consommateur
Fournisseur
Dpanneur
payer,
slectionner,
prendreProduit,
prendreMonnaie
ouvrir,
remplir,
mettreMonnaie,
mettreProduit,
fermer
Facturation
encaisser,
calculerAppoint
Distributeur de
boissons
majStock
Stock
ouvrir,
fermer
Modularit au niveau des fournis mais aussi au niveau des requis

Flexibilit dutilisation : on exporte que ce que lon utilise vraiment
- 56 -
Constat
Peu de guidelines
Dans quel cas utiliser un composant ?
Dans quel cas continuer utiliser un objet ?
Est ce que tout doit devenir composant ?
Est ce que tout peut devenir composant ?
On a besoin des 2 niveaux de granularit !

Mais quand passer de lun lautre ?
- 57 -
Identification des composants

Mthode Grady Booch / Softeam
A partir dun diagramme de classes UML
Regrouper les classes en catgories
Limiter le regroupement 12 classes max
Proprit dune catgorie : ensemble de classes
stable, consistant, mono proccupation, continu
(agrgat de classes)
Le choix de la cration des catgories est en
partie empirique : limportant est de promouvoir
les catgories dun projet lautre
- 58 -
Exemple de composant : gestion bancaire
- 59 -

Encaissement
Client
Portefeuille
Devis
Ventes
- 60 -

Portefeuille
Client
Encaissement
Ventes
Devis
- 61 -
Assemblage de composants et interactions

L'assemblage de deux composants se fait en connectant un port de
sortie (interface requise) avec un port d'entre (interface fournie)

qui doivent respecter un contrat
Type de communication
Un mode d'interaction doit tre choisi pour que la connexion soit

tablie
Composite
Les composants peuvent tre composs d'autres composants

Assemblages manipulables comme des composants
Re-configuration dynamique
Permet de modifier l'application chaud sans modification du code en

manipulant les assemblages
Utilit trs importante dans le cadre de linformatique ambiante
Apparition & disparition de services suivant le contexte
- 62 -
Assemblage de composants : distributeur de boissons
Consommer:
payer,
selectionner,
prendreProduit,
prendreMonnaie
Rapprovisionner:
ouvrir,
remplir,
mettreMonnaie,
mettreProduit,
fermer
Rparer:
ouvrir,
fermer
Facturer:
encaisser,
rendreMonnaie
Contrat
Facturer:
encaisser,
rendreMonnaie
Contrat
GererStock:
majStock
Distributeur de
boissons
GererStock:
majStock
Facturation
Stock
- 63 -
Assemblage de composants : gestion bancaire

Portefeuille
Client
Encaissement
Ventes
Devis
- 64 -
Consommer:
payer,
selectionner,
prendreProduit,
prendreMonnaie
Rapprovisionner:
ouvrir,
remplir,
mettreMonnaie,
mettreProduit,
fermer
Rparer:
ouvrir,
fermer
Facturer:
encaisser,
rendreMonnaie
Distributeur de
boissons
- 65 -
Consommer:
payer,
selectionner,
prendreProduit,
prendreMonnaie
Rapprovisionner:
ouvrir,
remplir,
mettreMonnaie,
mettreProduit,
fermer
Rparer:
ouvrir,
fermer
Distributeur de
boissons
Facturation
version 1
Facturer:
encaisser,
rendreMonnaie
- 66 -
Consommer:
payer,
selectionner,
prendreProduit,
prendreMonnaie
Rapprovisionner:
ouvrir,
remplir,
mettreMonnaie,
mettreProduit,
fermer
Rparer:
ouvrir,
fermer
Distributeur de
boissons
Facturation
version 1
Facturation
version 2
Facturer:
encaisser,
rendreMonnaie
- 67 -
Composition et vrifications
Interconnexions manquantes ou invalides
Proprits de vivacit et de sret
Contractualisation
...
Si les composants en entre sont corrects, l'opration

de composition garantit que le composant rsultant est
correct galement
- 68 -
Les composants dans la nature

Spcifications :
Beaucoup de
concepts
Pas dunification
EJB (Enterprise Java Beans)

CCM (CORBA Component Model)
Fractal
SCA (Service component Architecture) => pour SOA
...
Plates-formes d'xecution
Diffrentes faons
de les implmenter
Pour EJB : IBM Websphere, BEA Weblogic, Jboss, Jonas, ...

Pour SCA : Apache Tuscany, IBM Websphere, HydraSCA, fabric3, ...
...
Il nexiste pas un unique modle composants

Pas un modle meilleur que les autres
Utilisation d'un modle particulier guide par les besoins applicatifs
et techniques
- 69 -
Convergence composants / services

Ports de composants = services
Le service dsigne le point de vue du consommateur, cest
dire la vue externe du composant
Composant = fournisseur / consommateur de services

Notion de contrat trs importante dans les SOA
Norme SCA, le meilleur reprsentant

de cette convergence
- 70 -
Composant SCA
Initiative :
IBM, Oracle, BEA, SAP, Sun, TIBCO,
But :
structurer l'implmentation des SOA
Indpendances
langage de programmation
protocoles de communication
- 71 -
Assemblage de composants SCA

Choix communication au niveau des
connecteurs
WSDL/SOAP
Java RMI
JMS
...
Choix du langage
dimplmentation
Java
C++
BPEL
...
Source : oasis-open.org
- 72 -
Bilan : les couches SOA

**
- 73 -

**
- 74 -

**
Ces diffrents
modes de couplage
sont ncessaires et
dpendent du
niveau dans
larchitecture
- 75 -
Quels sont les lments cl dune

architecture oriente services ?
- 76 -
Architecture triangulaire
Toutes les parties ne sont pas forcment rifies
Source : Didier Donsez

- 77 -
Standards de larchitecture triangulaire

Les standards sont un lment
cl dune SOA, ils assurent
linteroprabilit
UDDI
Les trois piliers

des Services Web
Microsoft, IBM, HP
Universal Description Discovery and Integration

Enregistre les services
WSDL
WSDL
Web Services
Description Language
Web Services
Description Language
Dcrit le contrat
Dcrit le contrat
W3C
W3C
SOAP
W3C
Simple Object Access Protocol

Transporte
- 78 -
BPEL le chef dorchestre

Standard de lOASIS
Norme permettant de dcrire des orchestrations de
services en XML
Support des processus mtier
Propose les fonctions basiques dun langage de
programmation : sequence, flow, loop, switch
Identification des Instances de Process
Gestion des transactions
Gestion des fautes
BPEL
Oasis
Business Process
Execution Language
Dcrit les
processus mtier
- 79 -
SOA et web services

Attention ne pas confondre les 2 !
SOA est un ensemble de concepts :
Une SOA peut se mettre en uvre sans Web
Services
Les WS sont de lordre de la technologie :
On peut utiliser les Web Services sans faire de SOA
Les WS constituent la meilleure solution

standardise disponible
- 80 -
Architecture triangulaire enrichie

Services annots et recherchs smantiquement
- 81 -
Architecture triangulaire avec composants

Les fournis et requis sont explicits (en vert)
Fournisseurs et consommateurs sont des composants
Implmentation ddie en SCA
- 82 -
Dtails de larchitecture technique

Service
consumer
Repository
Contract
Mediation layer/Service bus
Service
provider
Business service
orchestrator
Business
process description
Registry
- 83 -

1 . a Search for service
Service
consumer
Repository
Contract
Service
provider
Business service
orchestrator
Business
process description
Registry
- 84 -

Service
consumer
Repository
1 . b Return contract
Contract
Service
provider
Business service
orchestrator
Business
process description
Registry
- 85 -

Service
consumer
Repository
Contract
2. a Create a process instance
Service
provider
Business service
orchestrator
Business
process description
Registry
- 86 -

Service
consumer
Repository
Contract
2. b
Execute
process
Service
provider
Business service
orchestrator
Business
process description
Registry
- 87 -

Service
consumer
Repository
Contract
2. b
Execute
process
Service
provider
Business service
orchestrator
2. c Retrieve service
end- point
Business
process description
Registry
- 88 -

Service
consumer
Repository
Contract

2. d Send request
Service
provider
2. b
Execute
process
Business service
orchestrator
2. c Retrieve service
end- point
Business
process description
Registry
- 89 -
ESB : couche de mdiation

Fournit des points dentre normaliss vers les services
On ne sait pas qui fournit le service ni comment il le fournit
Infrastructure qui optimise les changes entre

consommateurs et fournisseurs de services. Il peut
prendre en charge :
routage
transformation des donnes
orchestration
transactions,
scurit,
qualit de service,
Le but dun ESB est de permettre de communiquer de

manire simple et standardise entre des applications
htrognes
- 90 -
Quelques manires dimplmenter un ESB

Intergiciels de type MOM (Message Oriented
Middleware)
Intergiciels de type Bus (CORBA par exemple)
Intergiciels de type EAI (Message Broker avec
connecteurs propritaires lis au moteur dintgration)
Routeurs Web services tel que WebSphere Web
Services Gateway
Selon le type dimplmentation retenu, lESB
assurera plus ou moins de services : le choix

dpend des besoins
LESB nest pas obligatoire : mais il est fortement

recommand pour viter le couplage entre
fournisseur et consommateur
- 91 -
Java Business Integration (JBI)

Spcification visant standardiser les plates-formes
d'intgration via un jeu d'API
But : faciliter l'intgration de donnes en provenance de
sources diffrentes au sein d'un SI compos
d'applications htrognes
Permet tout fournisseur les respectant de pouvoir se
connecter un conteneur JBI pour changer des
messages avec le reste du SI
Petals ESB (utilis en TD) est une implmentation de cette
norme
- 93 -
Architecture JBI
Architecture composants pluggable pour intergiciels
2 types de composants :
Service Engine (SE) : hbergement des composants mtier
Binding Component (BC) : gestion des communications externes
Les composants peuvent tre rajouts sur le bus dynamiquement

Packaging des services 2 niveaux :
Service Unit (SU) : dploiement dun composant mtier
Service Assembly (SA) : dploiement dun assemblage
BC
SE
- 94 -
Mapping JBI/SCA : Approches complmentaires

SCA pour la dfinition et l'assemblage des composants
JBI plateforme d'excution pour lhbergement des
composants et la gestion des bindings distants
Hberger les composants via les Service Engines
Appeler les rfrences distantes via les Bindings Components
Exposer les services comme des endpoints JBI
Source : ICARE'08
- 95 -
Autre dclinaison de SOA : la WOA

REST (Representational State Transfer)
Les services Restful exposent leurs donnes et

fonctionnalits en tant que ressources travers des URI
Principe duniformit des interfaces : les consommateurs
interagissent avec les ressources travers un ensemble
prdfini et fixe de verbes (essentiellement CRUD)
Plusieurs reprsentions des ressources sont acceptes
URLs
ContentTypes
HTTP
methods
i.e., GET, POST, PUT, DELETE
i.e., (X)HTML, XML, JSON, txt

- 97 -
Conclusions
- 98 -
Du dj vu ?
SOA est une volution des paradigmes passs, tout en
prservant les caractristiques russies des architectures
traditionnelles
Contractualisation des services
Design by Contract (Meyer)
Dcouplage Interface/Implmentation,
interoprabilit, transparence des communications,
Middlewares la CORBA
Dcouplage fournisseur/comsommateur
Message Oriented Middleware (MOM)
Orchestration des services
Travaux autour des workflows, langages de coordination
SOA est une volution plutt quune rvolution

- 99 -
Assembleur
Langages machine
Chronique dune volution
objets
Langages
procduraux
**
*
services
services
composants
01011
10100
11000
01011
Niveaux dabstraction grandissant
Source : cole Hes SO
- 100 -
Synthse
Depuis
Vers
Orient fonctionnalits
Conu pour durer
Cycle de dveloppement long
Orient processus
Conu pour changer
Dveloppement et
dploiement interactif
Silos applicatifs
Couplage fort
Orient Objet
Orchestration de Services
Couplage faible
Orient message
Source : cole HEVs

- 101 -
Avantages et inconvnients
Architecture adaptative
Rutilisation du code
Productivit accrue
Manque de maturit de certains outils

Lenteur dexcution
Difficile effectivement implmenter
Peu de chose sur la contractualisation avane
- 102 -
Paradoxe des principes fondamentaux

MAIS un standard reste un standard tant quil y a
hgmonie (cf chec de CORBA)
Course la spcification
W3C vs OASIS vs OMG
UML
BPEL
WS-CDL
BPMN
SOAML
ebXML BPSS
- 103 -

Pas de remise en cause de lexistant lors
dvolutions technologiques
MAIS les diteurs nous asservissent avec leurs
suites doutils
services
- 104 -

Dcouplage entre fournisseurs et consommateurs de
services
MAIS pas de garde fou par rapport au couplage fort entre
fournisseurs et consommateurs possiblement rintroduit par la

couche IT
services
- 105 -

Dcouplage entre fournisseurs et consommateurs de
services
Mais les services sont fortement coupls une prsentation
(IHMs) cest- - dire les consommateurs ultimes !

Lorsque des services sont orchestrs, comment
les prsenter lutilisateur ? Comment obtenir
une orchestration de leur IHM ?
Flight Application
Hotel Application
IHM*
IHM*
Tour operator Application
service
Les IHM ne sont pas des

services actuellement
IHM *
service
Orchestration
de services
- 106 -

Indpendance des ressources vis vis de ceux qui
les utilisent
MAIS la gestion des donnes et leur virtualisation
est encore un enjeu
Les services doivent tre sans tat
MAIS beaucoup proposent de fdrer laccs aux
donnes par des services
- 107 -
Visionnez la vido suivante :

http://www.youtube.com/watch?v=ohPFC-9zuLs
Quelques rfrences ...

Urbanisation et BPM - Yves Caseau, DSI Bouygues Tlcom, Edition
Dunod
Consortiums autour de SOA, SCA, BPM et BPEL et standards des
services web
http://www.soa-consortium.org
http://www.osoa.org
http://www.oasis-open.org
http://www.bpmn.org
http://www.w3c.org
Voir la bibliographie complte sur le site web du module
- 109 -
Quelques rfrences ...

Modles composants
CCM spec
http://www.omg.org/cgi-bin/doc?ptc/2002-08-03
Fractal spec
http://fractal.objectweb.org/
Service Component Architecture (SCA)
http://www-128.ibm.com/developerworks/library/specification/ws-sca/
OpenCCM
http://openccm.objectweb.org/
Sofa
http://dsrg.mff.cuni.cz/projects/sofa/tools/doc/compmodel.html
- 110 -

Intro Concepts Principes Soa

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Intro Concepts Principes Soa

Transféré par

Droits d'auteur :

Formats disponibles

Module Architecture SOA & Workflow

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Vous avez dit SOA?

Une architecture base sur un fournisseur, un

Un style de programmation avec ses standards,

Les langages/technologies/outils que vous allez utiliser :

Un environnement de modlisation utilisant la notation BPMN

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Plan et valuation du module

Des rendus de projet en groupe

(c) 2012-2013, Occello Audrey, module SOA & Workflow

(c) 2012-2013, Occello Audrey, module SOA & Workflow

A quels besoins rpond SOA ?

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Problmatique de lintgration en entreprise

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Du "conu pour durer" au "conu pour changer"

besoins fonctionnels au niveau de la conception de

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Besoins mtier vs contraintes techniques

Pas de mutualisation des dveloppements entre projets

et peu de rutilisation possible

(c) 2012-2013, Occello Audrey, module SOA & Workflow

e-store : domaines mtier et architecture

(c) 2012-2013, Occello Audrey, module SOA & Workflow

e-store : domaines mtier et architecture

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Cots considrables dans la gestion des flux entre

dpartements et dans lintgration de leurs SI

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Hier : plat de spaghettis

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Demain : Architecture urbanise

Objectif : faire voluer le SI au mme rythme que la stratgie

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Vers toujours plus d'abstraction

Et maintenant les services !

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Quels sont les principes de base du SOA ?

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Principes fondamentaux de larchitecture SOA

Quest ce quun Service (au sens SOA) ?

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Exemple de couplage fort : Gestion de prts

LoanAgent est li LoanApproval et Loan

Exemple de couplage fort : Gestion de prts

LoanAgent est li LoanApproval et Loan

Gestion de prts en couplage faible

Est ce quune entit a un rle part ?

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Gestion de prts en couplage faible

Est ce quune entit a un rle part ?

Gestion de prts en couplage faible

Est ce quune entit a un rle part ?

Gestion de prts en couplage faible

Est ce quune entit a un rle part ?

Orient application vs orient services

(c) 2012-2013, Occello Audrey, module SOA & Workflow

(c) 2012-2013, Occello Audrey, module SOA & Workflow

(c) 2012-2013, Occello Audrey, module SOA & Workflow

(c) 2012-2013, Occello Audrey, module SOA & Workflow

Mais qu'est ce qu'un processus mtier ?

permet d'identifier, de matriser et d'optimiser les

Exemple de processus (notation informelle)