SOA : Architecture Logique :

Principes, structures et bonnes pratiques

Auteur: Gilbert Raymond
gilbert.raymond@softeam.fr

Version 2.1
avril 2011






Softeam
21 avenue Victor Hugo
75016 Paris
www.softeam.fr
Livre blanc
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 2 sur *1
Table des matires
1 Introduction ................................................................................................................ 3
2 Principes et motiations............................................................................................... !
3 "es #l#ments de base de l$arc%itecture......................................................................... &
*.1 #om"osant de service...................................................................................................... 6
*.2 +us d,entre"rise ............................................................................................................... 7
*.* #ontrat de service ............................................................................................................ -
*.. onn$es d,$c/anges et donn$es "ersistantes................................................................. 0
! Typolo'ie et modle en couc%es lo'i(ues................................................................... 11
..1 #om"osant 1ntit$........................................................................................................... 1*
..2 234 et Processus............................................................................................................ 1.
..* #om"osant Processus .................................................................................................... 15
... #om"osant 5onction...................................................................................................... 16
..5 #om"osant 'tilitaire et "ublic ....................................................................................... 17
..6 #om"osant Pr$sentation................................................................................................ 17
) *#marc%e et identification......................................................................................... 1+
5.1 $marc/e orient$ "rocessus ......................................................................................... 10
5.2 $marc/e orient$e donn$e........................................................................................... 20
5.* $marc/e orient$e a""lication...................................................................................... 20
5.. 6estion des versions ...................................................................................................... 21
5.5 2"$cification $tendue et tests........................................................................................ 22
& ,arto'rap%ie et modles............................................................................................ 2!
6.1 #artogra"/ie des services .............................................................................................. 2.
6.2 2tructure g$n$rale du syst7me ...................................................................................... 2.
6.* $"endance d,interfaces ............................................................................................... 25
- Structuration du SI et application............................................................................... 2&
7.1 4""lication com"osite.................................................................................................... 26
7.2 Visibilit$ et structuration du 2(....................................................................................... 27
. /ise en 0ure........................................................................................................... 2.
+ Glossaire ................................................................................................................... 2+

Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page * sur *1
1 Introduction
8,arc/itecture orient$e service 9234: s,est im"os$e au;ourd,/ui comme un t/7me ma;eur "our les
syst7mes d,information d,entre"rise. Plus )u,une nouvelle tec/nologie ou m$t/ode< c,est la
convergence de "lusieurs a""roc/es e=istantes< et l,$mergence d,un style d,arc/itecture et de
gouvernance de 2(.
SOA SOA
BPM
BPM
changes orient
document (XML)
changes orient
document (XML)
EAI
EAI
Approche par
Composant
(Herzum & Sims)
Approche par
Composant
(Herzum & Sims)
Distribution
(Corba, DCOM)
Distribution
(Corba, DCOM)
Approches
Orientes Objets
Approches
Orientes Objets
Urbanisation,
cartographie
Urbanisation,
cartographie
Web services Web services
SOA SOA
BPM
BPM
changes orient
document (XML)
changes orient
document (XML)
EAI
EAI
Approche par
Composant
(Herzum & Sims)
Approche par
Composant
(Herzum & Sims)
Distribution
(Corba, DCOM)
Distribution
(Corba, DCOM)
Approches
Orientes Objets
Approches
Orientes Objets
Urbanisation,
cartographie
Urbanisation,
cartographie
Web services Web services

Figure - SOA : ! la con"ergence de solutions
#e"endant< il ne s,agit "as d,une sim"le ;u=ta"osition de tec/ni)ues dis"arates. 234 int7gre ces
diff$rentes "rati)ues dans un cadre organis$ > l,arc/itecture des syst7mes< fortement guid$e "ar le
m$tier. 1n effet< les e="$riences tro" focalis$es sur une a""roc/e uni)ue ou guid$es "ar la tec/ni)ue
n,ont "as a""ort$ de r$"onses satisfaisantes.
ans cette o"ti)ue< l,arc/itecture logi)ue occu"e une "lace centrale. (nstrument "rivil$gi$ "our la
construction et la maintenance du syst7me< "ivot sur le)uel s,articulent le m$tier et sa traduction
logicielle< elle constitue la r$f$rence "our l,organisation des "ro;ets< la construction tec/ni)ue et le
"lan de "rogression. ?outefois< l,arc/itecture logi)ue n,est "as un mod7le abstrait< ni une
cartogra"/ie fonctionnelle cible lointaine. (l s,agit "lus "ragmati)uement de la descri"tion des
constituants du syst7me et de leurs relations.
#e document "r$sente l,arc/itecture logi)ue dans le cadre de notre a""roc/e 214 92ervice 1ntre"rise
4rc/itecture:.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page . sur *1
2 Principes et motivations
234 92ervice 3riented 4rc/itecture: est un style d,arc/itecture organis$ ! "artir de services m$tiers
communs mutualis$s "our un ensemble de lignes m$tiers ou d,a""lications.
234 is an a""roac/ to designing software t/at dissolves business a""lications into se"arate @servicesA
t/at can be used inde"endent of t/e a""lications of w/ic/ t/ey,re a "art and com"uting "latforms on
w/ic/ t/ey run.
Bay iCare< (+C 6lobal 2ervices< 2006
8a motivation fondamentale vient du constat suivant > 8e cloisonnement en silos a""licatifs
ind$"endants 9blocs monolit/i)ues: est une des sources ma;eures des difficult$s rencontr$es "our le
traitement des $volutions et la maintenance des syst7mes.

Figure # - Architecture orient$e application "s architecture orient$e ser"ice
A la rec%erc%e de l$a'ilit#. #ette notion n,est "as nouvelle> 8es 2yst7mes d,(nformation sont en
constante $volution et les obstacles rencontr$s sont largement d$battus de"uis des ann$es< mais ces
)uestions ac)ui7rent au;ourd,/ui une acuit$ "articuli7re. 8es organisations sont confront$es ! des
demandes de c/angement tou;ours "lus $tendues et "lus fr$)uentes. #es c/angements sont li$s ! la
fois au= r$organisations 9fusion< ac)uisitions:< ! l,ouverture des "rocessus et ! la multi"lication des
$volutions des marc/$s> 3n l,observe "ar e=em"le dans le secteur des services de telecom< dans les
ban)ues assurances< le trans"ort et l,$nergie< ou dans le commerce en ligne. 8es a""lications
construites et structur$es "our r$"ondre ! des besoins "articuliers dans un conte=te donn$ ne sont
"lus ada"t$es au= r$alit$s "r$sentes. 8es c/angements tec/nologi)ues a;outent encore des
contraintes su""l$mentaires. 4u= del! d,un certain stade< les coDts induits "ar les modifications
deviennent "ro/ibitifs< et les d$lais incom"atibles avec les demandes m$tiers. 8e syst7me devient
tro" rigide< "risonnier de son arc/itecture ant$rieure. 8es $volutions r$alis$es dans ce cadre
d$t$riorent la )ualit$ du syst7me et renforce encore ces difficult$s.
Euel)ues constatations ma;eures >
8,agilit$ d,un syst7me d$"end au "remier ordre du syst7me r$el d$"loy$. 8es diff$rentes
re"r$sentations< mod7les ou cartogra"/ies< si elles facilitent la tFc/e< et sont souvent
n$cessaires< n,$liminent "as la nature des obstacles rencontr$s.
8es infrastructures tec/nologi)ues transverses 9middleware< web services< G: ne constituent
;amais en soi de solutions radicales. 3n observe au contraire )ue les strat$gies tro" ancr$es
sur les tec/nologies mas)uent les r$alit$s m$tiers et "euvent aboutir ! des r$sultats
d$cevants et contre "roductifs.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 5 sur *1
8es syst7mes logiciels sont $labor$s< d$velo""$s "ar des $)ui"es. 8e travail /umain reste
largement ma;oritaire dans nos m$tiers et l,organisation< la gestion efficace des /ommes est
une des cl$s de la r$ussite.
8,arc/itecture orient$e service se base sur les "rinci"es suivants>
*iiser pour r#'ner > 2ubstituer la d$cou"e strictement a""licative "ar une structuration en
com"osants "lus r$duits et "otentiellement "lus sim"les ! faire $voluer.
Ali'nement m#tier > #onstruire et organiser le syst7me ! "artir des r$alit$s m$tiers< )ui
doivent se retrouver dans ses constituants.
1eutralit# tec%nolo'i(ue > 4ssurer une ind$"endance totale entre les interfaces et les
im"l$mentations. 8,$l$ment )ui utilise un service ne doit "as Htre contraint ni "ar la
tec/nologie d,im"l$mentation< ni "ar sa localisation 9"otentiellement distribu$:.
/utualisation > 5avoriser la r$utilisation de services m$tiers "ar "lusieurs lignes m$tiers ou
a""lications. Permettre la construction de services de /aut niveau "ar combinaison de
services e=istants.
Automatisation des processus m#tier. (soler la logi)ue des "rocessus m$tiers sur des
com"osants d$di$s )ui "rennent en c/arge les enc/aInements de tFc/es et les $c/anges de
flu= d,information.
2c%an'es orient#s *ocument. 8es informations $c/ang$es "ar les services "oss7dent une
structure "ro"re< guid$e "ar les besoins m$tiers. 3n "rivil$gie la transmission de contenus
com"lets et utilisables au "rofit d,acc7s direct au= structures de ty"e ob;et ou relationnel.

8a "lu"art des acteurs 234 "r$conisent une mise en Juvre "rogressive< e=cluant les o"$rations de
ty"e K big bang L< avec une co/abitation entre les constituants divers 9legacy< anciennes a""lications<
1MP etcG: et les services 234.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 6 sur *1
3 Les lments de base de larchitecture
3.1 Composant de service
8e composant de service est la bri)ue de base de l,arc/itecture N5igure *O. (l se d$com"ose en deu=
"arties > la vue externe 9ou s"$cification de service:< )ui e="ose la facette service "ro"rement dite< et
la vue interne< )ui d$crit le contenu du com"osant
12
. 8a vue e=terne est constitu$e "ar un ensemble
d,o"$rations de service regrou"$es en interfaces 9au sens 'C8:< et de l,a""areillage "our les utiliser
9ty"es des donn$es $c/ang$es< contrat de service< "ro"ri$t$s< etc.G:. #ette s"$cification est d$crite
en g$n$ral "ar un fic/ier P28
*
ou $)uivalent.
Composant de service Composant de service
Donnes
dchange
Logique interne Data
Contrats
Primtre
Contrat dutilisation
des services
TDE: Types de
donnes dchange
Domaine dappartenance,
visibilit
Vue externe
Vue interne
Opration1
Opration2

Interface A
Opration1
Opration2

Interface B
Services utiliss
Services utiliss
Composant de service Composant de service
Donnes
dchange
Logique interne Data
Contrats
Primtre
Contrat dutilisation
des services
TDE: Types de
donnes dchange
Domaine dappartenance,
visibilit
Vue externe
Vue interne
Opration1
Opration2

Interface A
Opration1
Opration2

Interface A
Opration1
Opration2

Interface B
Opration1
Opration2

Interface B
Services utiliss
Services utiliss
Services utiliss
Services utiliss

Figure % & Structure du composant de ser"ice
8a vue interne contient des informations relatives ! la logi)ue interne comme le d$tail des
traitements ou les bases de donn$es mani"ul$es. 3n y trouve $galement les r$f$rences vers les
services utilis$s "ar le com"osant. #ette vue est mas)u$e au= consommateurs du com"osant de
service. 1lle est em"loy$e notamment "ar les arc/itectes 2(< )ui travaillent sur la vision globale du
syst7me.
Vue externe
Liens de dpendance Vue interne
Vue externe
Liens de dpendance Vue interne

Figure ' - Repr$sentation sch$matique du syst(me

1
8a notion de com"osant ou de com"osant de service se retrouve notamment dans 2#4 92ervice #om"onent
4rc/itecture: "ro"os$ "ar l,organisme 3"en 234 9www.osoa.org:
2
3n retrouve des notions similaires dans ?ogaf0Q c/a"itre 22.7 9www.o"engrou".org:
*
Peb 2ervices escri"tion 8anguage. www.w*.org
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 7 sur *1
2c/$mati)uement< l,articulation des com"osants de service< avec leurs liens de d$"endance<
constitue la structure du syst7me N5igure .O. #/a)ue com"osant de service "eut invo)uer les
o"$rations de service d,autres com"osants< dans la mesure ou les r7gles de visibilit$ sont res"ect$es.
,omposants et serices. ans cette a""roc/e< le service d$signe le "oint de vue du consommateur< c,est
! dire la vue e=terne du com"osant de service. Par e=em"le le service de gestion des commandes R vue
e=terne du #om"osant K gestion des commandes L. 8e catalogue des services "ubli$s sur un "$rim7tre
est constitu$ "ar l,ensemble des vues e=ternes des com"osants de service.
8es com"osants de service sont identifi$s et d$finis avant tout suivant une logi)ue m$tier<
ind$"endamment de la tec/nologie. 3n distingue "our ce faire le composant logique< )ui fi=e la
structure du syst7me dans le cadre de l,arc/itecture logi)ue< et le composant logiciel< )ui est sa
traduction tec/ni)ue d$"loy$e.
3.2 Bus dentreprise
8e syst7me est constitu$ d,un ensemble de participants communi)uant )ui ;ouent le rSle de
consommateur et de fournisseur de service. 8es consommateurs de service "euvent Htre divers > des
a""lications< "rogiciels ou d,autres com"osants de service.
8es com"osants de service sont les fournisseurs de service du syst7me< dans les)uels on distingue
deu= familles> les com"osants )ui "rennent en c/arge directement l,im"l$mentation des services et
ceu= )ui d$l7guent cette im"l$mentation ! un tiers 9mainframe< 1MP< a""lication e=istante:. (l faut
n$anmoins "r$ciser )ue dans ce cas de figure< le com"osant n,est "as tou;ours assimil$ ! un sim"le
"asse%"lat. es traitements d,ada"tation sont fr$)uemment n$cessaires 9format des donn$es<
enca"sulation de service: afin de mieu= int$grer les besoins des consommateurs de service.
Bus de communication (ESB)
MainFrame
Application 1 Application 2
ERP
SGBD
Bus de communication (ESB)
MainFrame
Application 1 Application 2
ERP
SGBD

Figure ) & *S+ et ,omposants de ser"ice
8e bus d,entre"rise 912+: agit comme la colonne vert$brale reliant ces "artici"ants d,une mani7re
banalis$e ! travers les interfaces de services. #ela "ermet notamment les modifications
d,im"l$mentation ou le rem"lacement des K legacy L sans remanier la structure de fonctionnement
du syst7me.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page - sur *1
3.3 Contrat de service
8e contrat de service
.
;oue un rSle ma;eur > il d$taille les conditions d,utilisation du service sous
forme de "r$ et "ost conditions< "rotocoles< et contraintes 9Eo2< 284
5
:. 8es contraintes non
fonctionnelles N?ableau 1O "ermettent de fi=er les termes du contrat o"$rationnel entre
consommateur et fournisseur de service.
-ableau - ,ontraintes non .onctionnelles
Type de contraintes 23emples
is"onibilit$ ?au= d,indis"onibilit$ "ar an< Plages /oraires
#ontraintes de maintenance
Performance ?em"s de r$"onse moyen< minimum
Tombre de transactions "ar seconde
5iabilit$ ?au= d,erreur
2$curit$ Politi)ue de droits d,acc7s< Ton r$"udiation
4dministration Bournalisation< ?ableau= de bord< statisti)ues
8e "rotocole d,utilisation d,un com"osant de service d$finit les s$)uences valides d,invocation des
ses o"$rations N5igure 6O. 4 noter )ue les com"osants de service ne sont "as des ob;ets > ils ne
conservent aucun $tat 9une seule instance du com"osant est dis"onible:. 8es conditions "ortent sur
des attributs des donn$es d,$c/ange transmises lors de l,invocation des o"$rations > dans l,e=em"le
N5igure 6O l,$tat est un attribut de ty"efacture transmis en entr$e de c/a)ue o"$ration du com"osant
5acture.
mise
Cre
Rgle
Annule
mettre
rgler
annuler
annuler mise
Cre
Rgle
Annule
mettre
rgler
annuler
annuler
crer(typeFacture): typeFacture
modifier(typeFacture): typeFacture
emettre(typeFacture): typeFacture
regler(typeFacture): typeFacture
annuler(typeFacture): typeFacture
Interface dcriture
crer(typeFacture): typeFacture
modifier(typeFacture): typeFacture
emettre(typeFacture): typeFacture
regler(typeFacture): typeFacture
annuler(typeFacture): typeFacture
Interface dcriture
Composant
Facture
Numero
Etat
NumeroClient
Date
typeFacture
Numero
Etat
NumeroClient
Date
typeFacture

Figure / - protocole d0utilisation du composant Facture
ans la mHme o"ti)ue< les "r$ et "ost conditions d$taillent encore les conditions d,utilisation sur les
o"$rations de service
6
.

.
Voir notamment> Meference Codel for 2ervice 3riented 4rc/itecture. 342(2. www.oasis%o"en.org
5
Eo2> Euality of 2ervice. 284> 2ervice 8evel 4greement.
6
Me"rise des m$t/odes de programmation par contrat. fr.wiUi"edia.orgVwiUiVProgrammationW"arWcontrat
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 0 sur *1
3.4 Donnes dchanes et donnes persistantes
8a distinction entre les donnes dchange et les donnes persistantes est in/$rente au=
arc/itectures 234< )ui isolent les bases de donn$es ! l,aide de services d,acc7s N5igure 7O. 8es
donnes dchange sont les informations v$/icul$es entre les "artici"ants 9consommateurs ou
fournisseurs de service: ! travers l,invocation des o"$rations de service. 8es donn$es "ersistantes
sont les informations contenues et g$r$es dans les bases de donn$es. #es informations sont
structur$es de faXon /abituelle 9"ar e=em"le 26+ en mode relationnel:< dans le cadre de
r$f$rentiels ou de bases a""licatives.
Zone de stockage
Donnes persistantes
Zone dchange
Donnes dchange, flux
Metadata
Service bus
Messages
Interfaces, schmas XML
Formats dchange
MCD, MPD,
schmas
Applications
Applications
Services
Bases
Services
Services
Services
Services
Zone de stockage
Donnes persistantes
Zone dchange
Donnes dchange, flux
Metadata
Service bus
Messages
Interfaces, schmas XML
Formats dchange
MCD, MPD,
schmas
Applications
Applications
Services
Bases
Services
Services
Services
Services

Figure 1 - 2onn$es d0$change et donn$es persistantes
8es types de donne dchange 9?1: $tablissent la s$manti)ue< la structure et le format de ces
donn$es. (ls "euvent Htre d$finis ! l,aide de sc/$mas YC8 9et $ventuellement de classes 'C8:.
#/a)ue o"$ration de service "r$cise les ty"es de donn$e d,$c/ange en entr$e et en sortie.
-ableau # - Op$rations de ser"ice: e3emples
4p#ration de serice 2ntr#e5s6 Sortie5s6
cr$er#ommande ?1W#ommande
valider#ommande ?1W#ommande ?1W1tatValidation
8es caract$risti)ues des ?1 sont les suivantes >
3n "rivil$gie les messages K gros grain L< )ui regrou"ent un ensemble d,informations e="loitables
"ar le m$tier< et )ui minimisent le nombre d,invocation d,o"$ration de service N5igure -O.
8a structure et l,organisation des ?1 n,est "as contraint "ar des normalisations 9entit$%relation ou
orient$ ob;et:. 3n "arle de contenu orient$ document< ou message< dans le)uel on trouve une co"ie
des $l$ments "roc/e de la vision m$tier. 9Par analogie avec le fonctionnement d,une messagerie< ou
c/a)ue message est constitu$ d,$l$ments dont la co/$rence est valid$e "ar le "ro"os du message
lui%mHme:.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 10 sur *1
<commande>
<client>
<nom> Durand </nom>
<noContrat> 27615 </noContrat>
</client>
<montant> 522 </montant>
<date> 15O12007 </date>
<ligneCommande>
<noProduit> 432 </noProduit>
<quantit> 3 </quantit>
</ligneCommande>
<ligneCommande>
<noProduit> 603 </noProduit>
<quantite> 1 </quantite>
</ligneCommande>
</commande>
Figure 4 & *3emple de donn$e d0$change 5-2*6,ommande0 7.ormat 89L:
ans le cadre 234< la gouvernance des donn$es int7gre la gestion des donn$es "ersistantes< des
donn$es d,$c/ange et de leurs liens. 8a maItrise de cette gestion est fondamentale et doit Htre
trait$e avec une attention "articuli7re. 1n effet< le contenu et la structure des donn$es d,$c/ange
sont en grande "artie issus des donn$es "ersistantes et le bon fonctionnement du syst7me n$cessite
la descri"tion d$taill$e de ces relations.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 11 sur *1
4 !"poloie et mod#le en couches loi$ues
8a mise en Juvre de services< au= travers de com"osants de service est%elle suffisante Z 5orce est de
constater )ue les 2( sont des syst7mes com"le=es et souvent /$t$rog7nes. 8a "rolif$ration
d,$l$ments< fussent ils des services m$tiers< s,$c/angeant toutes sortes de messages ne constitue "as
une image tr7s rassurante "our un 2( 9on "arle de la d$rive 2"ag/etti 3riented 4rc/itecture:.
7849S 9Bust a +unc/ of Peb 2ervices:. 4n effective< functioning service%oriented arc/itecture re)uires
governance< and t/e ability to s/are services across multi"le business units and enter"rises. (t,s easy to
build Peb services. [ou could build 10 of t/em in an afternoon. +ut< t/en you end u" wit/ a B+3P2
arc/itecture 9Bust a +unc/ of Peb 2ervices:< w/ic/ will grow into a different sort of 234 \ a 2"ag/etti%
3riented 4rc/itecture. Boe Cc]endricU < december 2006< ^ Tet.
(l e=iste un consensus au;ourd,/ui "our bFtir les arc/itectures de syst7me ! "artir d,une ty"ologie de
services bien $tablie< organis$e en couc/es logi)ues 9?ableau *:. 1n g$n$ral les as"ects "rocessus
s,a""uient sur des services "lus basi)ues "lus "roc/es des donn$es.
-ableau % - Les di..$rentes propositions de typologies de ser"ices
:er;um
< Sims
-

2S4A
.
/icrosoft
+
I8/
1=
To'af
11
9i>ipedia
12
Types S2A
5ront end
4""lication
Presentation
8ayer
Presentation Presentation Pr$sentation
Processus Process
centric
+usiness
Process
+usiness "rocess
c/oreogra"/y
Process services Process Processus
(ntermediary +usiness
2ervice
#om"osite service 4""lication
services
5unctionality 5onction
1ntit$ +asic ata 2ervice 2ervice ata services ata 1ntit$
'tilitaire 'tilitaire
Public Public
Tous avons c/oisi "our 214 de distinguer . ty"es de com"osant> Prsentation< Processus< Fonction<
Entit< organis$s en . couc/es logi)ues de stabilit$ croissante< au=)uels nous a;outons les
com"osants Utilitaire et Public< en c/arge des fonctions transverses et des $c/anges avec les
syst7mes e=ternes.

7
+usiness #om"onent 5actory< Peter Her_um ` 3liver 2ims< Piley #om"uting Publis/ing 2000
-
1nter"rise 234< irU ]raf_ig< ]arl +anUe< irU 2lama< ?/e #oad 2eries< 2005
0
4n 3verview of 2ervice%3riented 4rc/itecture in Metail< Coin Coinuddin< Cicrosoft< Banuary 2007
10
+ern/ard +orges< ]errie Holley and 4li 4rsan;ani< (+C < 15 2e" 200.< 2earc/Peb2ervices.com
11
?ogaf0 c/a"itre 22 9www.o"engrou".org:
12
@?/is is t/e ty"e of t/e service to /el" distinguis/ it in t/e layer in w/ic/ it resides> ata< 5unctionality<
Process< and PresentationA. /tt">VVen.wiUi"edia.orgVwiUiV2ervice%orientedWarc/itecture
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 12 sur *1
8es couc/es logi)ues de stabilit$ croissante $tablissent la r7gle de base de d$"endance > un
com"osant ne "eut "as utiliser un com"osant d,une couc/e d,un niveau su"$rieur 9"ar e=em"le< un
com"osant 1ntit$ ne doit "as utiliser un com"osant 5onction ou Processus:.
Entits
S
t
a
b
i
l
i
t

Fonction
Processus
Prsentation
P
u
b
l
i
c
s
P
u
b
l
i
c
s
U
t
i
l
i
t
a
i
r
e
U
t
i
l
i
t
a
i
r
e
Entits
S
t
a
b
i
l
i
t

Fonction
Processus
Prsentation
P
u
b
l
i
c
s
P
u
b
l
i
c
s
U
t
i
l
i
t
a
i
r
e
U
t
i
l
i
t
a
i
r
e

Figure ; - 9od(le en couches logiques
#/a)ue ty"e de com"osant ;oue un rSle s"$cifi)ue >
#om"osant @Pr#sentationA> Cise en oeuvre du dialogue avec l,utilisateur > (HC< gestion de la
session utilisateur 9#e n,est "as un com"osant de service ! "ro"rement "arler:
#om"osant @ProcessusA> su""ort de "rocessus m$tiers com"lets 9rSle d,orc/estration:a
s,a""uie notamment sur des com"osants de ty"e @5onctionA et @1ntit$A
#om"osant @?onctionA> #om"osition de services. 4da"tations fonctionnelles ou traitements
localis$s.
#om"osant @2ntit#A> 2ervice d,acc7s au= donn$es "ersistantes 9#M'
1*
:< au= bases de
donn$es et r$f$rentiels.
#om"osant @@tilitaireA> fournisseur de services d,infrastructure ou transversau= 9messagerie<
tableau de bord< $diti)ue< annuaire:
#om"osant @PublicA > d$di$s au= services accessibles ! l,e=t$rieur du 2( 9+2+< "artenaires:
Entit
Fonctions
processus
Prsentation
Entit
Fonctions
processus
Prsentation
Processus
Fonction
Prsentation
Entit
Achat Produit (Web)
Catalogue Commande Client
Processus Commande
Commande
Client
Processus
Fonction
Prsentation
Entit
Achat Produit (Web)
Catalogue Commande Client
Processus Commande
Commande
Client

Figure < - Architecture de composants de ser"ices: e3emple

1*
#M' > #reate< Mead< '"date< elete
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 1* sur *1
4.1 Composant %ntit
8es com"osants de service de ty"e 1ntit$ sont focalis$s sur un ob;et m$tier cl$ du syst7me 9"ar
e=em"le #lient< #ontrat< #ommande< G:. 8eur rSle est de "ermettre un acc7s au= informations
relatives ! cet ob;et m$tier< le "lus souvent associ$ ! une base de donn$es. 3n trouve ty"i)uement
les o"$rations de lecture< $criture ou de re)uHte N5igure 11O. 3n im"ose )ue tout acc7s ! un ob;et
m$tier cl$ "asse "ar le com"osant 1ntit$ corres"ondant )ui est uni)ue. Par e=em"le< la cr$ation<
modification ou lecture d,un ob;et #lient "asse obligatoirement "ar les o"$rations du com"osant
1ntit$ #lient.
Client
Lire(noClient): TDE_Client
Rechercher(criteres): listeDeClients
Interface de lecture
Crer(TDE_Client): TDE_Client
Modifier(TDE_Client): TDE_Client
Interface dcriture
Client
Lire(noClient): TDE_Client
Rechercher(criteres): listeDeClients
Interface de lecture
Crer(TDE_Client): TDE_Client
Modifier(TDE_Client): TDE_Client
Interface dcriture

Figure - ,omposant de ser"ice 5,lient5 a"ec ses deu3 inter.aces 7lecture et $criture:
8es ty"es de donn$e d,$c/ange 9?1: re"r$sentent la structure des flu= $c/ang$s via les o"$rations
de service 9entr$es et sorties des o"$rations:. Plusieurs ?1 sur le mHme ob;et "euvent Htre d$clar$s
N5igure 12O< en fonction du d$tail demand$ ou du "oint de vue.
Contenu synthtique
Contenu synthtique
TDE_Client2
adresse
1
Coordonnes
bancaires
1
Contenu synthtique
Contenu synthtique
TDE_Client2
adresse
1
Coordonnes
bancaires
1
Contenu dtaill
Contenu dtaill
TDE_Client1
adresse
Mtier
Entreprise
Poste
Secteur
1
*
*
*
*
1
1
Coordonnes
bancaires
1
Achats
Profil
* *
Contenu dtaill
Contenu dtaill
TDE_Client1
adresse
Mtier
Entreprise
Poste
Secteur
1
*
*
*
*
1
1
Coordonnes
bancaires
1
Achats
Profil Profil
* *

Figure # - 2eu3 types de donn$e d0$change 7-2*: de l0ob=et m$tier ,lient
(l y a une relation $troite entre le com"osants 1ntit$ et le mod7le des ob;ets m$tiers> Pour c/a)ue
ob;et m$tier cl$< on doit trouver un com"osant 1ntit$ corres"ondant. 8,identification des ob;ets
m$tiers cl$ d$"end du conte=te m$tier et re"rend les "rati)ues d,analyse e=istantes. Par e=em"le<
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 1. sur *1
les ob;ets K mineurs L ont "eu de sens utilis$s seuls 9adresse du client:. 4 l,inverse< les ob;ets m$tiers
cl$ interviennent directement dans les "rocessus< sous forme de flu=< ou sont les "lus utilis$s comme
tels "ar l,utilisateur du syst7me. 5inalement< les messages $c/ang$s lors de l,e=$cution des
o"$rations de service sont constitu$s "ar une gra""e d,$l$ments dont la racine est un ob;et m$tier
cl$. ?ec/ni)uement< ces messages sont g$n$ralement transmis sous la forme de documents YC8< et
les ty"es de donn$e d,$c/ange 9?1: d$crit "ar un sc/$ma 9Y2: corres"ondant.
4.2 &'( et Processus
ans le cadre 234< l,automatisation des "rocessus est un a=e ma;eur< avec les notions
d,orc/estration< com"osition de services ou de c/or$gra"/ie. (l s,agit de centraliser la logi)ue d,un
"rocessus dans un com"osant d$di$< )ui "rend en c/arge l,enc/aInement et les r7gles de gestion
associ$es N5igure 1*O. #ette a""roc/e tend ! r$duire les im"acts li$s au= $volutions du "rocessus.
Application
Commande
Application
Facturation
Application
Client
Enregistrement
commande
Enregistrement
facture
Mise jour du profil
Envoi facture
Commande Client
1
Processus Commande client
commande facture Client
Messagerie
Achat Web
Rgle de gestion
Si nouveau client, cration du client
Sinon mise jour du profil
Rgle de gestion
Si nouveau client, envoi dun
message de bienvenue
Commande Client
2
Application
Commande
Application
Facturation
Application
Client
Enregistrement
commande
Enregistrement
facture
Mise jour du profil
Envoi facture
Commande Client
1
Application
Commande
Application
Facturation
Application
Client
Enregistrement
commande
Enregistrement
facture
Mise jour du profil
Envoi facture
Commande Client
1
Processus Commande client
commande facture Client
Messagerie
Achat Web
Rgle de gestion
Si nouveau client, cration du client
Sinon mise jour du profil
Rgle de gestion
Si nouveau client, envoi dun
message de bienvenue
Commande Client
2
Processus Commande client
commande facture Client
Messagerie
Achat Web
Rgle de gestion
Si nouveau client, cration du client
Sinon mise jour du profil
Rgle de gestion
Si nouveau client, envoi dun
message de bienvenue
Commande Client
2

Figure % - Automatisation de processus> : orient$e applications #: orient$e ser"ices
'ne clarification est n$anmoins n$cessaire >
3n distingue les processus mtiers transverses et les processus de traitement. 8es "remiers
re"r$sentent les "rocessus de bout en bout de l,entre"rise< )ui d$livrent une valeur a;out$e tangible
! l,e=t$rieur "ar une collaboration de "lusieurs unit$s et acteurs. 8es seconds 9"rocessus de
traitement: re"r$sentent le d$roulement d,une activit$ s"$cifi)ue et localis$e.
Pour sim"lifier on "arlera de processus mtiers et de processus de traitement.
3n "eut utiliser une identification "lus formelle entre "rocessus m$tier et "rocessus de traitement > un
processus mtier est interru"tible et "oss7de un $tat )u,il doit conserver entre deu= interru"tions. 4
l,inverse< un processus de traitement n,est "as interru"tible et ne maintient "as d,$tat en de/ors de son
e=$cution.
'n "rocessus m$tier "eut durer "lusieurs ;ours< "lusieurs mois ou "lus > "ar e=em"le le traitement
d,un sinistre d,assurance ou la livraison d,un "roduit command$ N5igure 1.O. 8e "rocessus de
traitement au contraire a une dur$e limit$e et rel7ve "lus sim"lement d,une o"$ration informati)ue
/abituelle 9"ar e=em"le le contrSle et enregistrement d,un dossier< le destocUage d,un "roduit:.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 15 sur *1

Figure ' - Processus m$tier trans"erse : e3emple 7diagramme +P9?:
8,automatisation des "rocessus m$tiers 9transverses: est "rise en c/arge "ar les com"osants de ty"e
Processus. #ette automatisation est a""el$e Orchestration de service 9"ar analogie avec l,orc/estre
)ui com"rend un grand nombre de musiciens diff$rents collaborant ! l,e=$cution d,une sym"/onie
sous le contrSle du c/ef d,orc/estre:.
8es com"osants de ty"es 5onction sont en c/arge des "rocessus de traitement. (ls ;ouent $galement
le rSle d,ada"tation et d,agr$gation 9com"osition de service: entre les 1ntit$s et les "rocessus
m$tiers ou la vision utilisateur.
-ableau ' - Propri$t$ des composants de ser"ice de type Processus, Fonctions et *ntit$s
Type RAle Type de participant Granularit#
1!

Processus
Processus m$tier transverse.
3rc/estration de service
5ournisseur et
consommateur de
service
6ranularit$ $lev$e.
?ransverse "ar nature.
5onction
Processus de traitement<
com"osition de services<
ada"tation
5ournisseur et
consommateur de
service
6ranularit$ moyenne
1ntit$
4cc7s ! un ob;et m$tier cl$ 5ournisseur de service 6ranularit$ fine. 5ocalis$
sur un ob;et m$tier cl$
4.3 Composant Processus
8a distinction entre "rocessus m$tier et "rocessus de traitement n,est "as une sim"le )uestion de
vocabulaire. 8e ty"e de )uestion "os$ "ar l,automatisation des "rocessus m$tiers est tout ! fait
s"$cifi)ue > la gestion des $v7nements et des $tats du "rocessus< les actions de com"ensations
15
< le

1.
8a granularit$ est un indicateur informel li$ au "$rim7tre fonctionnel couvert "ar le com"osant.
15
8es actions de com"ensation d$finissent les traitements ! r$aliser en cas d,erreur ou d,e=ce"tions dans le
d$roulement du "rocessus< "our retrouver un $tat correct.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 16 sur *1
nombre et la diversit$ des services utilis$s. 3n est dans le domaine du +PC
16
< avec ses tec/ni)ues
sous%;acentes comme +P18< les m$t/odes de descri"tion ada"t$e 9voir le langage +PCT:< ou la
su"ervision de "rocessus 9+4C:.
8es o"$rations de service Processus sont li$es au= $v7nements du "rocessus > d$marrage< arrHt< ou
s"$cifi)ues au m$tier.
Processus Commande
DemarrerProcess(TDE_Commande, Client): TDE_DossierCommande
DepassementDelai (NoDossier)
RepriseProcess(NoDossier, Partenaire)
ConfirmerPrestation(NoDossier)
AnnulationCommande(NoDossier)
Interface Processus Commande
TDE Dossier
commande
Commande
Client
NoDossier: interger
Etat : TypeEtat
Dlai: Dure
Fournisseur
Processus Commande
DemarrerProcess(TDE_Commande, Client): TDE_DossierCommande
DepassementDelai (NoDossier)
RepriseProcess(NoDossier, Partenaire)
ConfirmerPrestation(NoDossier)
AnnulationCommande(NoDossier)
Interface Processus Commande
DemarrerProcess(TDE_Commande, Client): TDE_DossierCommande
DepassementDelai (NoDossier)
RepriseProcess(NoDossier, Partenaire)
ConfirmerPrestation(NoDossier)
AnnulationCommande(NoDossier)
Interface Processus Commande
TDE Dossier
commande
Commande
Client
NoDossier: interger
Etat : TypeEtat
Dlai: Dure
Fournisseur

Figure ) - ,omposant processus: inter.ace et type de donn$e d0$change
8e ty"e de donn$e d,$c/ange du "rocessus contient toutes les informations utiles ainsi )ue l,$tat du
"rocessus. #elui%ci est sauvegard$ ! c/a)ue sus"ension du "rocessus 9attente d,$v7nement:. 8e
"rocessus devient un ob;et ! "art enti7re< avec un $tat "ro"re< distinct de l,$tat des autres ob;ets
m$tiers 9commande< facture:. #ette distinction facilite le traitement des $volutions du "rocessus
m$tier< "ar le faible im"act induit sur les autres com"osants. 8,a;out d,une double validation dans le
"rocessus de commande va modifier le "rocessus sans im"act sur les $tats de l,ob;et commande.
Processus /umains et worUflow
(l faut noter )ue l,on "eut distinguer deu= ty"es de "rocessus automatis$s > 8es "rocessus avec "as
ou "eu d,intervention /umaine dans leur d$roulement. #,est d,ailleurs un des ob;ectifs de
l,automatisation des "rocessus > rationaliser et r$duire le "oids des tFc/es manuelles dans
l,e=$cution des "rocessus m$tiers.
8es "rocessus m$tiers ! forte intervention /umaine 9un grand nombre d,activit$s sont r$alis$es "ar
des acteurs /umains: rel7vent /istori)uement des outils de worUflow. #es outils "rennent en com"te
l,organisation des $)ui"es< la transmission des informations et l,affectation des tFc/es entre les
diff$rents acteurs im"li)u$s dans le "rocessus. #e"endant< il n,y a "as de fronti7re tou;ours nette
entre ces deu= domaines > dans la "rati)ue< l,intervention /umaine est souvent n$cessaire "our
traiter les situations e=ce"tionnelles.
4.4 Composant )onction
8es com"osants 5onction occu"ent une "lace c/arni7re dans cette arc/itecture. 3n a vu
"r$c$demment )u,ils se c/argent des "rocessus de traitement< mais "lus g$n$ralement ils

16
+PC > +usiness Process Canagement. 6estion de "rocessus m$tier. +P18 > +usiness Process 1=ecution
8anguage. +PCT > +usiness Process Codeling Totation 9www.b"mn.org:. +4C > +usiness 4ctivity Conitoring.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 17 sur *1
fournissent les services "roc/es de la vision utilisateur< "ar com"osition de services de ty"e 1ntit$.
3n retrouve cette notion de com"osition dans les ?1 des services de ty"e 5onction< )ui sont
souvent d$finis comme une agr$gation de ?1 de com"osants de ty"e 1ntit$ N5igure 16O.
Contrat client
Client Contrat
TDE
contrat
TDE
client
TDE
Contrat
+
Client
Lecture du dtail du contrat
et du client associ
Cration contrat
Modification contrat
Contrat client
Client Contrat
TDE
contrat
TDE
client
TDE
Contrat
+
Client
Lecture du dtail du contrat
et du client associ
Cration contrat
Modification contrat

Figure / - ,omposant Fonction et agr$gation de donn$es d0$change
ans la "rati)ue< les com"osants 5onction sont les moins ais$s ! identifier. 8es com"osants
Processus "roviennent directement des "rocessus m$tier de l,entre"rise< et les com"osants 1ntit$
des mod7les d,information 9ob;et m$tier ou base de donn$es:. 8es com"osants 5onction sont mis en
"lace graduellement "ar consolidations successives du syst7me.
4.* Composant +tilitaire et public
8es com"osants Utilitaires fournissent les services transverses< et relativement ind$"endants du
m$tier de l,entre"rise< comme les annuaires< la messagerie ou l,$diti)ue. 6$n$ralement stables< les
com"osants utilitaires sont souvent im"l$ment$s "ar des "rogiciels largement diffus$s< et sont "eu
ris)u$s.
8es com"osants Publics sont d$di$s au= $c/anges avec l,e=t$rieur de l,entre"rise 9+2+ e%+usiness:. 8e
c/oi= est de r$server ces communications ! un ty"e de com"osant "articulier< com"te tenu de ses
"articularit$s et des ris)ues s"$cifi)ues. ?y"i)uement< ces com"osants "rennent en c/arge
l,ada"tation des formats de donn$e 9diff$rence d,encodage< de structure ou de format:< la s$curit$<
et tous les a;ustements "ro"res au= dialogues avec les "artenaires.
8es com"osants Publics et Utilitaires ne sont "as associ$s ! une couc/e logi)ue "articuli7re. (ls
"euvent Htre en relation avec des com"osants de service ind$"endamment de leur ty"e.
4., Composant Prsentation
8es com"osants Pr$sentation "ilotent le dialogue entre le syst7me et les acteurs e=ternes. (ls
assurent la gestion des interfaces /omme mac/ine et la maintenance du conte=te session de
l,utilisateur. ?ec/ni)uement< ce ty"e de com"osant utilise les infrastructures $"rouv$es 9client ric/e
ou client web< tiers de distribution:.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 1- sur *1
Produit arif
Site Web
client
Catalogue
Client
Stoc! Client Commande
Processus
commande
facture
Client
Composant Prsentation
Produit arif
Site Web
client
Catalogue
Client
Stoc! Client Commande
Processus
commande
facture
Client
Composant Prsentation

Figure 1 - ,omposant Pr$sentation
8es com"osants Pr$sentation ne sont "as des com"osants de service "ro"rement dit > ils ne
fournissent "as de services< sauf ! l,utilisateur. (ls sont consommateurs de service "our tout autre
ty"e de com"osant. ans le cadre d,une arc/itecture 234< les com"osants Pr$sentation sont ! la fois
un "oint d,entr$e sur le syst7me et res"onsables de l,int$gration des contenus "our l,utilisateur. (ls
g7rent $galement le dialogue< l,$volution des donn$es et leurs modifications au cours d,une session.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 10 sur *1
* Dmarche et identi-ication
(l n,e=iste "robablement "as de d$marc/e universelle "our l,identification et la construction des
services. 8e conte=te de l,entre"rise< les m$t/odes ou les mod7les d,urbanisation utilis$s sont autant
de facteurs )ui devront Htre "ris en com"te. 3n "eut n$anmoins distinguer "lusieurs d$marc/es
ty"es >
$marc/e "ar "rocessus m$tiers
$marc/e orient$e donn$es
$marc/e orient$e a""lications
Taturellement< ces d$marc/es ty"es ne s,e=cluent "as 9et ne sont "as e=/austives:. ans la r$alit$< le
syst7me se constitue "ar une articulation de ces diff$rentes a""roc/es< "ar consolidations
successives< en "arall7le avec la vision globale de l,arc/itecture.
*.1 Dmarche orient processus
8a d$marc/e orient$ "rocessus s,a""uie sur une analyse des "rocessus m$tiers de l,entre"rise 9ou
d,un domaine "articulier:< dans l,ob;ectif de d$"loyer des com"osants de services de ty"e Processus.
8es "rinci"ales activit$s sont les suivantes >
,arto'rap%ie des processus m#tiers > inventaire des "rocessus m$tiers< avec leurs "ro"ri$t$s et leurs
liens. #ette cartogra"/ie reste au niveau macro< sans d$tailler le d$roulement de c/acun des
"rocessus.
Identification des composants Processus > $termination des "rocessus m$tiers ! automatiser. 3n
"rivil$gie les "rocessus ! forte valeur a;out$e "our l,entre"rise 9on $vite les "rocessus internes
comme la gestion du "ersonnel: et les "lus $volutifs< de faXon ! aboutir ! un r$el a""ort m$tier et un
retour sur investissement notable. 4 noter )ue certains "rocessus "euvent Htre d$;! automatis$s<
mais diss$min$s sur "lusieurs a""lications. ans ce cas< la re"rise de la logi)ue des ces "rocessus "ar
un com"osant d$di$ 9ty"e Processus: entraIne une r$novation des a""lications im"act$es )ui
facilitera la "rise en com"te des futures $volutions.
2laboration des modles de processus m#tiers. #es mod7les re"r$sentent l,enc/aInement des
"rocessus m$tiers 9activit$s< flu=< acteurs: avec un "oint de vue maItrise d,ouvrage. 8es flu= $c/ang$s
"ar les activit$s $tablissent une "remi7re structure des ty"es de donn$es d,$c/ange 9?+1: utilis$s.
#es mod7les sont r$alis$s ! l,aide de notations +PC ou de diagrammes d,activit$ 'C8 N5igure 1.O.
/odles de processus e3#cutable. 8e "assage de mod7les m$tiers au= mod7les e=$cutables
n$cessite la descri"tion d$taill$e de tous les $l$ments 9l,ensemble des c/emins< les erreurs< les
com"ensations $ventuelles:< et de "r$ciser les services consomm$s "ar de "rocessus. #e travail
"ermet g$n$ralement d,identifier de nouveau= services ou d,a;outer des o"$rations au= services
e=istants 9notamment services de ty"e 5onction ou 'tilitaire:. 8es mod7les sont de ty"e +P18<
e=$cutables ! l,aide d,un outil ou traduits dans un langage de "rogrammation. #ette re"r$sentation
sert de base "our la s"$cification des services< avec l,ensemble des o"$rations n$cessaires.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 20 sur *1
*.2 Dmarche oriente donne
#ette d$marc/e aboutit ! la mise en "lace de com"osants de ty"e 1ntit$< avec la d$finition des ty"es
de donn$e d,$c/ange 9?1: associ$s. 1lle assure un acc7s banalis$ au= informations g$r$es "ar les
bases de donn$es.
/odle des obBets m#tier. #e mod7le re"r$sente la structure et les "ro"ri$t$s des ob;ets m$tiers.
?y"i)uement< on utilise le formalisme de classes 'C8< en s,a""uyant sur les structures "ro"res des
bases de donn$es e=istantes.
TarifGeneral
Tari fUnit
Produit
Commande LigneCommande
Catal ogue
FicheTechnique
Client
Stock
Lot
Fournisseur
Transposteur
Proprit
Facture
*
*
1
*
*
*
1
*
1
1 1
1
*
1
1
1
1
1
1

Figure 4 - 9od(le des ob=ets m$tier 7notation @9L:
Identification des obBets m#tiers cl#. #omme il a d$;! $t$ $vo)u$ "r$c$demment< cette
identification s,a""uie fortement sur la connaissance fonctionnelle. #/a)ue ob;et m$tier cl$ donne
lieu ! un com"osant de service de ty"e 1ntit$< )ui fournit les services d,acc7s 9cr$ation< modification<
su""ression et re)uHte:.
*#finition des T*2. Pour c/a)ue ob;et m$tier cl$ 9et donc "our c/a)ue com"osant de ty"e 1ntit$:<
un ou "lusieurs formats d,$c/ange est d$fini. #e format est naturellement bas$ sur les mod7les des
ob;ets m$tiers< et consiste ! K d$cou"er L celui%ci sous la forme de format de ty"e document
9sc/$ma YC8:< )ui seront $c/ang$s lors de l,invocation des o"$rations du service N
17
O.
8ranc%ement des composants. Par leur nature "articuli7re< les com"osants de ty"e 1ntit$ obligent !
une modification dans les acc7s ! l,information. 1n effet< ces com"osants sont "ar d$finition
d,uni)ue canal vers les donn$es "ersistantes > les autres formes d,acc7s doivent donc Htre remani$es
9"ar e=em"le les lectures directes vers les bases de donn$es:.
*.3 Dmarche oriente application
8,ob;ectif est la restructuration de certaines a""lications "ar mutualisation de services.
,arto'rap%ie des applications. #,est un mod7le des a""lications e=istantes int$grant notamment les
$c/anges de flu= inter a""licatifs.

17
Voir notamment 1nter"rise 3riented 4rc/itecture< Bames Cc6overn< 3liver 2ims< 4s/is/ Bain< CarU 8ittle<
2"ringer< 2006< c/a"itre 2.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 21 sur *1
Identification des serices mutualis#s. 8,analyse des flu= et leurs caract$risti)ues 9volume<
fr$)uence: signale les a""lications fortement d$"endantes. e "lus< une connaissance "lus d$taill$e
des a""lications "eut faire a""araItre des redondances fonctionnelles ou des du"lications
/istori)ues. #es $l$ments se con;uguent "our isoler les services "otentiellement mutualisables< et
d,obtenir une d$cou"e "lus sim"le et "lus co/$rente.
Application 1 Application 2 Application 1 Application 2
Application 1 Application 2 Application 1 Application 2

Figure ; - restructuration par mutualisation de ser"ice
Restructuration. 8es com"osants de services doivent a""araItre comme des $l$ments stables< avec
un consensus d,inter"r$tation sans entraIner une refonte com"l7te du domaine. ans le cas
contraire< une reconstruction globale est souvent "r$f$rable< avec une mise ! "lat de l,analyse
m$tier. 8es com"osants de services r$sultants sont g$n$ralement de ty"e 5onction< "roc/es de
l,utilisation m$tier.
Memar)ue. 8a mutualisation de service n,est "as un ob;ectif en soi. (l est inutile de d$"enser du
tem"s 9et du budget b: dans la restructuration d,a""lications stables )ui fonctionnent correctement.
*.4 .estion des versions
#omme tout $l$ment logiciel< les com"osants de services sont soumis au= $volutions 9maintenance
ou modifications fonctionnelles:. 8a mutualisation de service a des im"acts "lus ou moins im"ortants
sur les consommateurs de ces services< en fonction du ty"e d,$volution N5igure 20O > l,a;out d,une
nouvelle interface ou d,une o"$ration< la modification de l,im"l$mentation 9sans modification des
interfaces de service:< la modification d,interface e=istante< la modification des ty"es de donn$e
d,$c/ange.
V1
I1 I2
V2
I1 I2 I3
V2
I1 I2
V2
I1 I2
Interfaces
Implmentations
V1
I1 I2
V2
I1 I2 I3
V2
I1 I2
V2
I1 I2
Interfaces
Implmentations

Figure #< - -ypes d0$"olution: A=out d0inter.ace, modi.ication d0impl$mentation, modi.ication d0inter.ace
1n toute rigueur< le d$"loiement d,une nouvelle version d,un com"osant de service entraIne un coDt
9et un d$lai: su""l$mentaire dD en "articulier au= tests n$cessaires des diff$rents consommateurs du
service. #ette contrainte "eut dans certains cas devenir contradictoire avec la sou"lesse rec/erc/$e<
et un d$"loiement de "lusieurs versions d,un mHme com"osant est une solution envisageable.
Par e=em"le N5igure 21O< si 2 a""lications 4 et + utilisent le mHme service< et )ue "our les besoins de
l,a""lication + le service est modifi$< la cJ=istence de deu= versions du service "ermet le
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 22 sur *1
d$"loiement ra"ide le la nouvelle version sans im"act sur l,a""lication 4. 8e bus de communication
"rend en c/arge le routage en fonction du consommateur de service.
Application A
SX v1
Application B Application A
SX v1
Application B
SX v2
Application A
SX v2
Application B
Transition
Transition
Application A
SX v1
Application B Application A
SX v1
Application B
SX v2
Application A
SX v2
Application B
Transition
Transition

Figure # - -ransition utilisant plusieurs "ersions d0un ser"ice
#e"endant< on $vitera la multi"lication de ce genre de situation< )ui devra conserver son caract7re
transitoire. 1n effet< la "rolif$ration de versions de service engendre des difficult$s de gestion )ui
annulent ! terme ses effets b$n$fi)ues. 8,utilisation de r7gles a""ro"ri$es "ermet de r$duire ce ty"e
de ris)ue< "ar e=em"le >
8e nombre de com"osants de service d$"loy$s en "lusieurs versions ne doit "as d$"asser
15c du nombre total des com"osants.
Pour un com"osant de service donn$< le nombre de versions d$"loy$es est au ma=imum de *
*.* &pci-ication tendue et tests
8a s"$cification de service a $t$ d$finie "lus /aut avec ces diff$rents $l$ments > interfaces et
o"$rations< contrats et "rotocoles< ty"es de donn$e d,$c/ange. 1n consid$rant le com"osant de
service comme un mini "rogiciel du "oint de vue des consommateurs de service< les $l$ments de test
sont "artis "renante de sa s"$cification. #ertaines m$t/odes comme 1=treme Programming
1-

assimilent d,ailleurs s"$cifications et tests e=ternes. 2ans re"rendre totalement cette a""roc/e< la
vision "ragmati)ue )ui consiste ! d$finir un $l$ment logiciel "ar sa ca"acit$ ! r$"ondre ! un
ensemble de sc$narios d$termin$s n,est "as nouvelle et est ! la base des o"$rations de recettes.
ans cette o"ti)ue< la livraison d,un com"osant de service int7gre tous les $l$ments )ui "artici"ent !
sa validation > les sc$narios d,utilisation e=ternes< les e=em"laires de donn$es d,$c/ange et donn$es
"ersistantes< les $mulateurs $ventuels 9bouc/ons: )ui "ermettent la mise en Juvre de ces tests.

1-
1=treme Programming 1="lained<]ent +ecU< 4ddison%Pesley< 1000
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 2* sur *1
Composant de service Composant de service
Donnes
dchange
Logique interne Data
Contrats
Primtre
Vue externe
Vue interne
Opration1
Opration2

Interface A
Opration1
Opration2

Interface B
Services utiliss
Services utiliss
Document de
spcification
Document de
spcification
Tests unitaires (boites blanche)
Tests de validation (boites noire)
Bouchons
Bouchons
Scnarios
Scnarios
Scnarios
Scnarios
Scnarios
Scnarios
Jeux de
donnes
Jeux de
donnes
Composant de service Composant de service
Donnes
dchange
Logique interne Data
Contrats
Primtre
Vue externe
Vue interne
Opration1
Opration2

Interface A
Opration1
Opration2

Interface A
Opration1
Opration2

Interface B
Opration1
Opration2

Interface B
Services utiliss
Services utiliss
Services utiliss
Services utiliss
Document de
spcification
Document de
spcification
Tests unitaires (boites blanche)
Tests de validation (boites noire)
Bouchons
Bouchons
Scnarios
Scnarios
Scnarios
Scnarios
Scnarios
Scnarios
Jeux de
donnes
Jeux de
donnes

Figure ## - ,omposant de ser"ice: sp$ci.ication $tendue
4u%del! du strict "oint de vue de validation< )ui facilite les travau= d,int$gration< les sc$narios de test
a;outent une dimension concr7te et e=em"laire )ui "artici"e ! la com"r$/ension du rSle du
com"osant. 3n retrouve cette a""roc/e avec les cas d,utilisation 'C8< )ui "r$cisent ! l,aide de
sc$narios ty"es< la dynami)ue d,utilisation et les r$sultats attendus.
8,ensemble de ces $l$ments dis"onibles "our le consommateur de service est a""el$ spcification
tendue< )ui "ourra inclure $galement tous les documents et $l$ments utiles ! la d$finition du
service.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 2. sur *1
, Cartoraphie et mod#les
,.1 Cartoraphie des services
8a cartogra"/ie des services est une vue synt/$ti)ue des com"osants de services et de leur
r$"artition dans les diff$rentes couc/es logi)ues 9Pr$sentation< Processus< 5onction< 1ntit$:.
Produit arif
Site Web
client
Catalogue
Client
Stoc! Client Commande
Processus
commande
Sui"i
commande
rans#orteur
Messagerie
$changes
Fournisseurs
facture
%&glement
C'
Processus
Achat #roduit
Processus MA(
arif
)estion tarif
arification
Processus
MA( Catalogue
Achat
fournisseur
Processus
)estion litiges
ableau*
de bord
diti+ue
Processus retour
commande
Commande
Client
Prsentation
Processus
Fonction
Public
Utilitaire
Entit
Produit arif
Site Web
client
Catalogue
Client
Stoc! Client Commande
Processus
commande
Sui"i
commande
rans#orteur
Messagerie
$changes
Fournisseurs
facture
%&glement
C'
Processus
Achat #roduit
Processus MA(
arif
)estion tarif
arification
Processus
MA( Catalogue
Achat
fournisseur
Processus
)estion litiges
ableau*
de bord
diti+ue
Processus retour
commande
Commande
Client
Prsentation
Processus
Fonction
Public
Utilitaire
Entit

Figure #% - ,artographie g$n$rale des composants de ser"ice
,.2 &tructure nrale du s"st#me
8e syst7me contient naturellement tous les constituants du syst7me. ans la "rati)ue< on va utiliser
diff$rentes vues 9diagrammes: en fonction du ty"e de tFc/e ou du niveau de d$tail d$sir$. 8a
descri"tion des d$"endances 9liens d,utilisation: est "articuli7rement im"ortante "our une analyse
du syst7me.
Produit arif
Site Web
client
Catalogue
Client
Stoc! Client Commande
Processus
commande
Poste
)estionnaire
rans#orteur
Messagerie
$changes
Fournisseurs
facture
%&glement
Client
Gestionnaire
commande
Produit arif
Site Web
client
Catalogue
Client
Stoc! Client Commande
Processus
commande
Poste
)estionnaire
rans#orteur
Messagerie
$changes
Fournisseurs
facture
%&glement
Client
Gestionnaire
commande

Figure #' - Repr$sentation des liens de d$pendance entre composants
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 25 sur *1

,.3 Dpendance dinter-aces
#/a)ue com"osant de service "eut "otentiellement e="oser "lusieurs interfaces 9)ui contiennent
c/acune des o"$rations de services:. 8e lien de d$"endance au niveau des interfaces "ermet une
connaissance "lus fine de la structure du syst7me et facilite les analyses d,im"act.
Catalogue
Client
Produit
Stoc!
Lecture criture
MA( arifs
Produit arif arif
Catalogue
Client
Produit
Stoc!
Lecture criture Lecture criture
MA( arifs
Produit arif arif

Figure #) - @tilisation des inter.aces entre composants
8a notation 'C82 offre une re"r$sentation directe de com"osants ! l,aide des notions de Port< Part<
#om"osant et #onnecteur.
Catalogue client
Tarif
Produit
Stock
lTarif
lProduit
lStock eTarif
eProduit
eStock

Figure #/ - ,omposants de ser"ice: repr$sentation @9L#
4u%del! d,une certaine taille< l,em"loi d,un outil de mod$lisation est un atout indis"ensable "our la
gestion du syst7me. (l facilite l,$laboration en co/$rence des diff$rents "oints de vue< l,audit
automati)ue et l,analyse d,im"act< la "roduction d,$tat 9H?C8: "our la diffusion et le "artage
d,information. 8a mise en Juvre des tec/ni)ues C4
10
< "ar la "roduction des constituants logiciels !
"artir des mod7les assure une meilleure maItrise des c/angements en r$duisant la distance entre les
as"ects logi)ues et tec/ni)ues.

10
C4 > Codel riven 4rc/itecture. www.omg.orgV
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 26 sur *1
/ &tructuration du &I et application
/.1 (pplication composite
d la vue de ce ty"e d,arc/itecture< on "eut l$gitimement se demander oe sont "ass$es nos
a""lications Z 2,agit%il d,une dis"arition de l,entit$ logicielle )ui structure la ma;orit$ des 2(
d,au;ourd,/ui Z
8es a""lications sont les $l$ments tangibles du "oint de vue des utilisateurs du syst7me. ans cette
mesure< elles ;ouent un rSle essentiel > la r$"onse au= besoins concrets< et la valeur a;out$e du
syst7me se concentre ! un moment sur le dialogue acteur%syst7me. 8a mise en Juvre de 234
n,im"li)ue "as la su""ression des a""lications > 4u contraire< centr$e sur les ob;ectifs m$tiers< 234
tend ! am$liorer la mise ! dis"osition d,a""lications tou;ours "lus "erformantes et ada"t$es ! ses
utilisateurs.
"e syndrome arc%itectural. #omme avec d,autres a""roc/es< il faut se garder de l,$cueil K substituer les
moyens au= ob;ectifs L. 8es arc/itectures comme les tec/nologies ne constituent "as des buts en soi. (l
s,agit d,instruments 9outils: mis en Juvre "our r$"ondre ! des demandes m$tier< )ui sont mis en Juvre
dans le cadre d,a""lications concr7tes.
'ne a""lication com"osite est constitu$e "ar un ensemble de com"osants )ui concourent "our
r$"ondre au= besoins d$di$s ! une ligne m$tier ou une utilisation s"$cifi)ue du syst7me.
?y"i)uement on va trouver dans une a""lication com"osite un com"osant Pr$sentation 9(HC<
session utilisateur: )ui s,a""uit sur des com"osants de services de diverses natures 9Processus<
5onction< 1ntit$ G:.
Application A Application B Application A Application B

Figure #1 - Applications composites
1n terme d,organisation< les "ro;ets a""licatifs ont en c/arge la livraison de l,a""lication au"r7s des
clients utilisateurs 9internes ou e=ternes: corres"ondant au= ca/iers des c/arges. #ette res"onsabilit$
im"li)ue la mise en Juvre de toutes les activit$s n$cessaires > analyse< conce"tion< int$gration<
validation< construction de l,(HC< d$velo""ement de com"osants s"$cifi)ues.
ans une arc/itecture 234< ces "ro;ets a""licatifs vont "otentiellement r$utiliser et "artager des
com"osants de service< )ui n,a""artiennent "as ! une a""lication "articuli7re. 8e d$velo""ement< la
maintenance et la gestion de ces com"osants mutualis$s sont "ris en c/arge "ar une organisation
transverse )ui assure la coordination fonctionnelle et tec/ni)ue.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 27 sur *1
,onflits d$int#rCt. (l e=iste un ris)ue de conflit d,int$rHt entre les res"onsables des "ro;ets a""licatifs et
les ob;ectifs 234. 8es "remiers sont $valu$s "ar leurs ca"acit$s ! fournir dans les d$lais les $l$ments
corres"ondants au= ca/iers des c/arges en res"ectant les coDts fi=$s. 8a "rise en com"te de facteurs
transverses "eut Htre "erXu comme une contrainte additionnelle. 8e rSle de la direction est fondamental
"our assurer les coordinations et les actions "ermettant une collaboration efficace avec les $)ui"es
transverses.
Memar)ue > 234 n,im"li)ue "as la refonte totale du 2(< et dans la "rati)ue< des a""lications
K anciennes modes L coe=istent avec les a""lications com"osites. Pragmati)uement certaines vont
"artiellement utiliser des services tout en conservant leurs structures initiales.
/.2 0isibilit et structuration du &I
8a notion de "$rim7tre de visibilit$ d,un service n,est "as une )uestion anne=e et im"acte
l,organisation aussi bien )ue l,arc/itecture. 1lle "r$cise les $l$ments )ui ont le droit de l,utiliser
comme consommateur du service.
1n g$n$ral la structuration des syst7mes d,information se retrouve dans l,organisation des
res"onsabilit$s des $)ui"es 9domaine< sous%syst7me etc.:. 8es com"osants de service< comme tout
$l$ment du syst7me d,information doit Htre "ositionn$ dans cette organisation g$n$rale< )ui n,est
"as modifi$e "ar cette o"$ration.
8,im"act du "$rim7tre de visibilit$ est notable > un service limit$ ! une a""lication et un service
"ubli$ K en ligne L ne sont "as de mHme nature. e mHme< un service dis"onible sur un large
"$rim7tre n$cessite des efforts su""l$mentaires sur les "lans contractuels et tec/ni)ues.
8onne prati(ue. ?ou;ours d$finir le "$rim7tre d,un service "ubli$. 8a mutualisation de service im"li)ue
un coDt su""l$mentaire )ui d$"end en "artie du "$rim7tre de visibilit$. 8a dis"onibilit$ globale non
structur$e de tous les services ris)ue de "rovo)uer des dysfonctionnements ma;eurs sur les "lans
organisationnel et tec/ni)ue.
#oncr7tement< le "$rim7tre de visibilit$ d,un service est d$fini ! "artir des unit$s d,organisation du
syst7me 9domaine< sous%syst7me etc.G: N5igure 2-O. (l "eut $galement Htre d$fini de mani7re "lus
e="licite< "ar $num$ration des consommateurs autoris$s.
Systme A
Sous-systme Sous-systme
Systme A Systme B Systme C
Systme dinformation
Services de sous-systme
Services disponibles sur le systme A
Services disponibles sur tout le SI
Systme A
Sous-systme Sous-systme
Systme A Systme B Systme C
Systme dinformation
Services de sous-systme
Services disponibles sur le systme A
Services disponibles sur tout le SI

Figure #4 - P$rim(tre de "isibilit$
8e "$rim7tre de visibilit$ d,un com"osant "eut varier au cours de sa vie. Par e=em"le< un service
e="os$ dans un "remier tem"s sur un sous%syst7me< accroIt son "$rim7tre avec le tem"s "our
couvrir tout le 2(. #ette modification de visibilit$< mHme ! fonctionnalit$ $)uivalente im"li)ue
g$n$ralement une reformulation du contrat de service.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 2- sur *1
1 2ise en 3uvre
8,arc/itecture logi)ue< mHme si elle ;oue un rSle central< doit Htre articul$e avec les autres a=es de
construction > 8e "rocessus de mise en Juvre< la gouvernance des donn$es< les structures
d,organisation< la m$t/odologie< les infrastructures tec/ni)ues et les d$velo""ements. #es "oints
d$"assent le "$rim7tre de ce document< mais leurs maItrises constituent un facteur cl$ de la
r$ussite. To'afD
20
"ro"ose un cadre de r$f$rence d,$volution des syst7mes d,information
d,entre"rise. 8a d$marc/e "ro"os$e est d$cou"$e en un ensemble de "/ases 95igure 20: et
accom"agn$e de bonnes "rati)ues< instruments et aides.

Figure #; - Phases -oga.
#e cadre doit le "lus souvent Htre ada"t$ au conte=te de l,entre"rise< il "ro"ose ce"endant une
structure et des "rati)ues de r$f$rence )ui s,a""li)uent )uel )ue soit le style d,arc/itecture 9234 ou
"as:. 8a mise en avant des ob;ectifs m$tiers< le caract7re it$ratif du "rocessus< la "artici"ation de
toutes les "arties "renantes< la )ualit$ de la gouvernance sont "armi les $l$ments notables de ?ogafQ
)ui s,im"ose comme une r$f$rence incontournable "our les arc/itectures d,entre"rise.
8a mise en Juvre de 234 "eut a""orter une v$ritable valeur a;out$e. #e"endant< comme "our tout
c/angement< le succ7s "asse "ar une maItrise des ris)ues et des ob;ectifs. 8es e="$riences "ass$es
ont montr$ )ue les $cueils e=istent > le man)ue de r$sultats clairs dans le d$"loiement des 14(<
certainement due ! une orientation tro" focalis$e sur les solutions tec/ni)ues et les offres $diteurs.
'ne vision clairement orient$e m$tier< du "ragmatisme dans les d$cisions sans oublier des
organisations motiv$es sont autant de facteurs )ui faciliteront la r$ussite de la d$marc/e.

20
www.o"engrou".orgV
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page 20 sur *1
4 .lossaire

Application composite 4""lication constitu$e "ar assemblage d,un ensemble de com"osants.
8A/ +usiness 4ctivity Conitoring. 5ournit un tableau de bord< des indicateurs de
mesure de la "erformance m$tier< des outils de monitoring< de re"orting et
"ermet le contrSle du rendu fonctionnel des "rocessus m$tier a associ$ de faXon
classi)ue ! un outil de +PC et consid$r$ ! ;uste titre comme une a""lication !
"art enti7re.
8P2" +usiness Process 1=ecution 8anguage. #onXu "ar (+C< +14 et Cicrosoft< c&est la
re"r$sentation YC8 d,un "rocessus e=$cutable< )ui "eut Htre d$"loy$e sur
n,im"orte )uel moteur de "rocessus m$tier. 8,$l$ment "remier d,un "rocessus
+P18 est une K activit$ L< )ui "eut Htre l,envoi d,un message< la r$ce"tion d,un
message< l,a""el d,une o"$ration 9envoi d,un message< attente d,une r$"onse:<
ou une transformation de donn$es.
8&activit$ est d$finit "ar la combinaison de 2ervices Peb. +P18 utilise P28 "our
d$crire les actions d&un "rocessus.
8P/ +usiness Process Canagement. ?erme g$n$ri)ue d$signant ! la fois la
mod$lisation et la traduction< ! l&aide d&un fmoteurf< des "rocessus mod$lis$s
dans la r$alit$ de l&entre"rise. 4 cela s&a;oute< bien $videmment< des outils g
indicateurs< tableau= de bordG g de suivi de l&e=$cution des "rocessus et
d&$valuation de leur "erformance 9voir +4C:.
8P/1 4cronyme "our +usiness Process Canagement Totation 9Totation "our la
6estion des Processus C$tiers:
'tilis$e "our la mod$lisation gra"/i)ue des "rocessus m$tier 9"as l,e=$cution:.
Particuli7rement "ertinente dans le cadre de la mod$lisation des "rocessus< de
leur analyse et de leur simulation. #ette notation est sous le contrSle de l, 3C6
93b;ect Canagement 6rou":.
,omposant de serice #om"osant logiciel fournisseur de service divis$ en vue e=terne et vue interne. 8a
vue e=terne est la "artie service du com"osant< )ui "eut Htre utilis$ "ar d,autres
$l$ments du syst7me< ;ouant le rSle de consommateur de service. 8a vue e=terne 9
ou s"$cification de service: est constitu$e "ar un ensemble d,o"$rations de
service regrou"$es en interface< le contrat et toutes les informations li$es ! son
utilisation 9voir Eo2 et 284:.
,omposant 2ntit# #om"osant de service )ui donne un acc7s au= informations li$es ! un ob;et
m$tier cl$. 8es o"$rations sont de ty"e #M' 9#reate< Mead< '"date< elete:.
,omposant ?onction #om"osant de service )ui "rend en c/arge un "rocesssus de traitement< ou une
ada"tation ! une vision m$tier "articuli7re< sous forme de com"osition de
services.
,omposant Pr#sentation #om"osant de service d$di$ ! l,interaction entre acteurs /umains et le syst7me. (l
"rend en c/arge les (HC et la gestion de la session utilisateur.
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page *0 sur *1
,omposant Processus #om"osant de service )ui automatise un "rocessus m$tier.
,omposant Public #om"osant de service )ui assure les $c/anges avec les syst7mes e=ternes 9+2+< e%
business:
,omposant utilitaire #om"osant de service d$di$ ! des fonctions transverses 9annuaire< messagerie<
$diti)ue: non s"$cifi)ues au m$tier de l,entre"rise.
/*A
EEE.om'.or'

8e C4 est une d$marc/e de r$alisation de logiciel< "ro"os$e et soutenue "ar
l&3C6. 8&id$e fondamentale est )ue les fonctionnalit$s du syst7me ! d$velo""er
sont d$finies dans un mod7le ind$"endant de la "late%forme 9Platform
(nde"endent Codel< P(C:< en utilisant un langage de s"$cifications a""ro"ri$<
"uis traduites dans un ou "lusieurs mod7les s"$cifi)ues ! la "late%forme 9Platform
2"ecific Codel< P2C: "our l&im"l$mentation concr7te du syst7me.
4ASIS
EEE.oasisFopen.or'
3rgani_ation for t/e 4dvancement of 2tructured (nformation 2tandards.
#onsortium international )ui travaille "our la normalisation et la standardisation
de formats de fic/iers ouverts bas$s notamment sur YC8.
4/G
EEE.om'.or'

8,3C6 93b;ect Canagement 6rou": est une association am$ricaine ! but non%
lucratif cr$$e en 10-0 dont l&ob;ectif est de standardiser et "romouvoir le mod7le
ob;et sous toutes ses formes. 8,3C6 est "ar e=em"le ! l,initiative des normes
'C8 et #3M+4 ou encore C4 et +PCT.
4pen S4A
EEE.osoa.or'
3rganisme international )ui "ro"ose des normes 234 > 2#4 92ervice #om"onent
4rc/itecture: et 23 92ervice ata 3b;ects:.
Partenaires > +14< (+C< (3T4< 3racle< 24P< 2'T< 2iemens< ?ib#o.
Processus de traitement Processus )ui re"r$sente le d$roulement d,une activit$ localis$e< de courte dur$e
et non interru"tible.
Processus m#tier Processus de bout en bout de l,entre"rise< )ui d$livre une valeur a;out$e tangible
! l,e=t$rieur "ar une collaboration de "lusieurs unit$s et acteurs. 'n "rocessus
m$tier "eut avoir une longue dur$e de vie et est "otentiellement interrom"u.
Processus m#tier
transerse
Voir Processus m$tier
GoS Euality of service. 8a )ualit$ de service est une notion n$e c/e_ les o"$rateurs de
t$l$communications vers 1007. 3n "arle de contrat de niveau de service )uand
une entre"rise e=ige de son o"$rateur une /aute dis"onibilit$ de son r$seau. 8a
gestion du niveau de service s&est< de"uis< $tendue au syst7me d&information.
S,A

2ervice #om"onent 4rc/itecture 9voir o"en 234:
2ervice #om"onent 4rc/itecture aims to "rovide a model for t/e creation of
service com"onents in a wide range of languages and a model for assembling
service com"onents into a business solution % activities w/ic/ are at t/e /eart of
building a""lications using a service%oriented arc/itecture.
Silo ?erme utilis$ "our d$signer une d$cou"e verticale d,un syst7me< "ar a""lications
9silos a""licatifs:.
K Application architectures are typically created as independent or! efforts that
Gilbert Raymond SOA : Architecture Logique - Principes, structures et bonnes pratiques

ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas
d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.
Page *1 sur *1
are usually oned by a specific organi"ational domain or entity# Applications are
usually built to automate business applications ithin a single organi"ation
domain# $hose single%domain applications are said to be &siloed#& L 4voiding
common "itfalls in 234 ado"tion< ?ilaU Citra< 1=ecutive (? 4rc/itect< (+C< ;uin
2006.
S"A 2ervice 8evel 4greement. #ontrat d$finissant les engagements du fournisseur de
service )uant ! la )ualit$ de sa "restation< et les "$nalit$s engag$es en cas de
man)uement. #ette )ualit$ doit Htre mesur$e selon des crit7res ob;ectifs
acce"t$s "ar les deu= "arties. 1= > tem"s de r$tablissement du service en cas
d&incident
T*2 ?y"e de onn$e d,1c/ange. 2tructure des informations $c/ang$es "ar les
messages ou les flu= inter com"osants. ?y"e des "aram7tres des o"$rations de
service. Par o""osition< les donnes persistantes sont les informations contenues
dans les bases de donn$es.
To'af
EEE.open'roup.or'

T%e 4pen Group Arc%itecture ?rameEor>< $galement connu sous l&acronyme
To'af< est un ensemble de conce"ts et un standard industriel couvrant le
domaine des arc/itectures informati)ues d&entre"rise< )ui "eut Htre utilis$
librement et sans coDts "ar toute entre"rise sou/aitant d$velo""er ou modifier
son arc/itecture.
?ogaf a $t$ d$velo""$ et est continuellement am$lior$ de"uis le milieu des
ann$es 1000 "ar diff$rentes "ersonnes a""artenant ! un certain nombre de
d$"artements informati)ues d&im"ortantes soci$t$s< ainsi )ue "ar des
fournisseurs de conseils ou de solutions informati)ues. #e travail $tant effectu$
"ar l&interm$diaire du forum des arc/itectures de l&3"en 6rou".
93,
%ttp:HHEEE.E3.or'
8e Porld Pide Peb #onsortium< abr$g$ P*#< est un consortium fond$ en
octobre 100. "our "romouvoir la com"atibilit$ des tec/nologies du Porld Pide
Peb telles )ue H?C8< YH?C8< YC8<< #22< PT6< et 234P
9eb serice (l s&agit d&une tec/nologie "ermettant ! des a""lications de dialoguer ! distance
via (nternet< et ceci ind$"endamment des "lates%formes et des langages sur
les)uelles elles re"osent. Pour ce faire< les services Peb s&a""uient sur un
ensemble de "rotocoles (nternet tr7s r$"andus 9YC8< H??P:< afin de
communi)uer. #ette communication est bas$e sur le "rinci"e de demandes et
r$"onses< effectu$es avec des messages YC8.
8es services web sont d$crits "ar des documents P28 9Peb 2ervice escri"tion
8anguage:< )ui "r$cisent les o"$rations "ouvant Htre invo)u$es< leurs signatures
et les "oints d&acc7s du service 9'M8< "ort .:. 8es services Peb sont accessibles via
234P< la re)uHte et les r$"onses sont des messages YC8 trans"ort$s sur H??P.