Vous êtes sur la page 1sur 80

Architecture Orientée Services (SOA)

Une politique de l’interopérabilité

Livre Blanc

Ma r s 2 0 0 5
Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

1
Table des matières
Avant-propos........................................................................................................................................................7

1. Introduction ..........................................................................................................................................................8

1.1 SOA, l’architecture ultime des entreprises agiles ?.......................................................................................8

1.2 Qu’est ce qu’un service ? ............................................................................................................................10

1.2.1 Un service rend … un service ........................................................................................................10

1.2.2 Plusieurs types de consommateurs de services ............................................................................11

1.2.3 Typologie de services.....................................................................................................................12

1.3 Le double enjeu SOA : réutilisation et interopérabilité ................................................................................14

1.4 Les gains d’une architecture SOA ...............................................................................................................16

2. Quelles méthodologies pour la SOA ? ............................................................................................................18

2.1 Démarche SOA au niveau d’une application : ne changez rien !................................................................19

2.2 Démarche SOA au niveau d’un SI : top-down, bottom-up ? .......................................................................19

2.3 Notre démarche SOA au niveau du SI ........................................................................................................21

2.4 Patterns organisationnels ............................................................................................................................26

2.4.1 Pattern Communauté .....................................................................................................................26

2.4.2 Pattern Cellule Transverse .............................................................................................................27

2.5 Les patterns d’architecture SOA..................................................................................................................28

2.5.1 Patterns d’architecture fonctionnelle ..............................................................................................29

2.5.2 Patterns d’architecture technique...................................................................................................29

3. Patterns d’architecture fonctionnelle ..............................................................................................................30

3.1 Royaume / Emissaire...................................................................................................................................30

3.2 Modélisation document................................................................................................................................32

3.3 Processus implicite / explicite......................................................................................................................36

3.4 Agrégation d’IHM .........................................................................................................................................40

4. Patterns d’architecture technique....................................................................................................................42

4.1 Exposer des services...................................................................................................................................43

4.1.1 Le « proxy »....................................................................................................................................43

4.1.2 La façade .......................................................................................................................................47

4.1.3 Le service de localisation ...............................................................................................................57

4.2 Echanger......................................................................................................................................................60

4.2.1 Le point à point...............................................................................................................................60

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

2
4.2.2 Le publish and subscribe ...............................................................................................................61

4.3 Tester ...........................................................................................................................................................62

4.3.1 Fédération des plateformes d’homologation..................................................................................62

4.4 Sécuriser......................................................................................................................................................64

4.4.1 Zone implicite de confiance ...........................................................................................................65

4.4.2 Zone explicite de confiance ...........................................................................................................66

4.4.3 Fédération de l’identité...................................................................................................................66

5. SOA et les Web Services ..................................................................................................................................70

5.1 Qu’est ce qu’un Web Service ? ...................................................................................................................70

5.2 SOA n’est pas WSOA ! ................................................................................................................................70

5.3 De la maturité des standards Web Service .................................................................................................71

5.4 Le corpus de standards Web services ........................................................................................................72

5.5 WS-I, l’organisme de standardisation des standards ..................................................................................73

6. Conclusion .........................................................................................................................................................75

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

3
Table des figures
Figure 1 - Service et contrat de service .......................................................................................................................10

Figure 2 - Plusieurs types de consommateurs de services..........................................................................................11

Figure 3 - Le phénomène de banalisation des services métier ...................................................................................12

Figure 4 - Matrice de caractérisation des services ......................................................................................................13

Figure 5 - Interopérabilité et réutilisation de services ..................................................................................................15

Figure 6 - Gains d'une architecture orientée services .................................................................................................17

Figure 7 - Différence d'homogénéité entre SI et applications ......................................................................................18

Figure 8 - Matrice d'architecture OCTO Technology ....................................................................................................21

Figure 9 - Démarche d’architecture au niveau SI ........................................................................................................23

Figure 10 - Fiche de service.........................................................................................................................................24

Figure 11 - Pattern Communauté .................................................................................................................................26

Figure 12 - Pattern Cellule Transverse ........................................................................................................................27

Figure 13 - Les patterns SOA ......................................................................................................................................28

Figure 14 - Patterns d’architecture fonctionnelle..........................................................................................................30

Figure 15 - Pattern Royaume Emissaire ......................................................................................................................31

Figure 16 - Echanges entre modèles privatifs de données .........................................................................................32

Figure 17 - Modèle de données du système de facturation.........................................................................................33

Figure 18 - Modèle de données du système comptable..............................................................................................33

Figure 19 - Modèle hiérarchique des données échangées..........................................................................................34

Figure 20 - Intégration de services orientés données ou présentation........................................................................41

Figure 21 - Patterns d’architecture technique ..............................................................................................................42

Figure 22 - Le proxy .....................................................................................................................................................43

Figure 23 - Etapes de création d'un proxy technique sur une transaction CICS (Microsoft HIS)................................45

Figure 24 - Exemple de service participant à un processus (Microsoft BizTalk) .........................................................46

Figure 25 - La façade ...................................................................................................................................................47

Figure 26 - Exemple d'ordonnancement des services de médiation avec un outil spécialisé (webMethods) .............48

Figure 27 - Exemple de méthodes de validation technique (SeeBeyond ICAN 5) ......................................................49

Figure 28 - Exemple de transformation via un outil de mapping (SeeBeyond ICAN 5) ..............................................50

Figure 29 - Exemple de routage de message (SeeBeyond ICAN 5)...........................................................................51

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

4
Figure 30 - Abstraction de la logique de routage (SeeBeyond ICAN 5) ......................................................................51

Figure 31 - Orchestration - Besoin d'ordonnancement ................................................................................................52

Figure 32 - Orchestration - Besoin de gestion de processus.......................................................................................52

Figure 33 - Fonctionnalité de Drill Down (BEA Weblogic Integration) .........................................................................53

Figure 34 - Gestion de la persistance d'un processus (BEA Weblogic Integration) ....................................................53

Figure 35 - Hiérarchie de services en back-office........................................................................................................55

Figure 36 - Exemple d'implémentation d'une façade avec TIBCO ..............................................................................56

Figure 37 - Pattern service de localisation...................................................................................................................57

Figure 38 - Pattern point à point ..................................................................................................................................60

Figure 39 - Pattern Publish / Subscribe .......................................................................................................................61

Figure 40 - Exemple de fédération de plateformes d'homologation ............................................................................63

Figure 41 - Zone implicite de confiance .......................................................................................................................65

Figure 42 - Zone explicite de confiance (exemple du serveur centralisé) ...................................................................66

Figure 43 - SSO par identité fédérée ...........................................................................................................................68

Figure 44 - Les principaux protocoles des Web Services............................................................................................73

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

5
Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

6
Avant-propos
Où est passée la grande échelle ?
Le petit monde de l’informatique évolue souvent comme son sous-jacent, binairement.

L’histoire a vu la vague des L4G dans les années 90 et ses promesses de grand soir : fini les
informaticiens, place aux utilisateurs, au développement rapide, le quidam peut désormais
produire du système d’information à sa guise et en toute sécurité, …

Un peu plus loin UML et son bras armé Corba, la norme permettant de distribuer des objets,
nous promettent des Systèmes d’Information plus simples, constitués d’objets métier
interopérables. Le SI ? Une vaste grappe d’objets en mouvement …

Enfin, la montée en puissance des EAI s’est effectuée sur le même credo, avec l’argument de
vente massue : la lutte « anti-spaghettis ». Marre des fils qui irriguent tout et n’importe quoi ?
Achetez un EAI pour urbaniser votre SI …

Qu’ont en commun ces différents faits ?


Ils partent tous d’une mini-innovation : ce que nous nommons un Domain Specific Language
(DSL), c'est-à-dire un langage avec une métaphore adaptée à une problématique précise,
respectivement le développement d’interface graphique, la modélisation de problèmes en objets,
et le développement de programmes dédiés aux échanges.

Il existe des DSL d’hier - lex/yacc pour créer des compilateurs par exemple - et des DSL de
demain - par exemple pour les tests. Le problème avec les DSL, c’est surtout le bruit des
trompettes qui les accompagnent, car au-delà du taratata-votre-vie-ne-sera-plus-jamais-comme-
avant, leur usage comme simple outil de productivité est généralement pertinent.

Or dans ce paysage, « SOA », littéralement « Architecture Orientée Services », c’est un peu la


fanfare au grand complet ... et pour cause, dans un système d’information, lui-même somme
d’applications, quel bout de code, petit ou gros, n’est pas un service ou n’est pas architecturé,
c'est-à-dire conforme à une structure ? Que l’on regarde à un niveau micro (la fonction), ou au
niveau macro (les services rendus entre applications), tout le monde a quelque chose à dire
sur SOA ! Mais cette cacophonie a au moins le mérite de nous créer un sujet, car sujet il y a
autour de la problématique d’interopérabilité des SI : comment mieux mettre en résonance les
blocs du SI ? Comment non pas supprimer le « plat de spaghettis », mais en faire de meilleurs ?

Et là comme de coutume, plutôt que vous enivrer au doux parfum de l’innovation au service de
la paresse ou de vous sussurrer des promesses de grand soir, nous vous ouvrirons la caisse à
outils de l’architecte, nos meilleures pratiques, celles du monde vrai, bien rangées dans la boîte
à patterns OCTO.

Pierre Pezziardi
Directeur Technique OCTO Technology

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

7
1. Introduction
« SOA c’est comme le cassoulet, chacun possède la vraie recette »
Tout le monde a connu un toulousain qui disait connaître la véritable recette du cassoulet puis vous faites
quelques kilomètres et les habitants de Castelnaudary vous démontreront par « A + B » que la leur est
la seule véritable qui vaille le coup. Au final, qu’en est-il ? Qui a raison ? Pourraient-ils tous les deux
avoir raison ?
Le principal ne serait-il pas que le plat soit réussi et qu’il apporte entière satisfaction à chacun, qu’elle
qu’en soit sa recette ?
Pour faire le parallèle avec ce préambule culinaire, notre discours ne vise pas à donner une définition
rigide de la SOA, ni à fonder une théorie dogmatique du service. En l’absence de véritable spécification
sur la notion d’architecture orientée services, celle-ci peut être vue sous différents angles qui ne sont
aucunement antinomiques.
D’un point de vue technique, il est par exemple aisé aujourd’hui de s’engouffrer dans l’antre des Web
Services mais ce ne sera pas notre propos dans ce Livre Blanc, il ne s’agirait que d’une redite
nécessairement moins complète que d’autres ouvrages de référence.
Nous nous attacherons en revanche au « A » de SOA, à savoir « Architecture » et son outillage : les
patterns1, le couteau suisse de l’architecte.

1.1 SOA, l’architecture ultime des entreprises agiles ?

« Les systèmes d’information ne sont pas stables, au contraire, ils évoluent constamment »,
derrière cette évidence se dissimule une des principales motivations de la SOA.
En effet, les raisons de l’évolution constante des systèmes d’informations sont multiples :

• Evolutions des organisations :


les causes d’évolution organisationnelle sont variées ; il peut s’agir d’évolutions internes,
par exemple par la création de filiales ou de nouvelles implantations géographiques, la
restructuration des organisations en place (centralisation des achats, des ressources
humaines, …), comme d’évolutions externes, par exemple dans le cas de fusion ou
d’acquisition de sociétés.

• Évolutions réglementaires :
les évolutions des réglementations peuvent impacter le système d’information de manière
exogène : passage à l’Euro, évolution du calcul de couverture de risque imposée par le
comité Bale II, ouverture à la concurrence des marchés publics (télécommunications,
énergie, transport, …), programme de décentralisation des services de l’Etat. Autant
d’obligations réglementaires qui obligent à repenser - plus ou moins douloureusement - les
systèmes d’information.

• Evolutions métier :
les évolutions métier couvrent principalement la réaction face à la concurrence et à
l’évolution de l’activité : mise en œuvre d’une gestion de la relation clients ou fournisseurs,
distribution de services produits par des partenaires (services bancaires, services
multimédia, …) ou de « bouquets de services » personnalisés, ouverture à de nouveaux

1 : Qu’est-ce qu’un pattern ? C’est un ensemble de concepts structurés, ayant trait à un domaine (technique, organisationnel), et reproduit
de manière constante dans le temps.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

8
canaux de distribution. Ces évolutions du métier impactent les processus et donc le
système d’information, ceci d’autant plus si elles s’accompagnent de la mise en œuvre
d’un progiciel (Siebel, SAP, PeopleSoft, …).

• Evolutions technologiques :
la technologie constitue la matière première des systèmes d’information. Que ce soit
l’évolution des produits éditeurs, des modèles d’architecture (mainframe, client-serveur, n-
tiers, …), des paradigmes de programmation et leurs langages associés (Cobol, C, Java,
.NET, …), les impacts sur le système d’information sont nombreux et se traduisent par des
efforts d’intégration entre socles technologiques hétérogènes.

• Maîtrise des coûts :


quelle entreprise n’a pas comme objectif de réduire, ou du moins de maîtriser, ses coûts ? Cette
requête est souvent faite aux directions des systèmes d’information qui y répondent
généralement par des projets de rationalisation de l’infrastructure (poste de travail unifié,
socle éditique commun, …).

Quand un système, informatique ou non, est amené à évoluer de manière certaine, l’exigence
naturelle qui lui est demandée est d’être conçu pour faciliter (ou au moins prévoir) les évolutions.
L’agilité du système est une exigence majeure. Il s’agit du leitmotiv de la majorité des
architectes qui dépasse aujourd’hui largement le cadre stricto sensu de l’architecture technique.
Quel décideur ne désire pas, aujourd’hui, disposer d’un « SI Agile » permettant d’adapter ses
processus métier dans les meilleurs délais ?

La réponse à la question posée semble évidente, une visite du dernier forum à la mode ou bien
une lecture de la presse informatique le confirme : « Avec SOA, rendez votre SI plus agile ».
Fini donc les projets tunnel, les phases d’intégration douloureuses, avec la SOA tout devient plus
fluide, de l’expression de besoin au déploiement en production. Etudes et Métier sympathisent
autour d’un écran commun, celui du BPM2.

Hélas, adresser la problématique de l’évolutivité du système d’information sous l’angle de


l’architecture est nécessaire mais non suffisant. Certes, une architecture modulaire vaut mieux
qu’une architecture composée de blocs monolithiques ; certes, la standardisation autour des
Web Services participe à l’interopérabilité. Cependant, l’agilité d’une entreprise dépend tout
autant de l’agilité de son système informatique que de l’agilité des organisations qui la
composent, et qui in fine, constituent son « système d’information ». Comment envisager de se
rendre des « services » entre applications si les organisations sous-jacentes sont cloisonnées ? Avant
de vouloir disposer d’un référentiel de services, quelle DSI dispose d’une bibliothèque de
composants métier partagés en dehors d’un plateau projet ? Est-il réaliste d’envisager la mise
en œuvre de processus métier transverses entre organisations « souveraines » ? Autant de
questions qui nous rappellent que l’architecture du système d’information procède de
l’organisation de l’entreprise, et non l’inverse.

Tout en gardant cela à l’esprit, nous nous attacherons à montrer que la valeur d’une architecture
SOA se situe bien évidemment au niveau de la réutilisation de services mais aussi et surtout
au niveau de l’interopérabilité, aspect souvent oublié par les « promoteurs » du marché. Nous
étayerons ensuite notre discours par des meilleures pratiques d’architecture apportant des
solutions à cette problématique de l’interopérabilité, afin d’aborder les aspects organisationnels
et méthodologiques liés à une démarche SOA.

2 : BPM : Business Process Management. Gestion de processus métier.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

9
1
1.2 Qu’est ce qu’un service ?
BPM : Business Process Management. Gestion de processus métier.

1.2.1 Un service rend... un service

Derrière cette tautologie, se cache la notion de contrat de service. Un service se doit d’assurer
stabilité et assurance dans l’action qui lui est demandée et qu’il effectue. Il assure par ce biais
un contrat d’interface et une qualité de service, ces deux aspects forment le contrat de service.
L’avis de réception de La Poste intègre dans son contrat de service l’authentification des
intervenants, la garantie de livraison et le retour d’information dans un temps limite. Un service
de calcul de taux doit assurer une disponibilité minimale et une fraîcheur d’information définie par
avance. Enfin, un service d’authentification unifiée se doit d’assurer une disponibilité à toutes
épreuves et donc un niveau de qualité élevé.
Le contrat de service porte tout d’abord sur le traitement demandé et son intégrité. Quand nous
évoquons le traitement associé à un service, il peut s’agir de plusieurs opérations. Par exemple,
un service de gestion de client pourra être constitué des opérations creerClient,
modifierClient, rechercherClient et supprimerClient. Le contrat de service
comprend donc avant tout un contrat d’interface, qui doit être stable dans le temps.
Il porte ensuite sur un ensemble d’éléments qui ne sont pas sans nous rappeler le savoir-faire
de nos responsables de production :

• La qualité de service : la disponibilité (taux de disponibilité, temps maximum


d’indisponibilité, service de « secours »), la réactivité (temps de réponse), le support d’un
mode dégradé (traitement en différé des requêtes reçues pendant la période d’indisponibilité
du service).

• Les caractéristiques générales d’utilisation : la volumétrie supportée, la sécurisation


du service (niveau d’authentification et d’habilitation demandés), les conditions de
facturation, le mode opératoire pour le changement de version du service, le support aux «
clients », …

N’oublions pas que nos responsables de production pensent déjà « service », et ont ainsi
beaucoup à apprendre aux experts SOA !

Figure 1 - Service et contrat de service

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

10
1.2.2 Plusieurs types de consommateurs de services
Un service a pour vocation initiale l’exposition de traitements. Dans ce sens, il apporte une
décorrélation entre fournisseur de service et consommateur de service. Cela a pour objectif
d’apporter un niveau d’abstraction supplémentaire aux traitements effectués.
De cette manière, un service va pouvoir être utilisé par plusieurs types de consommateurs. Ainsi,
un service pourra par exemple être utilisé pour un traitement batch massif et pour un traitement
« à la demande » par un utilisateur. Le service de calcul de taux, évoqué plus haut, en est un
bon exemple : traitement massif d’opérations financières par vacation et utilisation pour une
simulation d’opération interactive. Par ailleurs, un service pourra également être invoqué par un
autre service.

Figure 2 - Plusieurs types de consommateurs de services

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

11
1.2.3 Typologie de services
Nous introduisons ici les deux caractéristiques d’un service : sa nature (métier ou infrastructure)
et sa granularité.
Nature de services : services métier et services d’infrastructure
Lorsque l’on évoque les services au sein d’un système d’information, les deux catégories
suivantes sont à distinguer :

• Les services métier : ces services correspondent à des fonctionnalités métier. Cela va
des services de fine granularité comme des fonctionnalités de calcul fondées sur des règles
métier, par exemple une conversion de devise, jusqu’à des fonctionnalités de plus grosse
granularité « encapsulant » un processus métier comme une demande de prêt bancaire.

• Les services d’infrastructure : ces services regroupent un ensemble de fonctionnalités


transverses au système d’information utilisées par les services métier. La gestion des
utilisateurs, un socle mutualisé d’intégration ou d’éditique font partie de cette catégorie.
Différents niveaux de granularité peuvent être identifiés. Ainsi, sur la gestion des utilisateurs,
nous retrouverons des fonctionnalités de fine granularité (récupération d’un identifiant
utilisateur, création d’une session, ...) et de grosse granularité (création d’un utilisateur qui
nécessite l’accès à plusieurs systèmes, ressources humaines, …).

Il convient de noter qu’un glissement peut s’opérer des services métier vers les services
d’infrastructure. En effet, dès lors qu’un service métier devient transverse et est offert par une
plateforme indépendante à l’ensemble du système d’information, ce service pourra être
considéré comme faisant partie d’un socle d’infrastructure, il aura subi un phénomène de
banalisation.

Figure 3 - Le phénomène de banalisation des services métier

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

12
Granularité de service
Comme nous l’avons évoqué à la section précédente, la notion de granularité de service est
essentielle et nous servira de principe structurant dans la suite de ce document. Il existe des
services de fine granularité (règles métier, fonction de calcul, fonction d’accès) et des services
de grosse granularité (gestion utilisateur, gestion de comptes).

• Les services de grosse granularité (services globaux) : ces services exposent la


valeur d’un système d’information (ou encore d’un bloc applicatif) à l’extérieur de ses
frontières, en masquant la complexité de la logique interne. Ils sont typiquement associés à
un cas d’utilisation (use case UML) qui possède une valeur ajoutée intrinsèque pour le
consommateur du service. Dans le cas de services métier, il s’agit généralement d’activités
génératrices de revenu pour l’entreprise (ex. « Souscription Contrat ») et dans le cas de
services d’infrastructure, il s’agit d’activités engendrant des économies d’échelle (ex. gestion
centralisée des comptes et droits des utilisateurs).

• Les services de fine granularité (services unitaires) : les services unitaires ne


supportent pas de cas d’utilisation, ils ne sont pas « vendeurs par eux-mêmes ». Ce sont
des fonctionnalités élémentaires qui trouvent leur valeur dans la réutilisation, que l’on soit au
niveau d’une application (composant logiciel commun) ou entre applications (service
partagé entre applications du système d’information). Dans le cas de services métier, il s’agit
typiquement de règles métier (ex. calcul de taux), consultation de référentiels (ex. existence
d’un client) et dans le cas de services d’infrastructure, de fonctionnalités techniques
réutilisables (ex. accesseur LDAP, service de composition d’un document « à la demande »
à partir d’un flux XML).

Figure 4 - Matrice de caractérisation des services


Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

13
1.3 Le double enjeu SOA : réutilisation et interopérabilité
Le terme SOA est apparu en 1996 dans une note de recherche du Gartner.

Service-oriented architecture (SOA) is a client/server software design approach in which an


application consists of software services and software service consumers (also known as clients
or service requesters). SOA differs from the more general client/server model in its definitive
emphasis on loose coupling between software components, and in its use of separately standing
interfaces.

Le Gartner utilise le terme « Composite Application », cette définition est orientée construction
d’application. Vu sous l’angle de la granularité de services, ce sont principalement des services
unitaires qui sont concernés et la problématique est celle de la réutilisation de services.
Reprenons notre matrice de caractérisation des services. Cet enjeu de la réutilisation prend tout
son sens au niveau des services suivants :

• Services d’infrastructure : sans valeur métier mais que chaque application doit
inévitablement mettre en œuvre pour ses besoins propres (sécurité, éditique, échanges, …).

• Services métier de fine granularité : qu’il s’agisse de la réutilisation de composants


logiciels au sein d’une application (par exemple, une couche logicielle de services communs
pour les chaînes batch ou TP d’une application) ou de l’invocation d’un Web Service
transverse de type « Validation d’adresse », la réutilisation de tels services évite la
duplication de code entre applications ou entre modules de l’application.

En revanche, pour les services métier gros grain qui exposent la valeur d’un système
d’information à l’extérieur de ses frontières, l’enjeu porte plus sur la capacité de ces services à
interopérer avec les autres blocs de SI qui vont en être consommateurs : interopérabilité des
interfaces (fonctions invoquées et données échangées), interopérabilité des échanges
(enchaînement et ordonnancement des messages, connectivité, gestion des erreurs, …),
interopérabilité de la sécurité entre services (identification, authentification, habilitation, ...),
capacité d’intégration par l’IHM3 d’un service dans une application composite.
Ce double enjeu de la SOA, réutilisation et interopérabilité, peut être ainsi représenté Figure 5.

En conclusion, nous proposons la définition suivante d’une architecture orientée services.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

14
Figure 5 - Interopérabilité et réutilisation de services

Un service étant un composant d’architecture rendant une fonctionnalité tout en respectant un


contrat de service, mettre en œuvre une architecture orientée services consiste à structurer
une application, un bloc applicatif voire le système d’information, en services contractualisés
afin d’adresser les enjeux suivants :
- la mise en œuvre de services globaux entre blocs applicatifs, en s’inscrivant dans une
politique d’interopérabilité,
- la recherche de la réutilisation à l’intérieur d’un bloc applicatif ou d’une application, en
particulier au niveau des services d’infrastructure ou des services métier unitaires, en
s’inscrivant dans une politique de réutilisation.

3 : Interface Homme Machine

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

15
1.4 Les gains d’une architecture SOA

Les gains d’une architecture SOA peuvent être de natures différentes selon les points de vue des
acteurs, qu’il s’agisse du métier, des fonctions de support ou des études informatiques.

• Gains pour le métier : profitabilité à travers des services métier. Ces gains sont induits
par les services globaux qui exposent la valeur métier du système d’information. D’un point
de vue concret, ces services ont pour vocation la génération de chiffre d’affaires au travers
de la vente de produits ou de services. La réactivité face aux différents types d’évolution
est améliorée au travers de la maîtrise des processus transverses (ex. mise sur le marché
d’une offre multiproduits par intégration de différents services produit unitaires). En outre,
l’intégration avec des partenaires externes est simplifiée par la capacité à exposer des
services standard de haut niveau (ex. un service de passage de commande, service de
synchronisation de référentiel client).

• Gains pour les services support du SI : réalisation d’économies d’échelle. Ces gains
sont induits par des services d’infrastructure globaux, qui encapsulent des processus de
support comme un processus de gestion des comptes et des droits des employés au niveau
des applications (ex. socles NT/Unix, mail, téléphone, applications métier), déclenché lors
de l’arrivée ou du départ d’un employé. Un tel service permet de réduire les coûts de
fonctionnement du système d’information et cela d’autant plus que le service concerne une
large population d’utilisateurs et un large périmètre d’applications.

• Gains pour les projets : augmentation de la productivité des études. Si l’utilisation de


standards d’interopérabilité facilite les phases d’intégration des projets, l’impact d’une
démarche SOA sur la productivité des équipes informatiques est dû principalement à la
politique de réutilisation de services :

- La réutilisation de code entre applications, en particulier pour les services


techniques (ex. sécurité, échanges, impressions, supervision), permet de factoriser
ces développements entre les différentes équipes projet d’une DSI.

- La réutilisation de composants au niveau d’une application (ex. couche d’accès


aux données, couche de services métier unitaires partagés entre une chaîne batch
et une chaîne transactionnelle), permet de factoriser les développements au niveau
d’un plateau projet.

- La réutilisation de batteries de tests (unitaires, intégration), associées à des


composants logiciels ou services réutilisés permet d’accélérer les phases de tests
en évitant de redéfinir et redévelopper les tests de ces composants.

Ces différents types de gains sont représentés sur la Figure 6.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

16
Figure 6 - Gains d’une architecture orientée services
Bien évidemment, ces gains sont soumis à plusieurs conditions.
Tout d’abord, ces gains sont donnés à titre de pistes pour sensibiliser le lecteur aux types de
gains potentiels d’une SOA. Il conviendra de compléter et d’affiner ces gains en fonction du
contexte et de l’existant de l’entreprise.

Ensuite, rappelons-le, une approche purement technique n’est pas suffisante pour justifier ces
gains. Il est nécessaire d’aborder les enjeux par une réelle étude d’opportunité, prenant en
compte les volets organisationnels, financiers et architecturaux.

Il s’agira notamment de faire preuve d’une grande clairvoyance sur la faisabilité d’une
architecture orientée services, en identifiant les coûts et délais nécessaires à l’exposition de
services et les impacts sur les équipes en place (ex. coûts et délais de « refactoring » du code
legacy, coûts en architecture système pour assurer la qualité de service demandée).

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

17
2. Quelles méthodologies pour la SOA ?
Une méthodologie « ça organise et ça rassure » ! RUP, XP, SADT, RAD, MERISE, ces
acronymes sont familiers à bon nombre d’informaticiens. Qu’en est-il dans le cadre d’une
approche SOA ?

Nous abordons ce sujet en fonction de la granularité concernée : au niveau d’une application (ou
d’un bloc) ou au niveau d’un système d’information. Dans le premier cas, la problématique SOA
est centrée sur la politique de réutilisation de services unitaires au niveau de l’application,
alors que dans le second cas, la problématique est centrée sur la politique d’interopérabilité
entre services globaux du système d’information. De plus, la façon de construire une
application est fondamentalement différente de la façon de construire et faire évoluer un système
d’information. La différence entre les deux tient à la différence d’homogénéité.

Les applications sont généralement homogènes à de multiples points de vue : une équipe
dédiée, des technologies homogènes, un modèle de donnée unique, des traitements regroupés
autour d’un domaine unique, une mise en production simultanée de tous ses composants, …
Pour toutes ces raisons, les applications sont qualifiées d’homogènes et de rationnelles, au
contraire des systèmes d’information. Ceux-ci font preuve d’une nature beaucoup plus
hétérogène, avec des équipes multiples (équipes projet métier dédiées), des technologies
hétérogènes (ex. mainframe, Unix, progiciels et développements spécifiques), des rythmes
d’évolution différents (ex. back-office stable, système de distribution en cycle d’évolution court),
des domaines métier multiples induisant des modèles de données et des logiques de traitement
différents. Pour ces raisons, les systèmes d’information sont qualifiés d’hétérogènes et
d’organiques.

Figure 7 - Différence d’homogénéité entre applications et SI

A la lumière de ces différences, il apparaît utopique, voire contre-productif, d’appliquer aux


systèmes d’information les recettes issues des applications, qu’elles soient méthodologiques ou
organisationnelles. Nous proposons donc des démarches différentes selon le niveau de
granularité.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

18
2.1 Démarche SOA au niveau d’une application : ne changez rien !

A l’intérieur des frontières d’une application, la problématique rencontrée est principalement celle
de la réutilisation de services unitaires. Dans ce cas, nous affirmons que la meilleure
méthodologie est la vôtre, à savoir celle que vous utilisez habituellement pour développer vos
applications, à la fois éprouvée et adoptée par vos équipes.

Considérant que cela ne servirait à rien de resservir une présentation des méthodologies
standard de développement d’applications, concentrons-nous à présent sur une démarche SOA
adaptée à l’échelle d’un système d’information (ou d’un bloc applicatif), fondée sur notre
démarche d’architecture globale.

2.2 Démarche SOA au niveau d’un SI : top-down, bottom-up ?

Mises à part de rares exceptions, les systèmes d’information sont composés de blocs applicatifs
hétérogènes tant du point de vue fonctionnel, technologique qu’organisationnel. L’interopérabilité
apparaît donc comme une nécessité majeure. Face à cette nécessité deux approches
s’affrontent, l’approche légaliste et l’approche organique.

Approche Légaliste « Top Down » Approche Organique « Bottom Up»

• Le SI est un « super bloc applicatif ». • Le SI est constitué de blocs applicatifs autonomes


• Le SI peut être appréhendé de manière globale. et hétérogènes.
• Les services sont identifiés a priori à partir d’une • Le SI est appréhendé bloc applicatif par bloc
démarche de cartographie globale (processus, applicatif.
applications, flux…). • Les services sont identifiés à partir des besoins
• Les services sont identifiés sur le périmètre global projets.
du SI. • Les services sont identifiés sur le périmètre de
communication du bloc applicatif.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

19
Nous nous positionnons clairement en faveur de l’approche organique pour, principalement,
deux raisons :

• Le caractère utopique de l’approche légaliste : l’approche légaliste, si elle est


intellectuellement séduisante et théoriquement idéale, doit faire face à plusieurs difficultés.

- Tout d’abord, la capacité à appréhender un système d’information dans sa


globalité. Est-il raisonnable de vouloir disposer d’une vision complète et détaillée de
celui-ci (ex. banque, ministère) ? La démarche de cartographie souvent mise en
avant est intéressante si l’on demeure à un niveau de granularité grossier. En
revanche, la pousser à un niveau de granularité trop fin engendre des coûts de
maintenance pouvant rapidement devenir prohibitifs au regard de ce que cela
rapporte. Mieux vaut une cartographie grossière mais à jour qu’une cartographie
fine obsolète !

- Par ailleurs, cette approche est difficile dans un contexte ou certains blocs
applicatifs vont, par essence, être stables et nécessiter peu d’agilité (ex. ressources
humaines, back-office, facturation) alors que d’autres vont être en perpétuelle
évolution (ex. distribution, portail extranet).

- Enfin, du point de vue organisationnel, les blocs fonctionnels sont généralement


gérés par des équipes différentes qui peuvent être distribuées géographiquement.
Est-il raisonnable de vouloir les fédérer de manière importante sans que cela ne
nuise à l’aboutissement des projets métier ?

• La recherche de gains rapides pour les projets métier : il convient de garder à l’esprit
que l’objectif d’une architecture, qu’elle soit orientée services ou pas, est d’être au service
du métier et pas uniquement des urbanistes et des architectes. La mise en place de services
doit apporter des bénéfices tangibles aux projets métier. Il est donc impératif que la mise en
place de services pour un bloc applicatif bénéficie d’un retour sur investissement à court ou
moyen terme. Ces délais sont incompatibles avec une approche légaliste du fait de sa
lourdeur.

A l’inverse, une démarche organique pure dans laquelle chaque projet répond « dans son coin
» à ses propres besoins sans vision d’ensemble amène très rapidement le système d’information
dans un état de désordre difficilement réversible et préjudiciable à son évolutivité. L’effort
d’intégration de tout nouvel ouvrage dans le système d’information devient alors un cauchemar :
« syndrome spaghetti » au niveau des échanges, duplication des référentiels, divergence des
modèles de données, …

Le meilleur n’étant jamais au niveau des extrêmes, la démarche que nous vous proposons est
une démarche conciliant les deux visions : il s’agit d’une démarche organique dans un cadre
structuré.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

20
2.3 Notre démarche SOA au niveau du SI

Au niveau d’un système d’information ou d’un bloc applicatif, notre démarche SOA n’est ni plus
ni moins que notre démarche d’architecture globale, fondée sur notre matrice d’architecture,
déclinée afin de prendre en compte les spécificités SOA. Cette matrice permet de donner une
vue synthétique de l’architecture sur les niveaux fonctionnels, technique et système, et sur les
axes services, données, processus, accès et sécurité.

Figure 8 - Matrice d’architecture OCTO Technology

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

21
Structurée par la matrice, notre méthodologie d’architecture s’articule autour de trois éléments
clés :
• Une démarche projet centrée sur le « DAG » (Dossier d’ Architecture Générale) :
véritable fédérateur des visions des utilisateurs, des architectes, des développeurs et des
exploitants, ceci pour toute la durée du projet.

• Un socle de « référentiels SI » : référentiel d’architecture (patterns d’architecture,


patterns organisationnels, outils et méthodes), cartographie générale (services, référentiels,
processus), schéma directeur. Ces référentiels sont mis à disposition des projets.

• Une démarche de capitalisation fondée sur les retours d’expérience des projets :
alimentée par les équipes opérationnelles et pas uniquement par une cellule transverse,
parfois déconnectée de la réalité du terrain.

La Figure 9 illustre cette démarche.

L’étude d’architecture générale consiste, à partir d’une expression de besoins plus ou moins
formalisée (présentations, story-board, note de cadrage, …), à aboutir à la définition de
l’architecture générale du projet et à un plan projet général du projet. Cette phase se veut
itérative - du général au particulier - avec une forte implication des utilisateurs tout au long des
différentes activités :

• L’analyse des besoins consiste à formaliser l’expression de besoins des utilisateurs en


cas d’usage, et à prioriser ces besoins par une démarche centrée sur l’analyse de la valeur.
Tout en restant à un niveau « grosse maille », cette activité fait ressortir les principaux cas
d’utilisation, modèles métier, entités métier et cycles de vie associés.

• La conception générale va procéder par itération en partant de ce premier niveau


d’analyse des besoins pour aboutir à la définition de l’architecture cible, l’étude de l’impact
sur l’existant, les paliers de mise en œuvre et le plan projet général (planning, organisation,
enveloppe budgétaire). L’architecture se décrit à l’aide notre matrice d’architecture, sur les
niveaux fonctionnel, technique et système.

Pour chaque itération, l’art de l’architecte consiste à se nourrir des résultats de l’analyse des
besoins et à s’appuyer sur les différents référentiels (patterns, standards, cartographie de
l’existant) pour proposer un ou plusieurs scénarios d’architecture.
Dans le cadre d’une démarche SOA, c’est à cette étape que seront identifiés les services
unitaires existant à réutiliser, les services candidats à la mutualisation, les services globaux à
invoquer ou à exposer, les formats d’échange entre services (interfaces, formats pivots), les
processus transverses, la sécurisation des accès aux services, les exigences de SLA, …

Les résultats de cette activité sont formalisés dans le Dossier d’Architecture Générale (DAG) et
le Plan Projet Général (PPG). La validation du DAG peut être collégiale puisque le document se
définit comme le « socle de connaissance minimum à partager pour pouvoir correctement
travailler ensemble ». Le collège est bien entendu composé des acteurs du projet (MOE, MOA,
utilisateurs, sponsors), mais aussi d’instances transverses responsable de la cohérence du SI.

Les différents projets de réalisation s’inscrivent dans la ligne directrice du DAG. Ces projets
s’appuieront sur les « référentiels SI » pour récupérer les informations concernant les services
disponibles (ex. interfaces, jeux de tests, SLA), les flux de données (ex. modèles de données
publiques, formats pivot). Point clé de notre démarche organique, c’est également au cours de
ces projets que seront enrichis et mis à jour les référentiels SI pour capitalisation et utilisation
par les futurs projets: évolution de la cartographie du SI, définition des « fiches de service » (voir
ci-dessous), développement ou mise à jour de nouveaux frameworks, …

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

22
Figure 9 - Démarche d’architecture au niveau SI

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

23
Nous voyons que notre démarche ne présuppose pas de l’existence d’un plan quinquennal. Elle
demeure néanmoins tout à fait compatible avec un pilotage stratégique du système
d’information, dans le respect des priorités métier (temps court des projets) et des priorités de la
DSI (temps long de la gouvernance du système d’information).

Cette démarche fait un usage intensif du concept de « pattern », c’est-à-dire de la bonne


pratique organisationnelle, fonctionnelle, ou technique déjà éprouvée dans le système
d’informatique. Nous allons donc maintenant aborder cette partie essentielle de notre Livre
Blanc, qui se concentre sur les patterns centrés sur la problématique d’interopérabilité, donc de
la SOA.

La fiche de service

Figure 10 - Fiche de service

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

24
Comme nous l’avons déjà exprimé à la section 1, il est impératif de définir le contrat de service
et le niveau de qualité de service désiré avec les parties concernées. La question naturelle que
tout un chacun est alors amené à se poser est donc :
Comment garantir une qualité de service pour un service mutualisé alors que potentiellement
on ignore l’usage qui sera fait de ce service ? Par exemple, si le nombre de clients augmente
de manière importante.
Effectivement, ce problème peut se poser pour des services en « libre-service » (comme
l’exemple bien connu du service donnant la température en temps réel pour une certaine zone
géographique), pour lesquels le contrat de service n’est pas explicitement défini. Comment
espérer consommer un service qui nous garantisse un certain niveau de qualité de service si
on n’a pas signé de contrat !!! Remarquez que cette problématique est d’ailleurs assez
similaire de celle, maintenant connue et maîtrisée, de la mise à disposition d’un site web sur
Internet.
Dans le contexte de l’entreprise, nous sommes persuadés que le problème ne se pose pas en
ces termes et que la découverte du service, et surtout de son utilisation dynamique, ne nous
parait pas être un raisonnement envisageable. Nous sommes convaincus que l’utilisation d’un
service est précédée d’une communication entre le consommateur et le fournisseur, qui est
donc au courant de ce supplément d’utilisation et pourra agir en conséquence.
C’est pour cette raison que nous recommandons de documenter les services au moyen d’une
fiche dans laquelle, entre autres informations, nous retrouvons la liste des utilisateurs et les
différents usages respectifs.
La fiche de service fait office de contrat entre le fournisseur et les consommateurs. Ce dernier
point nous apparait comme primordial. Il n’est pas rare de voir des pans entiers de traitements,
implémentés il y a quelques décennies à peine, dont on a perdu toute la connaissance, jusqu’à
ne plus savoir ce qu’ils font et pire s’ils sont encore utilisés ! Afin d’éviter que de telles
erreurs se reproduisent, il est conseillé de bien documenter un service mais aussi et surtout
de documenter son utilisation.
Insistons donc : n’hésitez pas être loquace en donnant le maximum de détails, qui vous
sembleront peut-être futiles mais qui, dans quelques décennies, seront peut-être salvateurs.
Exemple :
« C’est suite à une demande conjointe de Mr Durant, AMOA du secteur Finance, et Mme
Dupond, chef du projet « PYTHAGORE », gestion de la comptabilité client, que nous avons
décidé d’exposer la transaction CICS sous la forme de service. Mr Durant souhaite pouvoir
consulter ce service à toute heure de la journée de manière synchrone avec une garantie de
réponse de 3 secondes maximum. Il souhaite pouvoir réutiliser ce service à partir des
applications X et Y… Mme Dupond n’en a besoin que sur des périodes bien précises,
essentiellement en fin de mois mais en fera une utilisation intensive, estimée à 300 requêtes
par seconde. »

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

25
2.4 Patterns organisationnels

La mise en œuvre de services d’interopérabilité nécessite l’accomplissement d’un certain


nombre de tâches qui ne sont pas uniquement techniques. Il est tout d’abord essentiel d’acquérir
une compréhension métier commune de l’échange entre le bloc applicatif fournisseur de service
et le(s) bloc(s) applicatif(s) consommateur(s) de services.

Dans certains contextes, il est pertinent de mettre en place une équipe transverse dotée de
compétences multiples, à la fois métier, fonctionnelles et techniques. Cette équipe doit assurer
une tâche importante de communication et de médiation. De ce fait, seuls des intervenants dotés
d’une forte expérience peuvent constituer cette équipe. Le choix de ces intervenants est donc un
facteur clé de succès. Nous présentons au travers des patterns suivants deux modes
d’organisation.

2.4.1 Pattern Communauté


Ce modèle repose sur la constitution d’une équipe virtuelle formée des représentants des
différents blocs applicatifs. Chaque bloc applicatif élit donc un représentant qui aura pour tâches
d’exposer ses besoins et de répondre à ceux des autres participants au cours de réunions
organisées de manière régulière. Il est important de noter que l’équipe ainsi constituée n’est pas
forcément visible dans l’organigramme de l’entreprise.

Bien évidemment, le succès de ce modèle organisationnel repose, en grande partie, sur le choix
des représentants. Ceux-ci doivent, à la fois, posséder une parfaite connaissance de leur bloc
applicatif, tant du point de vue technique que métier, et disposer de qualités de communication
et d’autonomie importantes. Ils seront donc recrutés parmi les meilleurs collaborateurs, ce qui du
reste peut constituer une gratification pour ces personnes.
Ce modèle présente, tout d’abord, l’avantage de pouvoir être mis en place rapidement. En effet,
il est possible de commencer par une communauté réduite et de la faire grossir progressivement
au gré des besoins des projets.

Ce modèle présente, par ailleurs, l’intérêt de ne pas induire de changements organisationnels


majeurs. Il contribue donc à consolider l’agilité technique de la SOA par une agilité
organisationnelle. Adapté à des systèmes d’information de taille modérée, ce pattern
organisationnel n’est pas figé et peut être un moyen adéquat d’évoluer vers la mise en œuvre
d’une cellule transverse de gestion des services.

Figure 11 - Pattern Communauté

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

26
2.4.2 Pattern Cellule Transverse
Le modèle organisationnel de la cellule transverse vise un objectif différent du pattern précédent : il
s’applique à un environnement constitué d’un nombre important de blocs applicatifs. Il consiste
à mettre en œuvre une équipe transverse dédiée à la gestion des services (voire, de manière
plus large, des flux). Les objectifs de la cellule transverse sont :

• D’apporter une assistance aux projets : le premier rôle est opérationnel. Il consiste à
assister les équipes projets pour la mise en œuvre de services. Il s’agit in fine d’un centre
de compétences intégrant notamment des développeurs, des architectes et des experts
produit (dans le cas de l’utilisation d’un outil dédié de gestion des services). La cellule
transverse peut aussi apporter assistance à la maîtrise d’ouvrage en phase de définition de
services métier. Enfin, dans le cas de l’utilisation d’un socle dédié à la gestion des services,
une assistance à la production peut aussi être envisagée.

• De prendre à sa charge l’infrastructure de gestion des services : la mise en oeuvre


d’une architecture orientée services peut donner lieu à la mise en place d’un socle technique
dédié. Dans ce cas, la cellule transverse est l’équipe projet qui prend en charge le
développement et la maintenance du socle.

• D’arbitrer la mise en œuvre des services : si la mise en œuvre de services unitaires à


l’intérieur d’un bloc applicatif est aisément arbitrable par l’équipe projet du bloc, il est
beaucoup plus délicat d’effectuer cet arbitrage dans le cas de services globaux transverses.
La cellule transverse, en prenant la position d’un tiers de confiance, peut assurer ce rôle
coercitif.

• De normer la mise en œuvre des services : enfin, la cellule transverse intervient sur le
plan de la normalisation. Cet aspect concerne à la fois le point de vue technologique et le
point de vue méthodologique. C’est la cellule transverse qui va déterminer les technologies
de développement de services et les outils à utiliser. Sur le plan méthodologique, elle va fixer
les normes de développement et de test, fournir des modèles de services, …

Figure 12 - Pattern Cellule Transverse

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

27
Ce modèle organisationnel est adapté à une distribution de services dans un environnement
multilatéral. Le nombre de personnes impliquées dans ce type d’organisation peut varier
aisément. Nous montrons sur la Figure 12 un ensemble de profils que l’on retrouve dans cette
cellule. Le nombre de personnes va varier en fonction de la taille du système d’information, de
la mise en place d’un véritable centre de compétences prenant en charge l’intégralité des
développements de services ou juste une assistance aux projets métier sur le développement.
Dans un système d’information de taille modérée, la cellule transverse pourra être constituée
d’un nombre réduit de personnes et n’assurer que des tâches d’assistance et d’arbitrage.

Le lecteur comprendra que la mise en place d’une cellule transverse crée de facto un nouveau
bloc dans le système d’information, bloc dédié aux échanges interblocs.

2.5 Les patterns d’architecture SOA

S’il est effectivement nécessaire de mettre en place la meilleure organisation possible avec les
bonnes personnes, il est également important de bien les outiller. Les outils que nous proposons
sont des patterns d’architecture fonctionnelle et technique adaptés à une architecture
orientée services. Ces patterns adressent la sécurité, les interfaces homme-machine, les
traitements, la donnée et les processus.

Figure 13 - Les patterns SOA

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

28
2.5.1 Patterns d’architecture fonctionnelle
Un des principes majeurs d’architecture est la dissociation au sein d’un système des fonctions
de communication et des fonctions internes. Ce principe est résumé au travers du pattern
Royaume Emissaire dans lequel le royaume est dévolu aux traitements métier d’un bloc
applicatif et l’émissaire aux fonctions de communication avec les autres blocs.

Comme nous l’avons déjà sous entendu, ce n’est pas parce que l’on communique avec des
services qu’il ne faut pas oublier les bonnes vieilles méthodes de communication. Nous
rappelons cette idée au travers du pattern Modélisation Document. Le principe est de fonder
l’échange d’information sur un modèle pivot simple et dénormalisé.

Le point suivant, que nous voulons aborder, est celui de l’intégration par les interfaces homme-
machine. Ce principe est courant dans le domaine du portail et peut aussi être utilisé dans le
cadre d’une architecture SOA. Nous abordons ce point dans le pattern Agrégation IHM.

Enfin, le dernier sujet que nous avons voulu aborder est celui de la gestion des processus au
travers du pattern Processus Implicite / Explicite. Il est important de faire la distinction entre
les processus métier, ou processus explicites, et les processus techniques, ou processus
implicites. Ces derniers sont généralement orientés données et ont pour objectif la
synchronisation de référentiels alors que les processus explicites vont être beaucoup plus
complexes avec des IHM, la gestion d’état, …

2.5.2 Patterns d’architecture technique


En ce qui concerne les fonctions d’exposition, nous présentons les deux principaux patterns
d’implémentation de services que sont le pattern Façade et le pattern Proxy qui vont différer
par la complexité des fonctions qu’ils mettent en œuvre. En complément nous abordons le
problème de la localisation de services au travers du pattern Service de Localisation.

La partie suivante concerne les modes d’échange. Elle oppose de manière classique la
communication selon le pattern Point à Point ou le pattern Publish/Subscribe.

Nous détaillons, par la suite, le pattern Fédération d’Homologation qui, de par l’utilisation de
jeux de données cohérents dans le temps, participe à l’amélioration de la productivité des actions
de tests de services et, plus généralement, de blocs applicatifs.

Nous distinguons 3 principaux patterns de sécurité. Tout d’abord, le pattern de la Zone Implicite
de Confiance qui consiste à décharger les services de la gestion de la sécurité (principe de
firewall). Le second pattern, dit de la Zone Explicite de Confiance, consiste à utiliser un serveur
de sécurité tout en laissant l’initiative de son appel aux services (principe du serveur de sécurité
centralisé). Enfin, le troisième pattern, celui de la Fédération de l’Identité, a pour objectif
d’assurer un service d’authentification unifiée tout en respectant l’anonymat des utilisateurs
(principe de Liberty Alliance).

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

29
3. Patterns d’architecture fonctionnelle
Nous présentons dans ce chapitre les principaux patterns permettant de structurer l’aspect
fonctionnel d’une architecture orientée services.

Figure 14 - Patterns d’architecture fonctionnelle

3.1 Royaume / Emissaire

Comme nous l’avons déjà énoncé, il est fréquent de constater que les blocs applicatifs d’un
système d’information divergent tant du point de vue technologique (ex. back-office mainframe
et front-office J2EE), conceptuel (ex. modèles de données différents pour un même objet métier)
qu’organisationnel (équipes différentes). Pourtant, ces blocs applicatifs doivent communiquer
entre eux d’où la nécessité de contrôler la zone d’échanges, ce qui s’avère souvent très
complexe.

Un des principes structurant d’architecture de système d’information est d’isoler les fonctions
intrinsèques d’un bloc applicatif de ses fonctions de communication avec l’extérieur. Le pattern
Royaume / Emissaire est fondé sur ce principe. Le royaume représente le cœur du bloc applicatif :
le savoir. En langage d’informaticien, nous appelons cela le « métier », avec ses déclinaisons :
règles métier, objets métier, applications métier, … Ainsi, vous l’aurez compris, le royaume se
focalise sur son métier et délègue toutes les actions de communication à un émissaire qui joue
le rôle d’intermédiaire avec le reste du monde. Ce dernier est responsable de la gestion et de la
sécurité des échanges avec les autres blocs applicatifs ainsi que de la validation et de la
transformation des données en entrée/sortie du royaume.

En fonction de l’importance du royaume, ce pattern pourra être reproduit afin de représenter des
blocs applicatifs plus petits. D’où les notions de « pattern fractal » et d’ « émissaire des
émissaires ».

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

30
Figure 15 - Pattern Royaume Emissaire

Dans un contexte SOA, le pattern Royaume / Emissaire est utilisé de différentes manières :

• Il va tout d’abord jouer son rôle principal : isoler des blocs applicatifs distincts afin de
faciliter leur interopérabilité. A chaque bloc est associé un émissaire responsable de la
communication avec son royaume, lui-même constitué d’applications ou de services
globaux. Il s’agira d’être vigilant face à la bonne définition des contrats de services exposés
par l’émissaire, ceux-ci pouvant être soumis à de fortes contraintes. L’objectif est de
favoriser l’interopérabilité au niveau du système d’information et d’augmenter la capacité
d’adaptation aux changements.

• A l’intérieur d’un bloc applicatif, l’émissaire représente l’accès aux services globaux évitant
ainsi des interactions directes entre services de plus faibles granularités. L’objectif est de
faciliter la réutilisation de services sans tomber dans les travers d’un couplage trop fort.

L’implémentation de ce pattern peut prendre différentes formes que nous détaillerons lorsque
nous aborderons le pattern façade. Nous verrons en particulier que l’émissaire manipule des
données publiques de l’entreprise et son principal rôle est de les mettre à disposition du royaume
dans une déclinaison qui lui est spécifique (des modèles relationnels historiques par exemple).

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

31
3.2 Modélisation document

Comment communiquer entre systèmes ? Quelle technologie pour échanger des données ? Qui
possède la bonne structure des données ?

Voilà des questions qui méritent d’être posées et qui malheureusement concourent souvent à la
mise en œuvre de solutions pénalisantes à long terme pour l’évolutivité du système
d’information.

Bien que nous ayons déjà largement abordé ce sujet au travers du Livre Blanc consacré à la
gouvernance de la donnée4, il nous parait important, en regard des enjeux, d’en rappeler certains
principes par l’intermédiaire de ce pattern.

L’échange d’information entre blocs applicatifs est souvent complexe, non seulement à cause
d’incompatibilités technologiques mais surtout à cause de leurs modèles de données privatifs. La
même information (clients, fournisseurs, produits,…) va donc se retrouver dupliquée et définie de
manières différentes. Il est souvent nécessaire d’appliquer une transformation pour l’intégrer
dans le modèle de données du destinataire.

Alors, quel langage utiliser pour représenter ces données échangées ? Dans un contexte où tout
le monde parle le même langage, il n’est pas besoin de traduction mais que se passe-t-il aux
frontières, dans un contexte multiculturel ? Il faut s’adapter. Il faut alors trouver un langage qui
soit compris par tout le monde et, à défaut de lingua franca, il faut souvent trouver un compromis
et élire un langage par défaut. Dans la vie de tous les jours, c’est l’anglais. Dans le monde de
l’informatique, XML est en train de s’imposer comme le langage universel.

Le modèle document impose simplement de standardiser la communication en passant par une


représentation hiérarchique des données échangées sous la forme d’un document XML. Ce
pattern est couramment utilisé dans les solutions d’intégration d’applications (EAI).

Figure 16 - Echanges entre modèles privatifs de données

4 : Le Livre Blanc “Gouvernance de la donnée” est disponible en téléchargement sur le site d’OCTO Technology : http://www.octo.com

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

32
Il est intéressant de coupler le modèle document avec une normalisation des données publiques
de l’entreprise. Nous recommandons d’aborder cette tâche de manière progressive, bloc par
bloc, à l’occasion de la refonte ou de la rénovation d’une partie du système d’information. Les
données modélisées sous la forme de document vont, petit à petit, venir alimenter l’arbre de
l’information de l’entreprise.

Dans un contexte SOA, nous préconisons d’utiliser ce pattern pour implémenter les services gros
grain. C’est l’émissaire de ces services qui sera en charge de la transformation de modèles.
Afin de clarifier notre propos, prenons un exemple simple mais suffisamment illustratif. Un
système comptable doit consolider les commandes passées par un système de facturation. Nous
nous focalisons sur les données échangées et non sur la manière dont elles sont échangées (ex.
synchrone/asynchrone, temps réel/par vacation).
Le système de facturation en question possède le modèle de données relationnel suivant :

Figure 17 - Modèle de données du système de facturation

De l’autre côté, le système comptable possède lui aussi un modèle de données spécifique :

Figure 18 - Modèle de données du système comptable

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

33
L’échange de données entre le système de facturation et le système comptable pourrait se faire
en utilisant l’un des deux modèles. Mais lequel ? Dans les deux cas, un des deux systèmes doit
s’adapter et un couplage fort se crée, limitant l’évolutivité des deux systèmes.

Nous nous proposons de mettre en pratique le pattern Modélisation Document couplé avec le
pattern Royaume/Emissaire. Nous supposons que les deux systèmes délèguent les actions de
communication à leur émissaire respectif. L’émissaire du système de facturation pourra par
exemple exposer un service d’extraction des commandes qui se chargera de transformer les
données transmises d’un modèle de données relationnel en une représentation hiérarchique.
L’émissaire du système comptable effectuera l’action inverse afin d’intégrer les données reçues
dans son propre modèle de données.

Les factures échangées, sous forme de données publiques, pourront ressembler à l’exemple
suivant (nous avons pour les besoins de l’exemple simplifié le modèle) :

Figure 19 - Modèle hiérarchique des données échangées

Le schéma XML correspondant sera :

<?xml version=”1.0” encoding=”UTF-8”?>


<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema”>

<xs:element name=”facture”>
<xs:complexType>
<xs:sequence>
<xs:element name=”facture_ID” type=”xs:string”/>
<xs:element name=”date” type=”xs:string”/>
<xs:element ref=”client”/>
<xs:element ref=”ligne_commande” minOccurs=”1”
maxOccurs=”unbounded”/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name=”client”>
<xs:complexType>
<xs:all>
<xs:element name=”client_ID” type=”xs:string”/>

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

34
<xs:element name=”nom” type=”xs:string”/>
<xs:element name=”prenom” type=”xs:string”/>
</xs:all>
</xs:complexType>
</xs:element>

<xs:element name=”ligne_commande”>
<xs:complexType>
<xs:all>
<xs:element name=”prix_client” type=”xs:string”/>
<xs:element name=”quantite” type=”xs:string”/>
<xs:element ref=”produit”/>
</xs:all>
</xs:complexType>
</xs:element>

<xs:element name=”produit”>
<xs:complexType>
<xs:all>
<xs:element name=”product_ID” type=”xs:string”/>
<xs:element name=”nom” type=”xs:string”/>
</xs:all>
</xs:complexType>
</xs:element>

</xs:schema>

Et enfin, voici un exemple de données échangées entre les deux systèmes :

<?xml version=”1.0” encoding=”UTF-8”?>


<!—Sample XML file generated by XMLSPY v5 rel. 4 U (http://www.xmlspy.com)—>
<facture xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:noNamespaceSchemaLocation=”D:\order.xsd”>
<facture_ID>FACT003241</facture_ID>
<date>12/02/2001</date>
<client>
<client_ID>CLT01521</client_ID>
<nom>Durant</nom>
<prenom>Paul</prenom>
</client>
<ligne_commande>
<prix_client>2497.80</prix_client>
<quantite>23</quantite>
<produit>
<product_ID>PR00712</product_ID>
<nom>Imprimante Laser Couleur AZ41</nom>
</produit>
</ligne_commande>
<ligne_commande>
<prix_client>20.00</prix_client>
<quantite>100</quantite>
<produit>
<product_ID>PR00021</product_ID>
<nom>Disquette 1.44</nom>
</produit>
</ligne_commande>
</facture>

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

35
L’application du pattern Modélisation Document a permis de découpler les deux systèmes et
d’isoler les actions de transformation dans les émissaires. Ainsi, les deux systèmes vont pouvoir
évoluer à leur propre vitesse sans s‘impacter mutuellement. Cette technique, employée dans un
contexte SOA, permettra de faciliter l’évolutivité des services tout en favorisant la construction
de l’arbre d’information de l’entreprise.

Faire coexister SOA et DOA (Data Oriented Architecture)


Au travers du Livre Blanc « Gouvernance de la donnée », nous avons insisté sur la nécessité
d’avoir une démarche de qualité des données utilisées dans le système d’information. Il en est
évidemment de même dans le contexte SOA. La SOA répond, entre autres, au besoin
d’intégration des processus, notamment par le partage de services et, in fine, l’orchestration
de ces services.

Or, l’intégration dans les systèmes d’information, c’est aussi l’intégration par la donnée (DOA)
avec pour exemples la synchronisation de bases de données, le transfert de données par
vacation, ... Evidemment, ce mode d’intégration par la donnée n’est pas prêt d’être remplacé
et continuera d’exister : tout bloc applicatif produit et consomme de la donnée partagée. SOA
et DOA vont donc ainsi coexister.
Mieux, la SOA a besoin de la DOA. En effet, si la SOA est porteuse de la normalisation des
services métier de l’entreprise, la DOA est porteuse de la normalisation des données métier
de l’entreprise, typiquement à partir de standards internationaux : HRML, SwiftML, ebXML, …
Par exemple, pour le servie calculer_profil_risque_deal(dealXX) il est nécessaire de
normaliser l’objet métier « deal » :
- caractéristiques
- contreparties
- cash flows
- risque
- règlement / livraison
-…

3.3 Processus implicite / explicite

La gestion de processus métier (BPM) et la SOA sont souvent associées au travers de


l’orchestration des services, qui est vue comme un moyen d’implémenter facilement un
processus métier. Les éditeurs de logiciels nous promettent encore des miracles avec de
supposés outils permettant, en quelques clics de souris, d’implémenter un processus et de le
modifier aussi facilement. Qu’en est-il dans la vraie vie ? Est-ce bien le problème ?

Tout d’abord, rappelons que l’urbanisation du système d’information, par l’intermédiaire de


l’analyse des processus d’entreprise, a pour vocation d’obtenir une image, non pas exhaustive
mais grossière, des principaux processus métier de l’entreprise à des fins d’audit d’organisation
ou de définition de schémas directeurs informatiques. Lors de cette tâche, il est très important
de se fixer une limite. On peut imaginer qu’une entreprise de taille importante possède une
dizaine de macro processus, pouvant se décliner en une centaine de sous processus. C’est déjà
beaucoup. Et puis, STOP ! Cela ne sert à rien d’aller plus loin et d’essayer de modéliser des pico
processus. Ce n’est malheureusement pas avec des pico processus que l’on va urbaniser le
système d’information.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

36
Prenons un exemple : imaginons que nous sommes en train d’analyser les processus d’une
mairie en se concentrant sur les services aux usagers. Les macro processus suivants peuvent
être identifiés :

• Etat civil et affaires générales


- La délivrance de pièces d’état civil
- L’inscription électorale
- L’autorisation de sortie du territoire

• Urbanisme
- L’octroi de permis de construire
- L’octroi d’un permis de démolir
- La déclaration de travaux

Le processus « Octroi du permis de construire » est très complexe et possède de nombreuses


règles métier en fonction de multiples paramètres (type de construction, nature des travaux,
localisation, les règles d’urbanisme en vigueur, …). De plus, le processus sera différent que l’on
soit une personne morale ou une personne physique. Ce type de processus pourra difficilement
être modélisé à l’aide d’un outil. Traditionnellement, il sera modélisé dans le cadre du
développement de l’application au travers de cas d’usage détaillés (Use Cases) et des différents
diagrammes associés.

Dans la réalité il en est de même : les processus d’entreprise sont souvent complexes, avec
états, interactions humaines, règles de gestion complexes, procédures de réaffectation. Ils se
prêtent rarement à une modélisation au travers d’un outil de BPM. Notre expérience nous pousse
donc à avoir une position réservée quant à l’utilisation des outils de gestion de processus. Si
ceux-ci sont maintenant suffisamment matures pour gérer des processus séquentiels temporels,
ils pèchent encore pour la gestion de processus complexes.

Nous pensons que la flexibilité que les entreprises attendent n’est pas liée à la mise en œuvre
d’un outil de gestion de processus mais plutôt à la maîtrise de son architecture fonctionnelle.
Nous vous proposons de réfléchir à la nature des processus : de quel type de processus suis-
je en présence ?

Les processus métier sont ceux qui viennent tout de suite à l’esprit. Ce sont ceux qui supportent
la stratégie de l’entreprise, qui sont le symbole de l’automatisation et des gains de productivité.
Ce sont ceux-là que l’entreprise va chercher à optimiser puisqu’ils sont source de gains
importants. Nous qualifions ces processus d’explicites. Les macro processus transverses, très
rares, sont candidats à une externalisation au sein d’un outil de gestion de processus (ex :
EAI/BPM). Ceux, non transverses, se retrouvent localisés au sein même des applications. Leur
implémentation peut alors varier du développement spécifique à l’utilisation d’un outil spécifique
(BPM ou Workflow), toujours local à l’application concernée.

Par opposition, l’entreprise (ne devrait-on pas dire la DSI ?) possède des processus de support
au bon fonctionnement du système d’information. Ces processus ont rarement de sens pour le
métier de l’entreprise et sont, la plupart du temps, orientés synchronisation ou alimentation de
données. Par exemple, l’alimentation de l’entrepôt de données du système décisionnel. Nous
qualifions ces processus d’implicites. De part leur nature transverse, ils sont de bons candidats
à une externalisation au sein d’un outil d’infrastructure (ex : EAI, ETL).

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

37
Après avoir identifié le type d’un processus, il est intéressant de s’intéresser à son
implémentation. De part leur nature très différente, il est possible d’effectuer des choix
d’implémentation très différents : EAI, ETL, BPM, outil de Workflow, application dédiée, …
Nous distinguons deux caractéristiques principales de la gestion d’un processus entre
applicatifs :

• l’orchestration du processus : c’est-à-dire le moteur d’exécution permettant le passage


d’un état à l’état suivant du processus,

• le suivi du processus : c’est-à-dire la capacité à savoir dans quel état se trouve un


processus à un instant donné ainsi que ceux par lesquels il est passé.

Comme le montre le tableau page 39, ces deux propriétés peuvent être localisées dans les
applications participant au processus ou être externalisées dans un outil dédié.

En conclusion, nous pouvons donc synthétiser le pattern Processus Implicite / Explicite de la


manière suivante :

• La quasi-totalité des processus explicites sont implémentés au sein même des


applications, leur complexité n’est pas propice au développement à l’aide d’un BPM.

• Les outillages de BPM servent l’orchestration de tâches séquentielles, par exemple un


traitement Back-office nocturne.

• Les outillages de BPM peuvent orchestrer des échanges inter-domaines, le plus souvent
de nature implicite : irrigation des référentiels, extraction vers les systèmes de synthèse.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

38
Processus distribué Orchestration centralisée / Orchestration centralisée
Suivi distribué BPM actif
BPM passif

Orchestration du Dans les applications Dans les applications Externalisé


processus

Suivi du processus Dans les applications Externalisé Externalisé


Description Chaque application Le processus reste à La logique d’enchaînement
participante possède un bout l’initiative des applications, un du processus est externalisée
de logique de gestion de module central assure le suivi des applications et centralisée
processus transverse. de l’avancement du dans un outil dédié.
processus.

Avantages / + Solution pragmatique + Suivi de bout en bout (mais + Evolutivité optimale du


Inconvénients + Adapté à l’organisation en à développer) processus
place + Facilement réalisable sur un + Suivi de bout en bout
- Evolutivité coûteuse socle d’intégration possible (intégré au moteur,
- Difficulté d’avoir un suivi de - Evolutivité coûteuse des pas de développement)
bout en bout processus inter-applicatifs + Facilement réalisable sur un
- « Pollution » des (intrusion au niveau des socle d’intégration
applications par de la logique applications) - Nécessite une organisation
inter-applicative - Nécessite une organisation dédiée à la gestion du noyau,
dédiée à la gestion du module responsable du processus
de suivi des processus - Coût élevé de mise en
- Coût élevé de mise en œuvre et des ressources
œuvre et des ressources

Considérations Adapté à des processus Répond au besoin de suivi Adapté aux processus
simples et stables dans le d’un processus transverse complexes, instables dans le
temps Processus moyennement temps et impliquant plusieurs
complexes, plutôt stables applications.
dans le temps, impliquant un Scénario de mise en oeuvre:
nombre important
d’applications. • Module BPM d’un socle
d’intégration
Solution d’intégration sans • Application BPM dédiée,
utilisation du module BPM. intégration XML avec les
applications (ESB, Web
Services…)

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

39
3.4 Agrégation d’IHM

Depuis l’avènement des technologies Web telles que HTML, JSP, ASP et plus récemment les
portlets, le besoin d’agrégation d’informations sur le poste de l’utilisateur est de plus en plus fort.
La bulle Internet nous ayant dérouté quelques années en nous abreuvant de success stories (à
base de cas d’utilisation orientés essentiellement B2C voire B2B) toutes aussi fabuleuses que
non lucratives, nous sommes en train de nous rendre compte que l’intérêt pourrait résider dans
une utilisation interne à l’entreprise ! Juste retour des choses.

En effet, il est maintenant possible de penser fournir le poste de travail unifié, source de
productivité, que nos employés désespéraient d’avoir un jour. Fini les n fenêtres d’applications
possédant une interface utilisateur totalement différente. A nous le poste de travail unifié, le
portail d’entreprise de l’employé, point unique d’accès de mon travail, dans lequel je retrouve
mes applications métier anciennes ou nouvelles générations, mes bases de connaissance, ma
messagerie, ma liste de taches, et même la liste des collègues en ligne susceptibles de
m’assister en cas de problème ; et tout ça, totalement intégré, avec la possibilité de
personnaliser complètement mon environnement … Je peux même changer la couleur du fond
d’écran !

Vous allez me dire : quel rapport avec la SOA ?

Et bien, c’est évident ! Les bouts d’applications, les pages, les informations à intégrer sont des
services du point de vue de l’application appelante et doivent être traités tels quels puisqu’ils
proposent un service et se doivent de respecter un contrat de service.

Et d’ailleurs, toute la difficulté est ici : avec les nouvelles technologies proposées (portlet, Web
clipping, URL rewriting, …), il est devenu si facile d’intégrer de l’information que l’on oublie
encore une fois l’essentiel. Si vous avez l’intention que votre application (portail, poste de travail
unifié ou autre) garantisse un certain niveau de qualité de service à vos utilisateurs, il faut
s’assurer en contrepartie du respect de la qualité de service des services intégrés.

En d’autres termes : contractualiser votre relation avec vos fournisseurs de service IHM.

Cette tâche doit être effectuée pendant la phase d’architecture fonctionnelle, en collaboration
avec les responsables des différents services ou applications à intégrer.

D’un point de vue plus technique, l’intégration au niveau de la couche de présentation concerne
essentiellement deux types de services :

• Des services orientés données : ces services ne fournissent qu’un résultat, la


présentation des données est à la charge de l’application appelante.

• Des services orientés présentation : ces services s’occupent de présenter directement


les données, l’application appelante n’ayant plus qu’à intégrer la partie de page reçue.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

40
Figure 20 - Intégration de services orientés données ou présentation

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

41
4. Patterns d’architecture technique
Nous présentons dans les sections suivantes les patterns d’architecture technique satisfaisant
les besoins d’exposition, d’échange, d’homologation et de sécurisation d’une architecture
orientée services.

Figure 21 - Patterns d’architecture technique

Des solutions d’implémentations : L3G ou L4G ?

Qui se souvient encore de ces deux acronymes et de ce qui se cache derrière ? Comme
souvent en informatique, dès qu’un concept ou un acronyme arrive à maturité et est finalement
accepté, on lui cherche déjà son successeur sous prétexte qu’il est has been.

Allez, séance de rappel pour ces deux acronymes qui ont presque disparu de la circulation et
qui ont pourtant encore tellement leur place.

L3G : Langage de Troisième Génération. On retrouve dans cette catégorie les langages tels
que Java, Cobol, Pascal et C. Notre définition va même s’étendre à l’utilisation de frameworks
facilitant et structurant le développement tout en restant toujours très proche du code.

L4G : Langage de Quatrième Génération. Ce terme est devenu très populaire au début des
années 90, avec l’essor du client / serveur et des outils tels PowerBuilder ou Delphi. L’objectif
est de proposer une abstraction supplémentaire (pour cacher la tuyauterie et le code) et de
rendre plus accessible le développement afin de gagner en productivité, à condition de rester
dans le cadre du L4G. Car tout le problème est là, on a voulu trop cacher ! Du coup, le
développeur n’a plus la maîtrise et se retrouve parfois dans des impasses qu’il contourne à
grands coups d’astuces toutes autant ingénieuses que dangereuses pour la solution
développée. Enfin, ces solutions s’appuyaient souvent sur des technologies propriétaires qui
avaient pour inconvénients de proposer des modèles de développement non standard et des
dépendances fortes vis-à-vis de l’éditeur.

Heureusement, l’arrivée de certains standards et l’avènement de Java ont modifié beaucoup


de choses. Les frustres L3G ont étoffé leur panoplie d’assistants en tout genre (génération de
code et autres outils d’assistance visuels), alors que les L4G propriétaires ont jeté à la poubelle
leurs langages propriétaires et se sont ouverts en proposant pour certains des vues «
avancées », permettant de voir le code ! ! !

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

42
Aujourd’hui, le concept de L4G fait place à celui de Domain Specific Language (DSL). On s’est
aperçu en effet que le L4G qui fait tout (ex. des écrans, des échanges, des tests) n’existerait
pas avant longtemps. Ces ambitions revisitées à la baisse conduisent les acteurs à fournir des
métaphores de code évoluées, mais par univers restreint. Les outils EAI sont des DSL dédiés
à l’intégration, vous ne développerez pas une application de gestion avec.

Nous utiliserons, dans ce chapitre, ces deux métaphores afin d’illustrer les différentes
solutions d’implémentation des différents patterns proposés : code ou DSL.

4.1 Exposer des services

4.1.1 Le « proxy »
La réutilisation, chimère de l’informatique pour certains et réalité palpable pour d’autres, demeure
un sujet récurrent dans les salons des DSI. La motivation initiale tient en une phrase qui peut
sembler évidente et dépasser le cadre des systèmes d’information « à quoi ça sert de réinventer
la roue ? ».

Un des intérêts du service va donc bien être dans sa réutilisation, nous allons même plus loin en
disant que l’intérêt d’un service va être dans la réutilisation de l’existant. La capitalisation sur les
actifs de l’entreprise fait donc partie des objectifs poursuivis.

Le proxy est un pattern bien connu en informatique et fortement usité pour permettre l’accès à
des objets distants (ex. CORBA, DCOM, EJB, .NET Remoting), des traitements transactionnels
(ex. CICS, TUXEDO), des traitements orientés données (ex. procédures stockées) ou encore
des progiciels (ex. SAP, SIEBEL, PeopleSoft).

Figure 22 - Le proxy

Dans le contexte SOA, à la standardisation technique d’accès au service vient s’ajouter la notion
de contrat de service et d’interface standardisée. Un service se propose de décorréler l’interface
exposée de l’implémentation du traitement exécuté (modèle objet, signature de fonctions, …).

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

43
Le proxy permet d’exposer, de préférence, des services unitaires; les services globaux étant
généralement exposés à l’aide de la façade, que nous étudierons plus loin.

Fournir une interface stable d’accès au service


Pour garantir cette stabilité, il est nécessaire de mettre en œuvre une couche d’abstraction afin
qu’un changement sur l’implémentation du service n’ait pas d’impact important sur les
consommateurs du service. Certaines technologies intègrent nativement ce concept (ex. Web
Services), au contraire d’autres (ex. EJB, .NET Remoting, CORBA) qui n’offrent pas de couche
d’abstraction et qui propose un couplage fort entre le traitement exposé et son interface
d’utilisation.

Dans le cas où ce concept n’est pas disponible, il est recommandé d’appliquer une bonne
pratique de développement en incluant cette couche d’abstraction. Par exemple, au lieu
d’exposer un EJB directement, on pourra le faire au travers d’un autre objet de délégation
(pattern Business Delegate5).

Standardiser l’accès au service


Malgré ce que l’on pourrait penser après le bombardement médiatique des partisans des Web
Services, l’exposition d’un service n’impose pas la mise en œuvre d’une technologie particulière.
L’interopérabilité est portée par la standardisation et le respect du contrat de service. Ainsi, en
environnement purement mainframe, la technologie adéquate pourrait être l’utilisation de
transactions CICS.

Il existe pourtant des cas où il est préférable d’exposer un service de manière « ouverte » afin
qu’il soit accessible par plusieurs types de consommateurs, i.e. technologies.

La technologie des Web Services permet d’exposer un service en utilisant les standards Internet
et ajoute une couche d’abstraction supplémentaire afin d’éviter un couplage fort entre la
technologie d’appel et celle utilisée pour développer le service. A l’inverse des appels RPC6, le
client d’un Web Service n’a pas besoin d’être développé dans la même technologie ; mieux, il
ne sait même pas quelle technologie a été utilisée pour développer le service. C’est du «
couplage lâche technique » mais, comme nous l’avons expliqué précédemment, cela
n’empêche aucunement une adhérence fonctionnelle forte entre les applications et il demeure
plus difficile de les découpler du point de vue des données (voir le pattern Modélisation
Document).

Gestion de l’accès à distance


Si le besoin est exprimé, le proxy pourra proposer un mécanisme d’accès à distance au service.
Il sera en charge de la communication distante donnant l’impression au consommateur que le
service est local. Il effectue les actions suivantes:

• gestion du protocole de communication,


• pliage / dépliage des données ou objets échangées,
• gestion des erreurs survenues lors de la communication distante.

Exemple de proxy
La « servicisation » technique d’un traitement java ou .NET s’est banalisée. Les différents
environnements de développement permettant d’enrober ce type de traitement à l’aide d’une
couche de Web Service par exemple. Cette facilité relative ne doit pas nous faire oublier que le
traitement que nous souhaitons exposer n’a pas forcément été conçu comme un

5 : Fait partie des principaux Patterns Java définis par SUN : http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
6 : Remote Procedure Call

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

44
service (ex. accès concurrents, disponibilité, performance, sécurité). Il faut donc commencer
par s’assurer de cette compatibilité et revoir, sinon établir, le contrat de service. Il est parfois
nécessaire de repenser sa conception.

Prenons un exemple : nous souhaitons réutiliser une transaction CICS qui renvoie les
informations complètes pour un client identifié en paramètre. Comment transformer cette
transaction en service pour qu’elle soit accessible à partir de différents environnements ?

Pour ce faire, nous choisissons d’utiliser Host Integration Server de Microsoft (ou tout autre DSL
équivalent) pour générer, à l’aide d’un assistant, un proxy pour notre transaction.

Figure 23 - Etapes de création d’un proxy technique sur une transaction CICS (Microsoft HIS)

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

45
Le proxy généré se charge des actions de communication avec le système transactionnel :
mapping avec la COMMEAREA, conversion technique des données en entrée et en sortie.

A ce stade, nous disposons d’un proxy technique nous permettant d’appeler la transaction et
d’obtenir le résultat mais ne satisfaisant pas complètement aux exigences SOA. Il manque
l’essentiel : le contrat de service et l’interface d’accès stable. Nous recommandons d’utiliser une
fiche de service pour documenter le service (voir la Figure 10 - Fiche de service) et établir un
contrat entre le fournisseur et chaque consommateur.

Une fois le contrat de service signé, il faut maintenant satisfaire à la deuxième contrainte :
proposer une interface d’accès stable afin d’éviter que tout changement impacte de manière
importante l’ensemble des consommateurs.

Deux possibilités :

• le contexte technologique est compatible : dans ce cas, soit le proxy généré possède une
couche d’abstraction par rapport au traitement concerné, soit il faut créer cette couche, par
l’intermédiaire d’un objet de délégation (utilisation de pattern Business Delegate).

• le contexte technologique est hétérogène : il faut introduire une nouvelle couche


d’abstraction « standardisée ». L’utilisation des Web Sevices semble toute indiquée.

Le service ainsi défini pourra participer à un processus de plus haut niveau qui lui-même pourra
être mis à disposition sous la forme d’un service.

Figure 24 - Exemple de services participant à un processus (Microsoft BizTalk)

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

46
4.1.2 La façade
La façade est l’un des patterns les plus importants de la SOA. Il va permettre d’organiser et de
structurer l’accès aux services qu’ils soient métier ou d’infrastructure. A la différence du proxy, la
façade va jouer l’intermédiaire entre les consommateurs et un ensemble de services, et non plus
uniquement un seul service. En ce sens, la façade va permettre d’implémenter des services de
plus grosse granularité.

Nous pouvons d’ores et déjà dire que la façade aura deux représentations majeures dans la
SOA :

• Au niveau de l’interopérabilité entre blocs applicatifs : nous avons vu qu’il était souhaitable
d’utiliser le pattern Royaume/Emissaire. L’implémentation de l’émissaire se fait avec une
façade, qui joue le rôle de portail des services globaux.

• Au sein de chaque bloc applicatif : nous avons vu que la problématique principale était la
réutilisation de services de plus ou moins grosses granularités. Il est souvent nécessaire de
structurer l’accès aux services afin d’éviter que le système devienne rapidement difficile à
maîtriser et à faire évoluer (le comble de la SOA). La façade va jouer le rôle de portail de
services unitaires, soit pour représenter directement un service global soit pour représenter
un service intermédiaire d’accès à un bloc de services (cas plus rare où le service global
sous-jacent représente un bloc applicatif important).

L’objectif principal de la façade est donc de proposer une interface unifiée pour l’accès à
plusieurs services faisant partie du même sous-système. La façade va avoir recours à une
panoplie d’actions de préparation et d’organisation des services. Ces actions ne sont pas liées
aux traitements proprement dits des services.

Figure 25 - La façade

Une façade peut être implémentée sous différentes formes :

• Un composant développé « à la main » (ex. Java, .NET).


• Une brique d’infrastructure (ex. EAI, ETL) qui fournit les services de médiation avancés.

Nous distinguons cinq services de médiation : Transformation, Routage, Enrichissement,


Validation et enfin Orchestration.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

47
Il est d’ailleurs intéressant de constater que ces différentes actions peuvent être implémentées
sous la forme de services techniques du socle d’échanges. Il existe différentes options pour
implémenter (nous allons détailler ce point dans les sections suivantes) et ordonnancer ces
actions entre elles, que ce soit au travers de code, par appels successifs des services ou à l’aide
d’un outil spécialisé.

Figure 26 - Exemple d’ordonnancement des services de médiation avec un outil


spécialisé (webMethods)

Validation
Les besoins de validation au sein d’une façade sont essentiellement liés au besoin de
normalisation des messages d’entrée, c’est-à-dire de la validation technique. Il est impératif de
s’assurer du bon respect des règles syntaxiques. En revanche, mis à part des cas d’exception,
la validation sémantique du message sera effectuée au sein des services eux-mêmes,
responsables de la logique métier.

Là encore, plusieurs options d’implémentation sont possibles ; du code à l’outil spécialisé en


passant par les langages dédiés.

Les outils spécialisés, tels les EAI ou ETL, proposent des services à valeur ajoutée facilitant cette
action de validation. Par exemple, lors de la création de l’objet supposé représenter la structure
de données du message en entrée de la façade, des méthodes de parsing sont
automatiquement proposées. Elles permettent de prendre des données reçues sous une forme
non structurée et de les injecter dans une structure de données typées.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

48
Figure 27 - Exemple de méthodes de validation technique (SeeBeyond ICAN 5)

Lors de l’appel de cette méthode, si une erreur est détectée, une exception est levée et le
concepteur pourra réagir de manière adéquate.

public void receive( com.stc.connectors.jms.JMS input,


facture.Facture facture,
com.stc.connectors.jms.JMS queueValidation,
com.stc.connectors.jms.JMS queueFacturation)
throws Throwable{
facture.unmarshalFromString( input.getText() );

}

Enrichissement
La façade a parfois besoin d’enrichir le message reçu par des informations complémentaires
avant de poursuivre le déroulement des opérations. Ces informations peuvent être de diverses
natures : technique (ajout d’indicateurs pour le traitement) ou métier (ajout d’informations métier
relatives à une clé). Elles peuvent provenir de diverses sources de données comme le résultat
de l’appel d’un autre service.

La technologie utilisée pour implémenter ce service doit donc permettre d’étendre le message
initial, d’accéder à des sources d’information (appel ou requête) et d’enrichir le message. Un plus
est la possibilité de pouvoir gérer un cache de données afin d’optimiser ce traitement
d’enrichissement. On retrouve des technologies très proches de celles que nous allons détailler
pour le service de transformation.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

49
Transformation
Les informations en entrée et en sortie d’un service ont parfois besoin d’être adaptées, pour
cause de différence de modèles de données et/ou de conception (format pivot). Comme il est
préférable d’éviter d’effectuer ce type de transformation dans le service lui-même, la façade est
l’endroit idéal pour assurer cette fonction.

L’implémentation de la transformation au sein d’une façade peut évidemment prendre une


multitude de formes différentes, de l’implémentation basique (code) à l’utilisation d’un outil
spécialisé (EAI ou ETL) en passant par les langages dédiés (XSLT). L’avantage des outils
spécialisés est, non seulement, de proposer une abstraction des API de mapping et une
représentation graphique qui permet d’améliorer la productivité du développeur, mais aussi de
proposer des services intégrés de validation, de test, de gestion de versions.

Figure 28 - Exemple de transformation via un outil de mapping (SeeBeyond ICAN 5)

Dans les faits, cet avantage est souvent remis en cause car ce type d’outil présente un univers
restreint et le développeur se retrouve parfois dans des impasses dues à la nature fermée des
L4G.

Routage
Une façade peut faire office de routeur, c’est-à-dire qu’elle va transmettre la requête reçue au
service adéquat. Lorsque la correspondance entre la requête et le service cible est connu et figé
lors de la conception, on parle de routage statique. La façade joue alors simplement un rôle
d’aiguillage entre la demande et le service demandé. Ce pattern est communément utilisé en
conception d’architecture J2EE pour séparer la couche de présentation de la couche métier (EJB
Facade).
Lorsque la correspondance entre la demande et le service est déterminée à l’exécution, on parle
de routage dynamique. Pour effectuer ce routage, la façade étudie la demande et la transfère
vers le service adéquat. Il est fréquent d’externaliser les paramètres de routage dans une table
dédiée.

Le routage peut être :

• décentralisé : les règles de routage sont distribuées dans chaque application,

• centralisé : l’ensemble de règles de routage est centralisé dans la façade, les


applications n’ont pas connaissance de ces règles. Elles communiquent avec la façade qui
se charge du routage. Dans ce dernier cas, on dit que la façade joue le rôle de médiateur.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

50
Le routage peut être implémenté directement à base de code ou à l’aide d’un outil spécialisé
(DSL). Nous montrons, dans l’exemple suivant, un exemple de routage d’un message avec
SeeBeyond :

Figure 29 - Exemple de routage de message (SeeBeyond ICAN 5)

Ce type d’outil propose aussi une abstraction de la logique de routage, et, comme le montre la
Figure 30, il est maintenant possible d’accéder directement au code sous-jacent, du code Java
en l’occurrence. Les L4G s’ouvriraient-ils enfin ?

Figure 30 - Abstraction de la logique de routage (SeeBeyond ICAN 5)

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

51
Orchestration
L’orchestration dans la façade peut correspondre en fait à deux besoins distincts.
Le premier besoin, relativement aisé à couvrir, correspond à l’ordonnancement de tâches sans
état. Il s’agit de pouvoir contrôler le déroulement d’un certain nombre de tâches, comme l’appel
de services.

Figure 31 - Orchestration - Besoin d’ordonnancement

Le second type de besoin correspond à la gestion de processus avec état. L’orchestrateur doit
pouvoir se souvenir de l’état dans lequel se trouve le processus et disposer d’un mécanisme
permettant de retrouver la bonne instance du processus par rapport à un utilisateur donné
(concept de corrélation).

Figure 32 - Orchestration - Besoin de gestion de processus


Les langages traditionnels de programmation permettent de coder une telle logique à l’aide de
for, while, if ou autres switch / case. Si cette solution est envisageable pour implémenter le
besoin d’ordonnancement, elle s’avère rapidement ardue pour la gestion de processus
complexes dès lors que le nombre de tâches et leur imbrication s’intensifie.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

52
Les solutions d’infrastructure proposent une solution clé en main (ou presque) pour gérer ces
deux types de besoins. Certains produits permettent de gérer la complexité des processus en
proposant un mécanisme d’exploration des processus en allant du général au particulier (Drill
down).

Figure 33 - Fonctionnalité de Drill Down (BEA Weblogic Integration)


Enfin, comme le montre la Figure 34, la plupart de ces outils permettent de rendre le processus
actif, c’est-à-dire avec une gestion de la persistance des différents états des instances du
processus.

Figure 34 - Gestion de la persistance d’un processus (BEA Weblogic Integration)

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

53
Enfin, profitant de sa position préférentielle, l’orchestrateur est un lieu de passage où transitent
les données entre applications. C’est sur la base de ce constat que les éditeurs ont, ces derniers
temps, investi en complétant l’orchestrateur d’un module de monitoring de l’activité métier (BAM).
A ce sujet, ne soyez pas dupe ; si ce type de module apporte de la valeur ajoutée de par son
aspect intégré, dans un contexte de mise en œuvre d’une solution complète de gestion des
échanges, cela ne correspond qu’à du requêtage sur des données flux dont vous disposez peut-
être déjà dans votre application ou au niveau de votre socle d’échange.

Exemple de façade : réutilisation de services unitaires dans un contexte TP/Batch


Ce premier exemple met en exergue un des intérêts majeurs de la SOA, à savoir la réutilisation
de services, au travers d’un besoin classique : la réutilisation de traitements transactionnels pour
une utilisation à la fois unitaire (typiquement temps réel) et batch.

Nous nous plaçons dans le cadre du back-office d’un établissement bancaire. Ce back-office
implémente nombre de fonctionnalités spécifiques à des produits financiers (de l’ordre de
plusieurs dizaines) et de multiples fonctionnalités partagées (de l’ordre de plusieurs centaines).
L’ensemble de ces fonctionnalités est un ensemble de règles métier.

Les traitements sont implémentés en mode silo, c’est à dire que chaque chaîne de traitement
d’un produit financier ré-implémente des fonctionnalités métier communes. Par ailleurs, les
traitements des produits financiers sont nécessaires à plusieurs applications ainsi qu’à des
opérateurs humains. La chaîne de traitement d’un même produit financier est donc implémentée
pour chacun de ses utilisateurs (applications et opérateur). Il y a une redondance à la fois
verticale et horizontale.

En regard de ces enjeux, la mise en œuvre d’une architecture SOA apparaît comme une réponse
stratégique. Celle-ci est engagée dans le cadre d’une refonte du back-office et a pour objectif de :

• mutualiser les fonctionnalités partagées,


• standardiser l’accès aux fonctionnalités partagées.

L’architecture mise en œuvre dans le cadre de ce projet est typique d’une architecture orientée
services sans pour autant utiliser une quelconque technologie de type Web Service. L’accent est
mis sur la réutilisation et non sur l’interopérabilité car l’environnement est monotechnologie.
L’architecture s’articule autour d’un ensemble de services PL/SQL organisés en hiérarchie à trois
niveaux :

1. Couche de services métier dédiés au batch : cette couche est constituée de services
chacun dédié à un produit financier. Le nombre de ces services est de l’ordre d’une
cinquantaine. Ces services sont standardisés sur un modèle commun constitué de 3
actions : validation, traitement et persistance. Ces actions correspondent chacune à un
appel de service standardisé du niveau inférieur.

2. Couche de services métier standardisés : cette couche est constituée de services


standardisés autour de 3 fonctions : validation, traitement et persistance. Chaque
produit financier dispose de ces 3 services. Ces services sont appelés à la fois par les
services dédiés au batch et par les opérateurs et applications. Ils ont pour usage de
traiter les produits financiers en orchestrant des services unitaires du niveau inférieur.

3. Couche de services unitaires : cette couche est la seule à implémenter de véritables


traitements. Elle est constituée à la fois de règles métier (ex. calculs, contrôles) et de
fonctionnalités techniques (ex. persistance). Ces services sont appelés par les services
métier standardisés.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

54
Figure 35 - Hiérarchie de services en back-office

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

55
La Figure 36 montre un exemple d’implémentation de la façade (couche d’intégration) avec
TIBCO BusinessWorks.

Figure 36 - Exemple d’implémentation d’une façade avec TIBCO

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

56
4.1.3 Le service de localisation
Le service de localisation est un élément optionnel d’une architecture orientée services. Il rend
plus souple l’accès aux services, puisque de cette manière les consommateurs n’ont pas besoin
de savoir où se trouvent physiquement les services. Il suffit de le demander au service de
localisation qui se charge d’interroger un référentiel, l’annuaire de services, et renvoie la
référence sur le service recherché ainsi que les méta-données associées.

Figure 37 - Pattern service de localisation

Attention ! Nous avons dit que la présence du service de localisation est très utile mais
néanmoins pas indispensable. Ce pattern introduit une couche d’abstraction supplémentaire qui,
évidemment, aura des impacts, non seulement sur les performances, mais aussi sur la qualité
de service du système (notion de single point of failure). Il est donc possible de ne pas utiliser
un service de localisation et d’effectuer un couplage plus fort entre consommateurs et
fournisseurs si certaines conditions comme la stabilité de la localisation du service sont réunies.
Il existe différentes stratégies de localisation d’un service :

• Centralisée : le service de localisation est unique et chaque application doit s’y référer.

• Distribuée : afin d’éviter un point de contention important (SPOF), il est possible de


distribuer le service de localisation et d’utiliser des mécanismes de synchronisation du
référentiel.

• Locale : chaque application possède son propre service de localisation.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

57
Il est possible d’implémenter ce service sous différentes formes. Par exemple, il pourra prendre
la forme d’un simple objet responsable de la localisation des services. Cette solution est adaptée
à l’interaction avec peu de services dans un contexte relativement stable et technologiquement
homogène. Elle est facile à mettre en œuvre mais demeure peu souple et s’avère difficilement
gérable lorsque le nombre de services augmente ou encore quand la localisation des services
change fréquemment.

Un second type d’implémentation consiste à avoir recours à un outil dédié, tel un serveur
d’annuaire de services. La référence en la matière est UDDI. Ce type d’implémentation offre
souvent des fonctionnalités à valeur ajoutée telles que :

• Un mécanisme d’enregistrement (dynamique ou statique)

• Une gestion de la taxonomie de services

• Une gestion intelligente du cache

• Une IHM de recherche

• Une console d’administration

• Un mécanisme de notification du changement

• Une fonction de génération automatique d’identificateur de services

Cependant, la mise en œuvre de ce type de solution est encore complexe et doit nécessiter un
important travail préparatoire :

• Définir la politique de référencement des services : cycle de référencement de tout ou


partie des services

• Définir l’organisation de classification : taxonomie des services, règles de nommage,


langue utilisée

• Définir le processus de publication : manuel ou automatisé, workflow de validation,


synchronisation vers certains référentiels, impacts sur le processus de provisioning de
l’entreprise

• Définir la politique de sécurisation : authentification, habilitation, non répudiation,


confidentialité

• Définir les interfaces d’interactions : console d’administration, interface utilisateur de


recherche

Partager ou dupliquer le code ?

Effectivement, il est important de bien comprendre les incidences de ces deux types de
réutilisation de code car la mise à disposition d’un traitement réutilisable sous la forme d’un
service partagé et centralisé aura des impacts importants, à la fois sur le service lui-même
mais aussi sur les applications utilisatrices, par rapport à la mise à disposition de ce même
traitement sous une forme dupliquée.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

58
Services dupliqués Services partagés
Le service est dupliqué dans chaque application Le service est déployé de manière autonome et
utilisatrice. L’équivalent du bon vieux « copier - est accessible par plusieurs applications via une
coller » ! interface commune.

L’accessibilité au service est limitée à chaque Le service est accessible par plusieurs blocs
bloc applicatif. applicatifs.

Ce modèle est bien adapté aux services qui ne Ce modèle est bien adapté aux services gérant
gèrent pas de données partagées. des données partagées (exemple : service
d’accès à un référentiel client partagé).
Description

•Facilité de déploiement •Unicité du code du service

•Possibilité de migration transitoire, •Facilité de maintenance du service (pas des


application par application, en cas de applications utilisatrices) tant qu’on ne
montée de version de service touche pas au contrat de service
Avantages

•Peu d’impact organisationnel

•SLA (service et application) plus facile à


garantir

•Simplification des tests d’intégration

•Multiplication potentielle des •Déploiement et migration complexe


implémentations du même service (synchronisation nécessaire)

•Multiplication des mises à jour lors de la •Difficulté des tests d’intégration


montée de version du service
Inconvénients

•Complexité de la solution
•Gestion de configuration complexe (version
du service utilisée par application) •Dégradation du SLA des applications
composites

•Difficulté d’identification des responsables


du service (en phase projet et opérationnelle)

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

59
4.2 Echanger

4.2.1 Le point à point

Ce pattern consiste à faire communiquer fournisseurs et consommateurs de services en utilisant


un mode d’adressage explicite (ex. adresse IP, URL). Le consommateur est généralement à
l’initiative de la communication et se doit donc de connaître (ou de trouver) la localisation du
fournisseur de services désiré. Ainsi, la mise en œuvre d’un médiateur technique, pour le
transport et l’acheminement de la demande, ne préjuge pas du mode d’adressage. La
communication demeure du point à point.

Effectuer une communication en point à point ne présuppose pas non plus du synchronisme de
la communication. Ainsi une communication en point à point peut très bien s’effectuer sur un
mode synchrone (ex. appel de fonctions à distance par RPC, Web Service ou RMI) ou sur un
mode asynchrone (ex. utilisation de technologie de messaging, traitement par lot par FTP).

Figure 38 - Pattern point à point

Le point à point a longtemps été la bête noire de générations d’urbanistes traumatisés par le
syndrome du « plat de spaghettis » popularisé par le Gartner. Or le spaghetti est une réalité.
Les relations bilatérales entre services ou départements de l’entreprise sont la norme et
demeureront ainsi. Invoquer la centralisation systématique est d’autant plus hérétique que l’on
sait bien qu’un environnement multilatéral n’assurera pas le même niveau de réactivité qu’un lien
bilatéral, dont le métier est très souvent l’instigateur (ex. liens Back-office <-> Comptabilité).
Plutôt que de nier ce fait, intéressons-nous à la préservation d’un bon niveau de productivité
dans la maintenance de ces liens.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

60
4.2.2 Le publish and subscribe
Par opposition à la communication en point à point, le pattern publish and subscribe, littéralement
publier et souscrire, répond à des besoins de communication « 1 vers n » via un mécanisme de
publication de données et de gestion d’abonnements au service. Il permet à des services de
publier des informations à un nombre a priori inconnu d’abonnés. Les services sur abonnement
(publication de cotations boursières, d’actualités, de lettres d’information, …) sont de bons
candidats. Concrètement, les consommateurs intéressés doivent s’abonner au service désiré
afin de recevoir chaque publication de ce dernier.

Figure 39 - Pattern Publish / Subscribe

Ce pattern propose un mode communication en couplage lâche entre les consommateurs et les
fournisseurs. Malgré cela, son utilisation dans un contexte SOA est finalement assez restreinte
car les protocoles mis en jeux sont soit encore propriétaires (ex. Tibco Rdv), soit pas de nature
interopérable (ex. l’implémentation JMS de Sonic n’a rien à voir avec celle de BEA ou IBM). Ce
sont donc des solutions à l’échelle d’une application et non pas d’une entreprise.

Ce type de communication est asynchrone et s’implémente souvent par la mise en œuvre d’un
médiateur (hub ou bus) sans a priori sur les protocoles techniques utilisés.

ESB vs. EAI

Historiquement, les outils d’EAI se sont imposés comme des médiateurs permettant d’intégrer
des applications de manière non intrusive. De part leur position privilégiée et l’existence des
fonctions classiques d’intégration (connectivité, routage, transformation), ils se sont
progressivement transformés en producteurs de services.

Aujourd’hui, les outils d’EAI sont entrés en concurrence avec le petit nouveau : l’ESB ou
Enterprise Services Bus qui, comme son nom l’indique, se propose de mettre à disposition de
l’entreprise des services partagés sur un bus. Les pure player ESB sont des éditeurs issus de
la « bulle Internet » et précurseurs des technologies Web Services. Même si les coûts
d’investissement de telles solutions semblent moins importants que ceux de solutions EAI, il

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

61
n’en demeure pas moins vrai que les ESB n’apportent pas grand chose de nouveau dans à un
paysage déjà bien encombré de middleware.

Finalement, les vrais concurrents des EAI demeurent les plateformes d’applications
d’entreprise7 proposées par les BEA, IBM, Microsoft et consorts. Celles-ci réunissent des
fonctions d’exécution et d’intégration autour d’un serveur d’applications et de technologies
connues et maîtrisées par les équipes de développement et de production.

4.3 Tester

4.3.1 Fédération des plateformes d’homologation


Ce pattern concerne la phase d’homologation qui a pour but de valider un produit fini. Cette
phase est capitale puisqu’elle est la dernière étape avant la mise en production. Cette activité
arrive donc bien après les tests unitaires et les tests d’intégration effectués lors des phases de
développement par l’équipe projet. La nature des tests est variable en fonction du contexte et il
est classique d’effectuer des tests de compatibilité système, de recette fonctionnelle et de
validation de la qualité de service (charge, disponibilité, …).

Cette activité, de part sa nature critique, doit être menée avec une extrême rigueur. Il est donc
nécessaire de disposer d’un environnement d’homologation le plus proche possible de celui de
production tant d’un point de vue de l’infrastructure matérielle et logicielle, que du contexte
d’utilisation, c’est-à-dire des données de tests représentatives de la réalité. Elle est généralement
réalisée par une équipe mixte : les membres représentant la maîtrise d’ouvrage vont s’attacher
à l’aspect fonctionnel tandis que les experts vont s’attacher à l’aspect technique, c’est-à-dire au
comportement vis-à-vis de l’infrastructure cible et des systèmes connexes. Ce dernier point met
en évidence le plus gros écueil : l’homologation d’un système ayant des interactions avec
d’autres systèmes. Dans l’idéal, il serait nécessaire de disposer de ces mêmes systèmes pour
effectuer la recette de notre application. Or, dans bien des situations, cela n’est pas possible pour
des raisons techniques, organisationnelles, ou tout simplement de coûts. Dans ce cas, des
solutions de bouchonnage sont classiquement mises en œuvre pour simuler les applications.

Et c’est là que le bât blesse !

Très souvent, c’est le consommateur qui produit ses propres bouchons et ses propres jeux de
tests. Il est fréquent que ces données ne soient pas représentatives de la réalité (qui n’a jamais
fait des jeux de données avec des valeurs du style « titi, toto, tata » ?). Et lorsque plusieurs
consommateurs utilisent le même service, que font-ils ? Et bien, chacun implémente ses propres
bouchons avec ses propres données. Enfin, ces mêmes bouchons sont recréés, au cours du
temps, lors de la validation d’une nouvelle version.

Donc, résumons, non seulement cela ne semble pas très efficace, mais surtout cela coûte cher.
Ne serait-il pas intéressant de fédérer les différentes équipes d’homologation par des jeux de
données de tests cohérents ?

Le pattern « fédération d’homologation » résout ce problème en définissant les principes


directeurs suivants.

L’équipe d’homologation du producteur de service va être responsable de ses propres bouchons


utilisés lors des tests d’homologation des consommateurs, qui ont lieu de manière

7 : EAP : Entreprise Application Platform

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

62
désynchronisée8. La production du jeu de tests par le producteur garantit la cohérence du jeu de
données dans le temps, et surtout sa propagation dans les différentes plateformes
d’homologation. Lors de la signature du contrat de service, le producteur dialogue avec les
consommateurs pour définir ou vérifier la complétude de ce jeu de données. Il fournit une
implémentation du bouchon, qui peut dépendre du média dont voici les principales catégories :

• Service de type intéractif : typiquement Web Services / RPC, le producteur fournit le


bouchon, qui consiste en un serveur Web répondant en statique à des requêtes pré-
paramétrées.

• Service de type envoi/réception de message au fil de l’eau : le producteur fournit


l’ensemble des messages constituant son jeu de tests grandeur nature dans un fichier. Le
consommateur se charge d’injecter les messages dans son système à l’aide d’un
injecteur.

• Service batch : le producteur fournit un jeu de données sous forme de fichier ou de table
de base de données selon le type de média. Le consommateur se charge de les intégrer
dans son système.

Prenons un exemple concret : nous nous plaçons dans le contexte d’un établissement bancaire
où quatre systèmes interagissent les uns avec les autres.

Figure 40 - Exemple de fédération de plateformes d’homologation

8 : Rappel : le SI n’est pas une application, il est rare de voir plusieurs applications synchroniser leur mise en production

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

63
Le « référentiel tiers » irrigue la « Gestion des crédits », la « Fidélité / Analyse » et la «
Gestion des comptes courants » via un service batch. La « Gestion des crédits » met à jour la
note du client dans le « Référentiel tiers » via un message MQ Series émis après chaque
proposition de crédit. Elle propose aussi un service de notification d’ouverture de contrat au
système « Fidélité et Analyse » via un autre message. Le système de « Fidélité et d’analyse »
propose lui un service interactif permettant de consulter un coefficient de fidélité et un taux
d’attrition, qui est notamment utilisé dans l’outil de « Gestion des comptes courants » et qui
représente l’essentiel du poste de travail du collaborateur en agence.

En appliquant les principes du pattern, le premier fournisseur à produire un jeu de tests


d’homologation est le référentiel Tiers, qui va produire par exemple un fichier client d’une
centaine d’enregistrements, correspondant au panel complet de clients : majeur, mineur, en
défaut, professionnel, etc. Ce fichier unique va irriguer les trois consommateurs, dont les
homologateurs vont s’approprier durablement les données (Dupond est le père de famille CSP+,
Durand est le mineur sous tutelle, etc.).

Sur la base de ce fichier, le producteur « Gestion des crédits » va effectuer son homologation,
et en tant que producteur du service de mise à jour de la note de scoring, va lui aussi produire
un jeu de tests exploitant le même périmètre de donnée. En effet, l’homologation de l’octroi de
crédit aura testé le cas du mineur, le cas du CSP+, etc. puis produit son jeu de tests sur cette
base (mise à jour de la note d’une tutelle de mineur, mise à jour de la note d’un CSP+, etc.). Le
puzzle s’assemble ? Eh bien terminez cet exemple à titre d’exercice !

Comme nous venons de le voir, ce pattern est adapté à des situations où un ensemble de
services forme une chaîne de services interconnectés. La fédération des plateformes
d’homologation les unes avec les autres se fait naturellement par la contractualisation des
bouchons et des jeux de données et l’assurance de leur cohérence dans le temps car il est clair
que les bouchons évolueront avec le temps. L’homologation de la nouvelle fonctionnalité du bloc
X va nécessiter l’enrichissement des tests existant : en longueur (nouveaux cas de test, par
exemple client de type Agriculteur) ou en largeur (nouveaux attributs sur des tiers par exemple).

Ce pattern va donc participer à l’amélioration de la productivité générale du système


d’information, sachant qu’elle est bien plus préoccupante dans ces phases en aval (qui
n’intéressent personne, malgré l’accroissement continu de la taille des systèmes d’information)
que dans les phases en amont de conception ou de développement.

4.4 Sécuriser

L’objectif de cette section est de se focaliser sur la gestion de la sécurité au niveau des services
d’une SOA. Nous nous intéressons en particulier aux fonctionnalités d’authentification et
d’habilitation (nous parlons ici des habilitations d’accès aux services et aux opérations, les
habilitations plus fines sont bien évidemment toujours gérées au niveau des traitements). Nous
n’aborderons pas, en revanche, les architectures de sécurité autour des problématiques de
SSO9, de gestion des certificats ou encore de la signature électronique.

La manière qui peut sembler la plus simple de sécuriser un service consiste à implémenter les
fonctions de sécurité dans le service lui-même en le dotant par exemple de son propre référentiel
de sécurité. Il s’agirait alors du pattern de base, néanmoins, ce n’est pas ce que nous
recommandons pour des raisons évidentes de multiplication des référentiels de sécurité. Nous
présentons donc, par la suite, trois patterns de sécurité fondés sur la mutualisation des fonctions
de sécurité.

9 : Single Sign On : mécanisme d’authentification unique

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

64
Dans bien des cas, les patterns de sécurité sont grandement dépendants de l’infrastructure de
sécurité du SI existant et c’est donc l’infrastructure en place qui va imposer, dans la majorité des
cas, l’implémentation à effectuer.

4.4.1 Zone implicite de confiance


La première manière d’implémenter la sécurité au sein d’une SOA, et aussi assurément la plus
simple, consiste à ne pas gérer la sécurité au niveau des services mais en amont. Dans ce
modèle, les services sont placés dans une zone de sécurité dont l’accès est contrôlé. Du point
de vue de l’implémentation, cette zone peut être délimitée à différents niveaux ; au niveau
réseau par du filtrage IP/port avec un routeur filtrant, au niveau session par l’utilisation du
protocole SSL ou encore au niveau de la couche applicative par un portail ou un reverse proxy.
Dans tous ces cas, cela consiste, ni plus ni moins, à définir différents niveaux de zones
militarisées et démilitarisées.
Les différentes applications s’échangeant des services sont donc réunies dans cette zone
implicite de confiance, et vont y interagir en faisant confiance aux contrôles de sécurité effectués
par chacun. Ainsi, les applications ne sont pas nécessairement connectées au même référentiel
de sécurité, ce qui est malheureusement la norme dans les grands systèmes d’information. Si
elles le sont, il est possible de propager les informations de type user_ID, pour effectuer
d’éventuels contrôles d’habilitation, sans ré-authentifier l’appelant.

La Figure 41 montre l’exemple d’un utilisateur qui accède à une page Web utilisant trois Web
Services. La première étape consiste en l’authentification de l’utilisateur auprès de l’application
fournissant la page Web, celui-ci fournit un couple identifiant / mot de passe qui est vérifié auprès
du référentiel de sécurité. L’application peut ensuite accéder aux trois Web Services en
fournissant uniquement l’identifiant de l’utilisateur mais pas le mot de passe. De cette manière
les Web Services font implicitement confiance à l’application (aucune nouvelle authentification de
l’utilisateur n’est effectuée par les Web Services). Lorsque les trois Web Services ont retourné
leur résultat, l’application peut composer la page Web finale qui sera délivrée à l’utilisateur.

Figure 41 - Zone implicite de confiance

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

65
4.4.2 Zone explicite de confiance
Ce deuxième pattern consiste à réutiliser au niveau des services un référentiel de sécurité
externalisé. Lorsqu’un consommateur demande l’accès à un service, le mécanisme de sécurité
est sollicité par le service afin de déterminer l’identification et l’habilitation du consommateur. Un
exemple classique d’implémentation de ce pattern est l’utilisation d’un serveur de sécurité
centralisé.
Ce pattern diffère de la zone de confiance implicite du fait que la sollicitation du serveur de
sécurité demeure à l’initiative du service. Ainsi, et même si elle demeure minime, une couche de
sécurité est donc implémentée au sein des services.

La zone explicite de confiance est particulièrement adaptée à des services de grosse granularité
participant à la politique d’interopérabilité. En effet, ceux-ci sont, par nature, transverses au
système d’information et l’utilisation de la zone implicite de confiance peut être délicate. La zone
explicite va, au contraire, permettre de développer ces services transverses indépendamment
d’un frontal d’authentification et ne pas nécessiter de mécanisme de cloisonnement.

Figure 42 - Zone explicite de confiance (exemple du serveur centralisé)

4.4.3 Fédération de l’identité


Popularisé par les standards concurrents Liberty Alliance et WS-Federation, le pattern de la
fédération permet de sécuriser des bouquets de service dans un espace ouvert, par exemple
celui de l’administration électronique faite de services produits par les administrations centrales,
les collectivités territoriales ou encore les organismes sociaux.

Ce pattern consiste en l’utilisation d’un ou plusieurs fournisseurs d’identités (IdP pour identity
provider) qui vont être en charge de gérer une table anonyme de références croisées. Ainsi
lorsque le consommateur de services dispose de plusieurs identités auprès de plusieurs
fournisseurs de services (SP pour Service Provider), il peut décider de fédérer ses identités
auprès d’un fournisseur d’identité. Sont alors créées des clés de jointure anonymes (différentes

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

66
des identifiants du consommateur) dont la table de correspondance appartient au fournisseur
d’identité (cf. Figure 43). La table de jointure anonyme va permettre d’assurer le service
d’authentification unifiée (SSO) tout en ne faisant pas transiter les identifiants des différents
fournisseurs de services. De cette manière aucun fournisseur de services ou d’identités, ne
pourra effectuer la correspondance entre les différentes identités d’un même utilisateur.

Ce pattern repose sur les principes suivants :

• Les applications participant à la fédération peuvent toutes posséder leur propre


gestionnaire de sécurité, que celui-ci soit interne (IdP propre à l’application) ou externalisé
(IdP partagé).

• En préalable de l’acte de fédération d’identité par l’utilisateur, les fournisseurs d’identités


doivent contractualiser ensemble pour déclarer qu’ils font partie de la même fédération,
c’est-à-dire d’un espace de confiance homogène.

• La fédération des identités d’un consommateur est TOUJOURS à l’initiative de celui-ci,


c’est donc l’utilisateur qui choisit explicitement de réconcilier certaines de ses différentes
identités et non un serveur de sécurité centralisé qui le ferait automatiquement.

• L’anonymat des consommateurs de services est respecté. Seul le consommateur


possède la table de correspondance complète entre ses différentes identités, les
fournisseurs de service et d’identité ne sont pas capables de connaître l’ensemble des
identités d’un consommateur donné.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

67
Figure 43 - SSO par identité fédérée

La fédération de l’identité est une réponse à des besoins concrets des usagers de services
distribués, avec lesquels ils souhaiteraient partager sélectivement des informations. Les deux
principales familles d’acteurs concernés sont les sites participant à l’administration électronique
et les sites fédérés par un portail généraliste avec, notamment, le concept de coffre-fort
électronique dans lequel des données privatives peuvent être sélectivement distribuées aux
partenaires du portail, par exemple des coordonnées de paiement.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

68
Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

69
5. SOA et les Web Services
Ils sont partout ! Tout le monde en parle, tout le monde semble les avoir adoptés, à se demander
comment nous faisions avant cette sacro-sainte invention !
Il paraissait donc difficilement envisageable d’écrire un Livre Blanc sur la SOA sans parler des
Web Services, tant ils sont omniprésents.

5.1 Qu’est ce qu’un Web Service ?

Que dit le W3C à propos des Web Services ?

« A Web Service is a software application identified by a URI, whose interfaces and bindings are
capable of being defined, described, and discovered as XML artifacts. A Web Service support
direct interactions with other software agents using XML-based messages exchanged via
Internet based protocol ».

Facile, n’est-ce pas ?

Cette définition implique les propriétés suivantes :

• un Web Service est autodescriptif et fournit une interface qui sert de contrat entre le
consommateur et le fournisseur,

• un Web Service peut être publié, découvert et invoqué par Internet,

• les Web Services interopèrent aisément, c’est-à-dire qu’ils communiquent par des
protocoles indépendants des langages de programmation et des plateformes d’exécution,

• enfin les Web Services sont extensibles : chacun peut adjoindre ses propres données,
protocoles ou mécanismes propriétaires.

5.2 SOA n’est pas WSOA !

Par définition, la WSOA est simplement une architecture orientée services fondée exclusivement
sur les technologies Web Services. En résumé, WSOA = SOA + Web Services.

Dans les faits, cette proposition n’a pas véritablement de sens, en tout cas, pas pour l’instant. Il
ne suffit pas de wrapper tout traitement en Web Service pour obtenir une SOA. Les Web Services
participent à l’approche SOA mais une architecture SOA n’est pas fondée exclusivement sur les
Web Services. Alors pourquoi choisir de s’orienter exclusivement vers les Web Services ?
Pourquoi vouloir se passer des autres types de solutions, d’autant que la maturité et la
complétude des Web Services ne sont pas atteintes ?

Les Web Services ont bien des qualités intrinsèques indéniables. Ils ont l’ambition de réussir là
où CORBA, RMI, DCOM ont récemment échoué, c’est-à-dire apporter une solution à
l’interopérabilité entre composants sur un réseau mondial. Mais si l’on n’est pas confronté à un
problème d’interopérabilité, a-t-on vraiment besoin de la technologie des Web Services ?

Enfin, la WSOA ne propose pas plus que la SOA de cadre structurant qui permette d’obtenir une
certaine cohérence. Celui-ci est le résultat d’une démarche d’architecture et de l’application de
patterns.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

70
5.3 De la maturité des standards Web Service

Tout d’abord, une petite parenthèse sur le passionnant monde de l’informatique. Passionnant
parce qu’il est en perpétuelle évolution, parce que nous ne pouvons pas imaginer ses limites …
et tellement à part ! Jamais aucun autre secteur d’activité ne se risquerait à de tels
investissements sur la base d’aussi peu de certitudes. Il est fréquent de voir des projets démarrer
avec de nombreuses hypothèses, supputations ou risques majeurs. Certains éditeurs conseillent
même de démarrer des projets stratégiques sur la base d’un outil fraîchement sorti des
laboratoires de recherche parce qu’il implémente telle spécification toujours en cours de rédaction. On
croit rêver !

Alors, pourquoi les éditeurs de logiciels se sont-ils lancés, depuis quelques années seulement,
dans la course aux standards ? Pas pour la gloire, mais simplement parce qu’ils ont bien
compris qu’en étant à l’origine de la définition d’un standard, leurs produits pourraient y trouver
un avantage concurrentiel. Voilà ce qui pousse les éditeurs à vous encourager vers les nouveaux
standards sous le prétexte fallacieux que l’adoption de ces derniers va vous apporter « une
indépendance vis-à-vis de l’éditeur ». Les vrais bénéficiaires, ce sont eux puisqu’ils peuvent
développer leurs solutions et les rendre disponibles sur plusieurs plateformes à moindre coût.
Cette indépendance contribue-t-elle fondamentalement à rendre votre système meilleur et plus
performant ? A notre avis, le véritable intérêt des standards pour l’entreprise se trouve dans le
renforcement de la pérennité de la solution et la capitalisation du savoir et du savoir-faire.

Qu’en est-il dans la galaxie des Web Services ? La situation est confuse, voire chaotique. Les
standards matures des Web Services adressent des problématiques simples d’interopérabilité et
sont souvent incomplets pour supporter une SOA digne de ce nom (performances, fiabilité,
sécurité, orchestration, …). Pour l’instant, il faut combler ces manques par de l’intégration d’outils
et du développement spécifique. Heureusement, voilà que la deuxième génération arrive pour
apporter des réponses à toutes les questions soulevées par la première.

Or, que voit on ? Les spécifications fleurissent. Une proposition de nouveau standard WS est
annoncée quasiment chaque jour de l’année. Et en plus un bon nombre sont concurrentes, le
plus souvent comme conséquences de conflits d’intérêt et de luttes d’influences plutôt que de
réelles divergences d’implémentation. La guerre des spécifications est en marche. Sur le champ
de bataille, Il est d’ailleurs amusant de constater des alliances impensables entre clans ennemis
que l’on n’aurait pas soupçonnées (IBM et Microsoft par exemple).

Difficile de savoir qui va survivre ou, pour reprendre un langage moins guerrier, quelles seront
les spécifications élues au Panthéon des Web Services. Le chemin est long et s’accomplit parfois
dans la douleur, à l’instar de BPEL4WS et WS-Security.

Le véritable souffle d’optimisme vient d’initiatives comme celles du WS-I, supposée mettre de
l’ordre dans la jungle des standards de Web Services, même si pour l’instant, son action se limite
à la normalisation des bases des Web Services (Basic Profile). Ironique tout de même de
constater qu’il existe déjà des organismes dédiés à la standardisation des standards.

Les Web Services ont donc encore un long chemin avant de sortir de leur crise d’adolescence et
d’atteindre la plénitude : être la technologie standard de nos Systèmes d’Information. N’oublions
pas que la stabilité est une conséquence logique de la maturité, fruit de l’expérience.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

71
5.4 Le corpus de standards Web Services

Les fondations des Web Services (triptyque SOAP/WSDL/UDDI) ne couvrent pas un certain
nombre de besoins tels la gestion de contexte transactionnel, la sécurité, l’orchestration des
services, la fiabilité des échanges, la gestion des attachements ou encore les politiques de
gestion de services.

Une deuxième génération de spécifications est donc en gestation pour adresser ces sujets. Le
nom de la plupart de ces spécifications commençant par « WS- », par abus de langage, on
utilise souvent « WS-* » pour y faire référence. Comme nous l’avons exprimé précédemment,
cette deuxième génération est à l’origine d’une multitude de propositions de nouveaux standards
et il est difficile de s’y retrouver.

Nous vous proposons la vue, figure 44, produite en date de début 2005, qui synthétise les
spécifications majeures. Cette vue n’est évidemment pas exhaustive et illustre l’approche
historique puisqu’on distingue les deux générations de spécifications : d’une part, les fondations
des Web Services, et d’autre part, la panoplie de spécifications de deuxième génération.

5.5 WS-I, l’organisme de standardisation des standards

Bien que ne faisant pas partie, au sens strict du terme, du noyau des spécifications Web
Services, WS-I10 et ses Basic Profiles méritent d’être présentés ici. WS-I est un consortium
composé d’acteurs majeurs de l’industrie du génie logiciel, parmi lesquels BEA, HP, IBM,
Microsoft, Oracle, SAP et SUN.

WS-I s’est fixé pour objectif de faciliter l’adoption des Web Services en s’attachant à rationaliser
et à améliorer l’interopérabilité entre les différentes spécifications.

A cette fin, WS-I livre gratuitement un framework d’interopérabilité :

• des Profiles, sélection de spécifications totalement compatibles entre elles, accompagnées


de guide d’implémentation. Le premier Profile émis est le WS-Basic Profile qui porte
principalement sur la première génération de Web Services et les briques XML sous-
jacentes11,

• des cas d’utilisation et des exemples d’applications, avec le code source associé,

• des outils de test utilisés pour analyser les interactions entre Web Services et vérifier leurs
conformités aux guides contenus dans les Profiles.

Sous l’égide de WS-I, IBM et Microsoft organisent des démonstrations techniques montrant le
bon fonctionnement de l’interopérabilité de leurs solutions.

Enfin, dans la nébuleuse des spécifications de Web Services, la sélection de spécifications et les
livrables de WS-I s’avèrent utiles pour l’architecte ou le développeur car avoir une vision claire
des spécifications de Web Services est parfois loin d’être simple.

10 : Appelé aussi WS-Interoperability. Voir le site http://ws-i.org/

11 : SOAP, HTTP, XML, XML Namespaces, XML Schema, WSDL, UDDI, HTTP/TLS, SSL, X509.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

72
Figure 44 - Les principaux protocoles des Web Services

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

73
Bien débuter avec les Web Services

Voici quelques conseils pour bien commencer avec les Web Services :

• Commencer à concevoir des services mais pas forcément des Web Services

• Faire le tri dans la multitude de standards et établir sa propre norme technologique

• Suivre de près l’évolution des standards pertinents pour votre entreprise

• Se tenir au courant des éventuelles incompatibilités entre les différentes


implémentations et agir en conséquence

• Préférer les implémentations de spécifications retenues par des organismes de


normalisation comme le WS-I

• Ne pas croire que la standardisation va diminuer sensiblement la facture

• Eviter le « chaos des Web Services » c’est-à-dire la prolifération non contrôlée de


Web Services du fait de la facilité de développement apportée par les outils actuels

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

74
6. Conclusion
Le lecteur l’aura remarqué, notre objectif a été tout au long de cet ouvrage de démystifier le
concept d’architecture orientée services.

Si la SOA ne peut décemment être qualifiée de révolution de l’informatique, nous avons toutefois
montré que la mise en œuvre d’une architecture orientée services apporte de la valeur ajoutée
à la fois au niveau des applications en contribuant à la politique de la réutilisation et au niveau
du système d’information en participant à la politique de l’interopérabilité. Au travers de ces deux
volets, la SOA contribue aux objectifs d’entreprise en apportant des gains à différents niveaux :
productivité, économie d’échelle, réactivité et profitabilité. Cependant, il convient de garder à
l’esprit que ces gains sont loin d’être automatiques et systématiques. En effet, l’exposition de
services et la garantie du contrat de service demeurent des tâches à la fois complexes et
coûteuses.

Par ailleurs, il nous semble essentiel de rappeler que SOA n’est pas WSOA ! En d’autres
termes, ce n’est pas parce que l’on a développé quelques Web Services que l’on fait de la SOA.
Soyons clairs : on peut très bien faire de la SOA sans Web Services. La SOA est une démarche
d’architecture et pas une technologie. Nous allons même plus loin, la SOA n’est qu’un élément
d’architecture parmi d’autres, en d’autres termes « le tout SOA ne doit en aucun cas être une
quête ». Il s’agit donc d’adopter une démarche d’architecture globale au sein de laquelle la SOA
va demeurer complémentaire d’autres modèles d’architecture comme la DOA (Data Oriented
Architecture).

La démarche SOA que nous adoptons correspond donc à notre démarche d’architecture globale.
Celle-ci trouve sa spécificité dans l’utilisation de patterns SOA tant du point de vue fonctionnel,
technique qu’organisationnel. Il s’agit de construire sa propre SOA au fil du temps et de
l’apparition des besoins, projet par projet, et donc d’adopter une démarche avant tout
progressive, mais capitalisant sur les meilleures pratiques.

Sur le plan de l’outillage, insistons sur l’utopie de trouver l’outil magique. Actuellement, deux
familles d’outils complémentaires rayonnent sur les architectures orientées services. D’un côté,
les éditeurs de serveurs d’applications se positionnent depuis de nombreuses années sur le volet
de la réutilisation de services alors que les éditeurs de suites d’intégration adressent le volet de
l’interopérabilité. Néanmoins, la frontière vise à s’amenuiser tendanciellement avec l’émergence
des offres de type EAP (Enterprise Application Platform) qui apparaissent au confluent de l’EAI
et des serveurs d’applications. Parallèlement à ce phénomène de concentration dans des
Progiciels d’Infrastructure Intégrés, se joue la bataille des standards et leur intégration
(progressive) dans ces suites.

WS-I a mis quelques années à standardiser du middleware simple, il mettra encore plusieurs
années à produire une pile universelle adressant les besoins d’entreprise tels la garantie de
livraison, la sécurité, la gestion des petits et gros volumes, etc. Nous sommes convaincus que
l’histoire pathétique de DCE ou CORBA ne se reproduira pas avec cette nième tentative de
standardisation grâce au phénomène Open Source, véritable bras armé du standard, et qui les
imposera, même si des éditeurs traditionnels pourraient être tentés d’y déroger.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

75
7. A propos d’OCTO Technology
www.octo.com
OCTO Technology est le cabinet de Conseil en Architecture de Systèmes d’Information du
Groupe Aubay. Depuis sa création en 1998, OCTO Technology publie le fruit de ses expériences
et de ses recherches sous forme de Livres Blancs. Ils sont diffusés et diffusables gratuitement.

L’idée des fondateurs d’OCTO Technology est de se consacrer exclusivement au métier


d’architecte, et de l’exercer en toute indépendance, en équipes projet, et en fédérant des
compétences.

Son positionnement, de la stratégie technologique à la conception et la mise en oeuvre de


solutions innovantes, est principalement orienté vers les grands comptes pour :

• Les assister dans le pilotage de leur système d’information

• Structurer et sécuriser leurs projets par la mise en place de Bureaux d’Architecture


opérationnels

• Tirer le meilleur parti des Technologies de l’Information et accélérer leur mise en oeuvre,
grâce à une forte expertise technique

L’activité d’OCTO Technology se structure en quatre grandes lignes métier :

• Architecture de Systèmes d’Information

• Architecture d’Intégration

• Architecture d’Applications

• Architecture de Sécurité

Enfin, OCTO Technology fonde sa stratégie sur une forte politique de R&D. Les résultats des
recherches et développements d’OCTO Technology donnent régulièrement lieu à des séminaires
et conférences au Cigref, Microsoft DevDays, Gartner Group, Clusif, EBG, Benchmark Group,
Forum de l’Intégration… et font l’objet de nombreuses publications.

Outre ces écrits, la R&D des consultants OCTO Technology se traduit également par l’animation
ou la participation à des projets Open source phares : Cactus (tests unitaires), Maven
(plateforme d’intégration), jCaptcha (Outil de prévention des attaques web par robots), etc.

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

76
©2005 OCTO Technology. Tous droits réservés
Les informations contenues dans ce document représentent le point de vue actuel d’OCTO
Technology sur les sujets exposés, à la date de publication. Tout extrait ou diffusion partielle est
interdit sans l’autorisation préalable d’OCTO Technology. Les noms de produits ou de sociétés
cités dans ce document peuvent être les marques déposées de leurs propriétaires respectifs.

Auteurs
Les auteurs de ce document sont des consultants OCTO Technology, par ordre alphabétique :
Alain Buzzacaro, Laurent Henriet et Messaoud Oubechou.

Merci à toute l’équipe « Architecture d’Intégration » pour son support tout au long de la rédaction
de ce document.

Remerciements spéciaux à Rémy Mathieu-Daudé et Pierre Pezziardi sans qui ce Livre Blanc
n’aurait jamais vu le jour, et à Lyonel Thouvenot pour la qualité visuelle du produit fini.

Pour tous renseignements complémentaires, veuillez contacter P. Pezziardi, Directeur Technique


d’OCTO Technology : ppezziardi@octo.com

Bibliographie OCTO Technology :


Le Livre Blanc des Serveurs d’Applications © OCTO Technology 1999

Serveurs d’Applications (Editions Eyrolles)

Le Livre Blanc de l’EAI © OCTO Technology 1999

Intégration d’Applications (Editions Eyrolles)

Le Livre Blanc de l’IRM © OCTO Technology 2000

Le Projet e-CRM (Editions Eyrolles)

Le Livre Blanc de la Sécurité © OCTO Technology 2001

Architectures de Systèmes d’Information, Livre Blanc © OCTO Technology 2002

Architecture d’Applications, la solution .NET © OCTO Technology 2003

Architecture de Systèmes d’Information, Gouvernance de la Donnée © OCTO Technology 2004

Architecture Orientée Services, Une politique d’interopérabilité © OCTO Technology 2005

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

77
Dépôt légal : Mars 2005
Imprimé pour OCTO Technology chez
PORTAPRINT - 2 rue du Blanc-Seau
59334 - TOURCOING CEDEX
N° de dossier : 20525/0

Architecture Orientée Services (SOA) - Une politique de l’interopérabilité

78
OCTO Technology - 50, Avenue des Champs-Elysées - 75008 Paris
T é l : ( 3 3 ) 1 5 8 5 6 1 0 0 0 - i n f o @o c t o . c o m - h t t p : / / w w w . o c t o . c o m