Livre blanc

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

Table des matires

1 2 3 *.1 *.2 *.* *.. ! ..1 ..2 ..* ... ..5 ..6 ) 5.1 5.2 5.* 5.. 5.5 & 6.1 6.2 6.* 7.1 7.2 . + Introduction ................................................................................................................ 3 Principes et moti ations............................................................................................... ! "es #l#ments de base de l$arc%itecture ......................................................................... & #om"osant de service ...................................................................................................... 6 +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 #om"osant 1ntit$........................................................................................................... 1* 234 et Processus............................................................................................................ 1. #om"osant Processus .................................................................................................... 15 #om"osant 5onction ...................................................................................................... 16 #om"osant 'tilitaire et "ublic ....................................................................................... 17 #om"osant Pr$sentation................................................................................................ 17 *#marc%e et identification......................................................................................... 1+ $marc/e orient$ "rocessus ......................................................................................... 10 $marc/e orient$e donn$e ........................................................................................... 20 $marc/e orient$e a""lication...................................................................................... 20 6estion des versions ...................................................................................................... 21 2"$cification $tendue et tests........................................................................................ 22 ,arto'rap%ie et modles............................................................................................ 2! #artogra"/ie des services .............................................................................................. 2. 2tructure g$n$rale du syst7me ...................................................................................... 2. $"endance d,interfaces ............................................................................................... 25 Structuration du SI et application ............................................................................... 2& 4""lication com"osite.................................................................................................... 26 Visibilit$ et structuration du 2(....................................................................................... 27 /ise en 0u re........................................................................................................... 2. Glossaire ................................................................................................................... 2+

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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(.
Approches Approches Orientes Orientes Objets Objets

Approche Approche par par Composant Composant (Herzum (Herzum & & Sims) Sims)

Distribution Distribution (Corba, (Corba, DCOM) DCOM)

changes changes orient orient document document (XML) (XML)

EAI EAI

BPM BPM

Urbanisation, Urbanisation, cartographie cartographie

SOA

Web Web services 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:.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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> *i iser 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.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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"osant12. 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 P2 8* ou $)uivalent.
Composant de service Composant de service
Primtre
Interface A Interface B Opration1 Opration2

Domaine dappartenance, visibilit

Vue externe

Opration1 Opration2

Donnes dchange Contrats

TDE: Types de donnes dchange

Contrat dutilisation des services

Logique interne

Data

Vue interne
Services Services utiliss 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 Vue interne Liens de dpendance

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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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 ser ices. 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.
MainFrame

Application 1

Application 2

Bus de communication (ESB)

SGBD

ERP

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.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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< 2845:. 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 is"onibilit$ 23emples ?au= d,indis"onibilit$ "ar an< Plages /oraires #ontraintes de maintenance ?em"s de r$"onse moyen< minimum Tombre de transactions "ar seconde ?au= d,erreur Politi)ue de droits d,acc7s< Ton r$"udiation Bournalisation< ?ableau= de bord< statisti)ues

Performance

5iabilit$ 2$curit$ 4dministration

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.
Composant Facture
Interface dcriture mettre Cre crer(typeFacture): typeFacture modifier(typeFacture): typeFacture emettre(typeFacture): typeFacture regler(typeFacture): typeFacture annuler(typeFacture): typeFacture

annuler annuler

mise

rgler Annule Rgle

typeFacture Numero Etat NumeroClient Date

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

. 5

Voir notamment> Meference Codel for 2ervice 3riented 4rc/itecture. 342(2. www.oasis%o"en.org Eo2> Euality of 2ervice. 284> 2ervice 8evel 4greement. 6 Me"rise des m$t/odes de programmation par contrat. fr.wiUi"edia.orgVwiUiVProgrammationW"arWcontrat
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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

3.4 Donnes dchan es 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 dchange Zone de stockage

Donnes dchange, flux

Services Applications

Donnes persistantes

Messages
Services

Applications

Bases

Services

Services

Services

Interfaces, schmas XML Formats dchange Service bus

MCD, MPD, schmas

Metadata

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 ser ice cr$er#ommande valider#ommande 2ntr#e5s6 ? 1W#ommande ? 1W#ommande ? 1W1tatValidation Sortie5s6

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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

4 !"polo ie et mod#le en couches lo i$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 Processus Process centric

Presentation 8ayer +usiness Process

Presentation

Presentation

Pr$sentation

+usiness "rocess c/oreogra"/y

Process services Process

Processus

(ntermediary +usiness 2ervice 1ntit$ 'tilitaire Public +asic ata 2ervice

#om"osite service 4""lication services 2ervice ata services

5unctionality

5onction

ata

1ntit$ 'tilitaire 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.

+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
-

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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:.
Prsentation Publics Utilitaire

Stabilit

Processus

Fonction

Entits

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' donn$es et r$f$rentiels.
1*

:< au= bases de

#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:
Prsentation Achat Produit (Web)
Prsentation

Processus
processus

Processus Commande
Fonctions

Fonction
Entit

Commande Client Entit

Catalogue

Commande

Client

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

1*

#M' > #reate< Mead< '"date< elete

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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.
Interface de lecture Lire(noClient): TDE_Client Rechercher(criteres): listeDeClients Interface dcriture Crer(TDE_Client): TDE_Client Modifier(TDE_Client): TDE_Client

Client

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 Contenu dtaill dtaill
1

*
adresse

TDE_Client1
1 1 1

*
Entreprise Secteur

Profil

Coordonnes bancaires

*
Poste

*
Achats

* *
Mtier

Contenu Contenu synthtique synthtique

adresse TDE_Client2
1

Coordonnes bancaires

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<

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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.
Commande Client Application Commande 1 Enregistrement commande Application Facturation Enregistrement facture Application Client Mise jour du profil Envoi facture

Commande Client 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

Processus Commande client Messagerie

commande

facture

Client

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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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 Processus RAle Processus m$tier transverse. 3rc/estration de service Type de participant 5ournisseur et consommateur de service 5ournisseur et consommateur de service 5ournisseur de service Granularit#
1!

6ranularit$ $lev$e. ?ransverse "ar nature.

5onction

Processus de traitement< com"osition de services< ada"tation 4cc7s ! un ob;et m$tier cl$

6ranularit$ moyenne

1ntit$

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"ensations15< le

8a granularit$ est un indicateur informel li$ au "$rim7tre fonctionnel couvert "ar le com"osant. 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.
15

1.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

nombre et la diversit$ des services utilis$s. 3n est dans le domaine du +PC16< 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.
Interface Processus Commande
DemarrerProcess(TDE_Commande, Client): TDE_DossierCommande DepassementDelai (NoDossier) RepriseProcess(NoDossier, Partenaire) ConfirmerPrestation(NoDossier) AnnulationCommande(NoDossier)

Commande
TDE Dossier commande NoDossier: interger Etat : TypeEtat Dlai: Dure

Client

Processus Commande

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

+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.
ocument mis ! dis"osition selon les termes de la licence #reative #ommons Paternit$ % Pas d&'tilisation #ommerciale % Partage ! l&(denti)ue *.0 non transcrit.

16

Page 16 sur *1

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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.
Lecture du dtail du contrat et du client associ Cration contrat Modification contrat

TDE Contrat + Client

Contrat client

TDE client

Client

Contrat

TDE 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:.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

Client Composant Prsentation Site Web client

Processus commande

Catalogue Client

Produit

arif

Stoc!

Commande

facture

Client

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.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

*.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.
S tock

TarifGeneral

Catalogue

* Lot

* Tari fUnit * 1

* Produit

1 FicheTechnique 1 * Proprit

1 1 1 Fournisseur

1 * Transposteur 1 Commande 1 1 1 Client 1 Facture * LigneCommande

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

Identification des ser ices 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 1 Application 2 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.
I1 I2 Interfaces I1 I2 I3 I1 I2 I1 I2

V1

V2

V2

V2

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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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

Application B

Application A

Application B

Application A

Application B

SX v1

SX v1

SX v2

SX v2

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 Programming1assimilent 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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

Tests de validation (boites noire)

Scnarios Scnarios Scnarios Scnarios Scnarios Scnarios Primtre
Interface A Interface B Opration1 Opration2

Composant de service Composant de service

Vue externe
Donnes dchange Contrats

Opration1 Opration2

Document Document de de spcification spcification

Logique interne

Data

Jeux Jeux de de donnes donnes

Vue interne
Services Services utiliss utiliss

Bouchons Bouchons

Tests unitaires (boites blanche)

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.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

, Carto raphie et mod#les

,.1 Carto raphie 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$:.
Site Web client
Prsentation

Sui"i commande

)estion tarif

Achat fournisseur

$changes Fournisseurs %&glement C'

Processus commande Processus MA( Catalogue

Processus

Processus retour commande Processus )estion litiges

Processus MA( arif Processus Achat #roduit

Messagerie

diti+ue Catalogue Client

Fonction

Commande Client

ableau* de bord

arification

Public Utilitaire

Produit
Entit

arif

Stoc!

Client

Commande

facture

rans#orteur

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.
Client Site Web client $changes Fournisseurs Processus commande Gestionnaire commande Poste )estionnaire

%&glement

Messagerie Catalogue Client

Produit

arif

Stoc!

Client

Commande

facture

rans#orteur

Figure #' - Repr$sentation des liens de d$pendance entre composants

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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

Lecture criture

MA( arifs

Produit

arif

Stoc!

Produit

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

lProduit

e Produit lT arif

e Tarif

lStock

e Stock

Produit

Tarif

Stock

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 C 410< "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

C 4 > Codel riven 4rc/itecture. www.omg.orgV

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

/ &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

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.

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

,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

Services de sous-systme

Services disponibles sur le systme A

Systme dinformation

Systme A Services disponibles sur tout le SI

Systme B

Systme C

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

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'afD20 "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
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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

4 .lossaire
Application composite 8A/ 4""lication constitu$e "ar assemblage d,un ensemble de com"osants. +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. +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 P2 8 "our d$crire les actions d&un "rocessus. +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:. 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 ser ice #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:. #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:. #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. #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.

8P2"

8P/

8P/1

,omposant 2ntit#

,omposant ?onction

,omposant Pr#sentation

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

,omposant Processus ,omposant Public

#om"osant de service )ui automatise un "rocessus m$tier. #om"osant de service )ui assure les $c/anges avec les syst7mes e=ternes 9+2+< e% business: #om"osant de service d$di$ ! des fonctions transverses 9annuaire< messagerie< $diti)ue: non s"$cifi)ues au m$tier de l,entre"rise. 8e C 4 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. 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. 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 C 4 et +PCT. 3rganisme international )ui "ro"ose des normes 234 > 2#4 92ervice #om"onent 4rc/itecture: et 2 3 92ervice ata 3b;ects:. Partenaires > +14< (+C< (3T4< 3racle< 24P< 2'T< 2iemens< ?ib#o.

,omposant utilitaire

/*A EEE.om'.or'

4ASIS EEE.oasisFopen.or'

4/G EEE.om'.or'

4pen S4A EEE.osoa.or'

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 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. Voir Processus m$tier

Processus m#tier

Processus m#tier trans erse 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. 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.

S,A

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

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

Gilbert Raymond

SOA : Architecture Logique - Principes, structures et bonnes pratiques

are usually o ned 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 ?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. 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' 9eb ser ice 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 (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 P2 8 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.

T*2

To'af EEE.open'roup.or'

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