Imp Soa 1

URBANISATION & ARCHITECTURE
ORIENTÉE SERVICE (SOA)

Quelques bonnes pratiques pour leur mise en œuvre
LIVRE BLANC
A PROPOS DE L’AUTEUR
Cyrille Devaux,
Directeur chez Aubay Management
Titulaire d’un DESS en Intelligence artificielle, reconnaissance des formes et robotique, et d’un Executive MBA (HEC),
Cyrille Devaux est le plus globe-trotter des experts en technologies et systèmes d’information Aubay.
Après une adolescence passée à Abidjan (Côte d’Ivoire), Cyrille Devaux fait ses études supérieures à l’Université Paul
Sabatier de Toulouse et part ensuite effectuer son service militaire civil pendant 2 ans à l’Ecole Nationale des Sciences
de l’Informatique à Tunis (Tunisie).
Cyrille Devaux débute sa carrière en 1992 au Centre de Maquettage des Systèmes d’Information et de Communication
de la DGA (Délégation Générale pour l’Armement) pour le compte de Cap Gemini. En 1995, il rejoint Marben et part en
mission chez TELMEX au Mexique. De retour en France, il occupe successivement les fonctions de consultant ou chef
de projet chez EDF, Bouygues, Neuf Telecom, AXA ou encore IBM.
C’est chez Marben, devenu Sligos puis Atos, qu’il rencontre Christian Aubert (plus tard, fondateur du Groupe Aubay),
Christophe Andrieux (Directeur Général Délégué de Aubay France) et François Hisquin. En 1998, en collaboration avec
ce dernier, et fort de son expérience dans le conseil et le service client, dans les secteurs aussi divers que l’industrie, la
défense, les télécoms, la banque et l’assurance, il crée OCTO Technology, cabinet spécialisée dans l’architecture de
systèmes d’information.
En 1999, il part ouvrir et diriger l’agence espagnole d’OCTO à Madrid jusqu’au rachat du cabinet par le Groupe Aubay,
qu’il rejoint en 2002, en qualité de Directeur Technique.
A 42 ans, Cyrille Devaux occupe le poste de Directeur au sein de Aubay Management, département spécialisé dans le
conseil.
Bibliographie : Livre blanc ECM (2006), Livre Blanc EAI (1999).
Aubay est une société de conseil en technologies et intégration de systèmes d’informations, réseaux et télécoms
fondée en 1997. La société dispose de plus de 2000 collaborateurs répartis dans 6 pays (France, Belgique,
Luxembourg, Italie, Espagne et Portugal). En 2007, Aubay a réalisé un chiffre d’affaires de 155,3 millions d’euros et
une marge opérationnelle de 9,5%.
Ont également participé à la constitution de ce livre blanc :

Lionel BOURCERET, Barbara GORY, Luc BERNARD.
Pour tous renseignements complémentaires : cdevaux@aubay.com ou pesteves@aubay.com

© 2008 AUBAY. Tous droits réservés
Les informations contenues dans ce document représentent le point de vue actuel de Aubay sur les sujets exposés, à la date de publication. Dans la mesure où les éditeurs cités doivent s’adapter aux conditions
changeantes du marché, Aubay ne peut pas garantir l’exactitude des informations présentées après la date de publication.
Les noms de produits ou de sociétés dans ce document peuvent être les marques déposées de leurs propriétaires respectifs.
Urbanisation & Architecture Orientée Service (SOA) - 2

SOMMAIRE
1 INTRODUCTION ........................................................................................................................................................5
2 URBANISATION & SOA, LE COUPLE GAGNANT POUR UN SI AGILE ................................................................6
2.1 Urbanisation du SI ...............................................................................................................................................6
2.2 Principes directeurs de l’urbanisation ..................................................................................................................8
2.3 Règles d’or de l’urbanisation ...............................................................................................................................8
3 LA DEMARCHE SOA .............................................................................................................................................. 12
3.1 Concept de service............................................................................................................................................ 12
3.2 Fiche signalétique d’un service ......................................................................................................................... 14
3.3 Contrat de service ............................................................................................................................................. 14
3.4 Un exemple de modèle SOA ............................................................................................................................. 15
3.5 Typologie de services........................................................................................................................................ 16
3.5.1 Service Applicatif (ou Use Case)................................................................................................................ 16
3.5.2 Service Fonctionnel.................................................................................................................................... 17
3.5.3 Service Entité (ou Service C.R.U.D.).......................................................................................................... 17
3.5.4 Service Transverse (ou d’Infrastructure) .................................................................................................... 18
3.5.5 Service Host ............................................................................................................................................... 18
3.6 Identification des services ................................................................................................................................. 18
3.7 Référentiel des services .................................................................................................................................... 21
4 BONNES PRATIQUES ............................................................................................................................................ 24
4.1 Gestion des versions et variantes ..................................................................................................................... 24
4.2 Gestion des libellés ........................................................................................................................................... 25
4.3 Gestion des transactions ................................................................................................................................... 27
4.4 Gestion des données de références.................................................................................................................. 28
4.4.1 Définition d’un référentiel............................................................................................................................ 29
4.4.2 Principaux types de référentiel ................................................................................................................... 30
4.4.3 Métadonnées d’un référentiel ..................................................................................................................... 30
4.4.4 Services d’accès aux référentiels............................................................................................................... 31
4.5 Gestion des valorisations par défaut ................................................................................................................. 34
4.6 Gestion des exceptions ..................................................................................................................................... 35
4.7 Gestion de la sécurité........................................................................................................................................ 36
4.8 Utilisation d’un bus de service ........................................................................................................................... 38
4.9 Préconisations d’organisation............................................................................................................................ 40
5 CONCLUSION ......................................................................................................................................................... 41
6 REFERENCES ......................................................................................................................................................... 43
7 GLOSSAIRE ............................................................................................................................................................ 44

TABLE DES FIGURES
Figure 1 : La démarche d’Urbanisation en 4 volets de connaissance ________________________________________ 6
Figure 2 : La cascade des règles d’or de l’urbanisation ___________________________________________________ 9
Figure 3 : Exemple de POS fonctionnel ______________________________________________________________ 11
Figure 4 : Le modèle SOA_________________________________________________________________________ 12
Figure 5 : Eléments logiciels d’un service_____________________________________________________________ 13
Figure 6 : Composantes d’un service ________________________________________________________________ 13
Figure 7 : Exemple de modèle SOA _________________________________________________________________ 16
Figure 8 : Le Service Applicatif _____________________________________________________________________ 16
Figure 9 : Le Service Fonctionnel ___________________________________________________________________ 17
Figure 10 : Le Service Entité_______________________________________________________________________ 17
Figure 11 : Le Service Transverse __________________________________________________________________ 18
Figure 12 : Exemple de regroupement de services en composant _________________________________________ 20
Figure 13 : Exemple de diagramme d’architecture applicative (sous MEGA) _________________________________ 21
Figure 14 : Description complète d’un composant SF ___________________________________________________ 21
Figure 15 : Exemple de site web contenant le référentiel SOA (sous MEGA)_________________________________ 21
Figure 16 : Cycle de vie SOA ______________________________________________________________________ 24
Figure 17 : Gestion des versions de services__________________________________________________________ 25
Figure 18 : Gestion des libellés – scénario 1 __________________________________________________________ 25
Figure 22 : Rupture de l’intégrité transactionnelle ______________________________________________________ 27
Figure 23 : Transaction - solution actuelle ____________________________________________________________ 27
Figure 24 : Transaction – solution intermédiaire _______________________________________________________ 27
Figure 25 : Référentiels partagés pour les données de production _________________________________________ 30
Figure 26 : Référentiels dupliqués pour les données de nomenclature______________________________________ 30
Figure 27 : Couche d’accès simple aux données des référentiels__________________________________________ 32
Figure 28 : Gestion des clones _____________________________________________________________________ 32
Figure 29 : Gestion des données de référence ________________________________________________________ 32
Figure 30 : Données de références – cas particulier ____________________________________________________ 33
Figure 31 : Valeurs par défaut – scénario 1 ___________________________________________________________ 34
Figure 35 : Exemple d’un cas d’erreur nécessitant de lever une exception___________________________________ 35
Figure 36 : Architecture SOA sécurisée ______________________________________________________________ 36
Figure 37 : Zone implicite de confiance ______________________________________________________________ 36
Figure 38 : Architecture ESB_______________________________________________________________________ 38
Figure 39 : Rôles et fonctions en relation avec une SOA_________________________________________________ 39

1 INTRODUCTION
La capacité d’une entreprise à faire évoluer son système d’information pour faire face aux changements qu’elle rencontrera
(fusion, acquisition ou cession d’activités...) constitue une des clefs de sa compétitivité.
Contribuant à cette capacité d’alignement du Système d’Information avec les métiers de l’entreprise, l’urbanisation utilise la
cartographie comme principal outil support de son activité. Elle permet d’une part de réaliser l’inventaire du patrimoine de
l’entreprise et, d’autre part, de mesurer les analyses d’impact du système cible, et ceci sur les plans métier, fonctionnel,
technique, voire organisationnel.
Par ailleurs, l'évolution récente des technologies de l'information et le développement rapide des services sur le Web ont
impulsé de nouvelles approches qui permettent de mettre en place des architectures d’entreprise plus souples, plus
évolutives, et plus aptes à satisfaire les besoins d'agilité de l'entreprise.
Dans ce contexte, les objectifs des départements « Architecture – Urbanisation - Méthode » de la plupart des grandes
entreprises visent aujourd’hui à rationaliser et rendre plus modulaire leur patrimoine applicatif pour gagner en flexibilité et
1
répondre plus rapidement aux sollicitations des Métiers ou de la réglementation en vigueur .
Le présent ouvrage s’inscrit dans cette démarche de progrès puisqu’il propose d’identifier et de formaliser quelques règles
d’urbanisme et il exposera un certain nombre de bonnes pratiques d’une démarche d’Architecture Orientée Service (SOA).
Il est le fruit de l’expérience des consultants Aubay qui interviennent régulièrement sur des missions de conseil en stratégie
2.
technologique pour le compte de nos grands clients
Le présent livre blanc est composé de 3 chapitres.

Le deuxième chapitre introduit les concepts relatifs à l’urbanisation et à la SOA. Notons que ce chapitre n’a pas vocation à
être exhaustif dans son contenu, de nombreux ouvrages traitant déjà de la question.
Le troisième chapitre, représentant le cœur du document, présentera certaines règles (ou bonnes pratiques) qui ont souvent
été mises en place dans le cadre d’une démarche mixte « Urbanisation / SOA ».
1
SOX, Bale II, LOLF…
2
AGF, Société Générale, GMF…

2 URBANISATION & SOA,
LE COUPLE GAGNANT POUR UN SI AGILE
Tout acteur du développement d’application devrait pouvoir répondre sans ambiguïté aux questions suivantes :
Quel modèle d’architecture applicative faut-il adopter selon le type d’application ?
Comment accéder aux données et traitements déjà présents dans le patrimoine applicatif ?
Comment sont gérées les données de références de l’entreprise ?
Quelles règles de communication faut-il suivre entre applications?
Existe-t-il au sein de l’entreprise un annuaire des services partagés ? comment y accéder ?
Comment contribuer à l’enrichissement de cet annuaire ?
Répondre à ces questions revient en fait à définir certaines règles d’urbanisation du SI et à clarifier les principes
architecturaux pour le développement des nouvelles applications.
Le métier d'architecte technique (ou de système informatique) existe depuis longtemps. Celui d'urbaniste, parfois
nommé architecte d’entreprise (ou de système d’information), est en revanche beaucoup plus récent. Urbaniste et
architecte sont aujourd'hui deux métiers complémentaires dont les rôles sont fondamentaux dans la conception,
l'implantation et l’évolution de systèmes durables. Ensembles, l’architecte et l’urbaniste disposent d’une vision globale à
la fois des processus, des informations et de leurs interdépendances.
A ces deux fonctions, il convient d’ajouter celle d'administrateur de référentiel de données dont l’objet est d'assurer une
définition précise des règles de gestion et un propriétaire unique (dans le sens objet du principe) à chaque information
manipulée par l’organisation. Voir à ce sujet le chapitre 4.4 de ce document.
2.1 Urbanisation du SI
Urbanisation du SI : Action de structurer de façon cohérente et modulaire le SI en définissant les niveaux de
représentation, en répartissant les éléments et les responsabilités qui y sont liées par niveaux, et en définissant les
règles communes ou spécifiques.

Urbaniser le système d’information, c’est donc définir un cadre cohérent, stable et modulaire dans lequel viendront s’insérer
les développements informatiques.
Deux grandes préoccupations vont ainsi guider la démarche d’urbanisation :
la désimbrication des systèmes, des différents métiers puis des différentes activités de façon à éviter
l’enchevêtrement des applications informatiques correspondantes. Ce découplage a pour contrepartie la mise en
3
place de référentiels communs .
4
la recherche du juste équilibre entre subsidiarité et mutualisation, la difficulté de cet exercice est de placer la
responsabilité du système au plus près du terrain pour rendre l’entreprise plus réactive tout en réalisant des
économies d’échelle et en garantissant la cohérence de l’ensemble.
La cartographie du SI
La cartographie considère en général quatre visions du système d'information :
• la vision métier qui décrit les processus ou activités que le SI doit supporter,
• la vision fonctionnelle qui décrit les fonctions du SI permettant de représenter les processus,
• la vision applicative décrivant l'ensemble des éléments applicatifs du SI,
• la vision technique décrivant l'architecture technique (matériels, logiciels et technologies utilisés).
Cartographie métier
Les systèmes d’information doivent être cartographiés du point de vue métier :
• Les objets manipulés sont des processus, acteurs, rôle, objets métiers
• L’exploitation des cartographies métiers se fait au travers :
o des études d'impacts (par exemple, lors d’une fusion d’activité ou lors de l’éclatement d'activités)
o des études d’optimisation des processus (par l’analyse des points sensibles des processus).
Cette vue définit par conséquent des domaines et les processus métiers qui relient ces domaines par des flots de
données. Ces informations doivent être transposables d’une entreprise à une autre.
Cartographie fonctionnelle
Les systèmes d’information doivent être cartographiés du point de vue fonctionnel :
• Les objets manipulés sont des domaines d’activité, des domaines de responsabilité,
• Le découpage doit s’effectuer autour d’invariants métiers (objets métiers, fonctions …),
• Les échanges doivent être identifiés entre domaines fonctionnels,
• Des référentiels communs doivent être identifiés autour des objets ou données métiers.
Cette vue représente la mise en œuvre particulière du métier dans l’entreprise mais doit restée découplée des solutions
techniques de mise en œuvre informatique.
Cartographie applicative
Les systèmes informatiques doivent être cartographiés du point de vue applicatif (ou logiciel) :
• Les objets manipulés sont des applications, des composants logiciels, des bases de données…
• On y identifie les modes de communication entre composants (synchrone/asynchrone, MOM/fichier/DB/http,...),
• On y précise les outils communs (ex : modules communs de gestion des logs, des traces, des statistiques…)
• On précise les standards techniques (choix) et les règles de gestion concernant les plateformes logicielles (ex :
distinguer l’environnement de développement de celui de production).
La vue applicative est la partie automatisée du SI. Elle va décrire les solutions technologiques retenues pour réaliser
certaines fonctionnalités du SI
Cartographie technique
Les systèmes d’information doivent être cartographiés du point de vue technique (ou matériel) :
• Les objets manipulés sont du matériel (serveurs…), du câblage, des bâtiments, etc.…
• On y précise les règles de gestion des plates-formes (i.e. une seule plate-forme pour N applications ou N plates-
formes pour une application ; plate-forme 24x7…)
• On précise les règles de dimensionnement des tuyaux, les contraintes d’exploitation, de sécurité.
3
Un chapitre entier sera consacré à ce point majeur d’une architecture d’Entreprise.
4
Subsidiarité : Le principe de subsidiarité est une maxime politique selon laquelle la responsabilité d'une action publique doit être allouée à la plus petite entité
capable de résoudre le problème d'elle-même. C'est donc le souci de veiller à ne pas faire à un niveau élevé ce qui peut l'être avec autant d'efficacité à une
échelle plus faible.

2.2 Principes directeurs de l’urbanisation
Quatre principes directeurs dirigent l’élaboration des règles de l’urbanisation :
Cohérence forte / couplage faible

Le processus métier global d’une entreprise est découpé en zones, contenant chacun des quartiers, comprenant à
leur tour des blocs pour lesquels les données et les traitements présentent une forte cohérence (cohérence forte) et
une frontière bien délimitée avec les blocs connexes (couplage faible).
Pas de dépendance temporelle entre blocs, chacun opérant de manière asynchrone par rapport aux autres.
Encapsulation
Le bloc est seul propriétaire de ses données et de ses traitements.
Ses données sont masquées pour les autres blocs, un bloc ne peut donc accéder aux données d'un autre bloc qu'en
faisant appel aux services que propose celui-ci.
Mutualisation
Partager les éléments du SI qui peuvent être utilisés par plusieurs blocs :
- Par la mise en œuvre de référentiels d’objets,
- Par le déploiement d’une infrastructure d’échange (EAI ou ESB),
- Par la mise en œuvre progressive d’une approche orientée « service » (SOA).
Echanges contrôlés
A la frontière de chaque bloc, les échanges avec l'extérieur se font au moyen d'interfaces publiques et éventuellement
par l'intermédiaire d'une infrastructure fédératrice (annuaire).
Chaque bloc produit des résultats et des rapports avec un format standard sans présumer des destinataires.
Chaque interface est gérée par version pour prendre en compte le cycle de vie des blocs et de l’infrastructure de
communication.
2.3 Règles d’or de l’urbanisation

De ces principes directeurs découlent un certain nombre de règles pour l’implémentation d’une démarche d’Urbanisation.
Ces règles se situent sur trois plans : au niveau « Stratégique », en rapport avec les grandes orientations communiquées par
la Direction Générale (ou Comité Directeur) ; au niveau « Tactique », relevant plus d’une politique de gouvernance du
Système d’Information et enfin au niveau « Opérationnel », en rapport avec des choix de mise en œuvre.
Nous reprendrons ci-après dans le détail les règles du niveau « Tactique » puis le reste du document sera exclusivement
consacré à la mise en place de la dernière règle de niveau opérationnelle : la mise en place d’une SOA.

R1 : Respecter les zones d’urbanisme (ou Plan d’Occupation des Sols)
Tout système doit s'inscrire dans une et une seule "zone d'urbanisme" (premier découpage macroscopique).
5
On distribue ainsi les systèmes applicatifs dans les zones :
de présentation/acquisition (couche de front office ou commerciaux),
de traitements métiers (couche de back office ou de gestion),
d'échange et diffusion (couche middleware),
de gestion des référentiels,
de fonctions support à l’entreprise (SI Financier, SI Ressources Humaines), de pilotage et de reporting.
Par exemple, un système ne devrait pas cumuler des préoccupations commerciales (simulations de devis, règles de gestion
simplifiées) et des préoccupations administratives (caractéristiques contractuelles des contrats, règles de gestion
rigoureuses). Autre exemple, une application ne doit pas gérer à la fois des contrats et assurer la production de statistiques
d'aide à la décision (qui est la vocation d'un système de pilotage).
Gains attendus
Eviter la redondance fonctionnelle
Meilleure évolutivité du Système d’Information (limitation de l'imbrication des traitements)
Pilotage plus simple de l’évolution du système d’information par une vision d’ensemble urbanisée permettant
d’appréhender plus rapidement l’impact d’une évolution fonctionnelle ou technologique, de localiser les zones de
progrès, par exemple, grâce à des métriques calculées à partir de la cartographie.
R2 : Limiter les nouveaux développements

Réutiliser (au sens « mutualisation » et non « réplication ») plutôt qu’acheter, acheter plutôt que développer, développer
seulement pour acquérir un avantage compétitif certain et durable. En cas de développement, il faut veiller à respecter
les standards et normes de l’entreprise.
Gains attendus
Réduction de la diversité du patrimoine applicatif
Réduction des coûts
5
On définit un SA comme étant le regroupement de fonctions métiers au sein d’une même entité informatique

R3 : Contrôler les flux d’information entre applications
La gestion des échanges doit être pilotée par un bus de communication inter-applicatifs (type, EAI, ESB, MOM selon
besoin).
Une bonne gestion des flux est particulièrement importante pour la cohérence du SI et elle doit respecter un certain nombre
de principes :
Tous les flux doivent être identifiés (donc inscrits dans la cartographie),
Tout flux doit être préférentiellement basé sur un échange asynchrone de type Message,
Tout SA échange avec l’extérieur via une couche d’abstraction normalisée et documenté,
Tous les flux doivent être gérés par un unique outil central (type bus de communication inter-applicatifs).
Gains attendus
Fiabilité et cohérence des échanges de données,
Pilotage et traçabilité des événements,
Analyse statistiques des flux,
Sécurisation de la mise en production des nouvelles versions d’échanges,
R4 : Partager les données communes

Les données communes de l’entreprise sont contenues dans des bases dites référentielles.
Un référentiel ne contient que des informations de référence. Une information de référence est principalement caractérisée
par son partage entre plusieurs systèmes applicatifs et par un fort accès consultatif. Un référentiel peut aussi concerner les
données communes de nomenclature (paramètres applicatifs).
Pour chaque référentiel, il est nécessaire de bien identifier sa localisation et de développer une architecture d'échange
(normalisée et indépendante) d'informations entre les applications pour permettre la circulation des informations présentes
dans les référentiels.
Gains attendus
Vision commune des informations de référence de l’entreprise, évitant ainsi aux applications toute divergence ou
désynchronisation sémantique sur une donnée,
Mutualisation des infrastructures de gestion des tables communes.
R5 : Partager les traitements métiers

Les traitements métiers doivent être encapsulés sous forme de services réutilisables.
Le catalogue des services devra être géré via un annuaire.
Mesure d’avancement
Une démarche d’Urbanisation est un projet de longue haleine. Il s’agit donc de bien mesurer au fur et à mesure des mois qui
passent l’avancement de cette démarche de progrès ! A cette fin, le Club Urba a formalisé un outil de suivi de l’avancement
au travers le calcul d’un indice d’avancement.
Graphiquement, il se représente ainsi :

La suite du document se focalisera plus précisément sur la dernière règle énoncée : partager les traitements métiers. Nous
donnerons ainsi quelques bonnes pratiques relatives à la mise en place des Architectures Orientées Services.

3 LA DEMARCHE SOA
L’architecture orientée services (SOA) s’inscrit dans une démarche d’urbanisation qui guide la mise en place des
applications « métiers » et fixe la frontière entre réutilisation de l’existant (mainframe…) et nouveaux développements.
L’architecture SOA favorise la réutilisation fonctionnelle au travers de l’approche service. Cette approche est un modèle
d'interaction applicative mettant en œuvre des composants logiciels avec une forte cohérence interne et des couplages
externes « lâches ». Elle permet en outre de contractualiser la mise à disposition des grandes fonctions métier de l’entreprise
et induit une mise à disposition homogène de ces fonctions. De plus cette approche permet d’envisager de manière uniforme
la mise en place de fonctions communes comme l’administration, l’exploitation, la sécurité, etc.
3.1 Concept de service

Conceptuellement, un service expose une fonction métier ou technique, qui doit :
avoir le sens le plus universel pour une réutilisation optimale,
être stable et pérenne, donc indépendante de son implémentation.
Le service est de préférence autonome, favorisant ainsi le couplage faible entre services.
Il implique de gérer un contexte d’appel transmis mais non mémorisé (service « sans état »).
Il fonctionne en toute transparence, fournissant des informations sur son exécution, ses performances…
Un service est donc une prestation élémentaire :

assurée au bénéfice :
- D’une application,
- D’un processus métier,
- D’un autre service.
partagée entre plusieurs applications, processus ou services,
documentée et publiée,
- Dans le référentiel des Services,
- Dans les cartographies d’urbanisation.
conforme à une structure d’implémentation modèle (selon sa typologie).

Techniquement, un service, c’est un ensemble d’opérations exposées et accessibles aux consommateurs.
6
La composante « Interface » est une description des Entrées / Sorties pour l’ensemble des méthodes du service (voir le
chapitre sur le contrat de service).
L’implémentation représente la réponse codée à la fourniture des fonctionnalités exposées par l’interface. Elle peut être de
diverses natures car, étant masquée aux utilisateurs du service, le choix d’une technique de mise en œuvre (technologies
Web Service ou EJB ou connexion directe JDBC…) n’a en principe pas d’impact sur son exécution (à part un impact de
performance mais qui est alors explicitement indiqué dans le contrat de service).
L’aspect Mapping est une couche technique (optionnelle) de mise en relation entre deux éléments de natures distincts (ex :
objet java coté Service & structure à plat coté host, éventuellement au travers de l’utilisation d’un outil type hibernate).
Les bouchons sont nécessaires pour les phases de tests et font partie intégrante des éléments logiciels du service.
Concrètement, un service, c’est l’ensemble de composants suivants :
6
On utilisera indifféremment le terme « Service » pour désigner le composant ou l’une de ses opérations.

Du point de vue des outils support à l’utilisation des services, les choix sont partagés de la façon suivante :
7
La partie Descriptif (les spécifications du service) sera mémorisée dans un outil référentiel constituant ainsi le
référentiel des Services de l’entreprise.
La partie Code (l’implémentation du service et des tests associés) sera gérée avec l’outil retenu de gestion des
versions des développements informatiques (Ex : Source Safe, CVS…).
3.2 Fiche signalétique d’un service

La fiche signalétique d’un service est la carte d’identité du service. Elle expose en quelques lignes les tenants et
aboutissants du service. C’est donc une composante essentielle de la partie descriptive et documentaire du service.
Elle reprend l’ensemble des éléments suivants :

Nom du service
Version actuelle
Compatibilité avec autres versions
Date de mise en service
Date de péremption
Entités métiers manipulées
8
Applications clientes utilisatrices du service
Processus métiers clients (option)
Sous services utilisés (ou appelés par le service décrit)
3.3 Contrat de service

La valeur d’une architecture de services repose sur des contrats qui garantissent stabilité, assurance et performance entre
interlocuteurs. Un contrat de service spécifie un contrat d’interface (nature des informations fournies et générées) et une
qualité de service attendue et admise par les parties prenantes :
Le contrat d’interface caractérise les conditions d’utilisation et garantit un service sans état à des fins de mutualisation
(type de traitement, données d’entrée et données de sortie, contraintes de sécurité).
La qualité de service porte sur la disponibilité (éventuelle via la mise en place de solutions dégradées), la réactivité
(temps de latence/délai d’exécution, débit), la sécurité et, éventuellement, le coût de fonctionnement.
Concrètement, le contrat de service se compose donc des éléments suivants :

Politique d’Utilisation
- Description des interfaces d’appel
- Description des paramètres d’appel
Politique de sécurité
- Authentification du demandeur
- Gestion des droits d’accès
- Cryptage des informations
Politique de robustesse
- Présence d’un Secours, mode dégradé/différé, reprise
Politique de performance
- Réactivité du service
- Seuils d’alerte, statistiques périodiques
Politique d’administration (suivi qualité de service)

- Taux de disponibilité, indisponibilité maximale.
7
Repository de Service (WSRR chez IBM, MEGA V2007…)
8
Utile pour l’analyse d’impact d’une modification apportée sur un service.

WSDL (Web Service Description Language)
Description (basée sur XML) d’une Interface publique d'accès à un service. Précise plusieurs aspects dont
principalement :
• Le protocole de communication (binding)
• Les opérations exposées par le service (portType)
• Le format de paramètres requis pour communiquer avec ce service (message)
Syntaxe :
Exemple de description WSDL d’un service de contrôle d’une adresse postale :
3.4 Un exemple de modèle SOA

Une architecture SOA est donc basée sur la notion de service tel que décrit précédemment. Cependant, il reste de nombreux
aspects à déterminer et à figer dans un modèle d’entreprise. L’agencement de ces services forme l’architecture SOA (ou le
modèle SOA) retenue pour l’entreprise.

Dans ce modèle, figurent plusieurs types de service. On parle alors de typologie de service comme décrit ci-après.
3.5 Typologie de services

Il existe plusieurs catégories de services selon que l’on les classe par nature de services (catégorisation verticale sur la
figure 7) ou domaines de services (catégorisation horizontale).
3.5.1 Service Applicatif (ou Use Case) 9
Le Service Applicatif permet de mettre en œuvre la logique applicative d’une application telle qu’elle a été identifiée par les
cas d’utilisation ou les processus métiers. Ce service est fortement lié à la logique de l’application qui a nécessité sa
création ; en général, il n’est donc pas réutilisable, hors du contexte de l’application. Le service applicatif active des règles de
gestion qui vont conduire, dans le contexte de l’application, à la modification d’une grappe d’objets métier.
9
Au sens UML du terme.

3.5.2 Service Fonctionnel
Le Service Fonctionnel permet d’exposer des traitements métiers identifiés comme réutilisables dans des contextes variables
(ex: calcul de devis). Le service fonctionnel travaille sur des objets métiers et fait donc appel à des services Entité ou
Transverse. Dans le cas de l’exposition d’un service Host de haut niveau (et correspondant fonctionnellement à un SF), on
s’oblige à créer un SE de passage (prise en compte de la gestion du mapping…).
La Valeur Ajoutée du SF réside dans ses caractéristiques particulières (mais arbitraire car dépendant du modèle SOA que
l’on décide d’établir) :
Le SF peut faire appel à des services plus élémentaires ou externes (partenaires). C’est la notion d’orchestration.
Le SF représente la couche logicielle où seront prises en compte la gestion de la sécurité, des règles métiers
déportées (ex : calculs globaux sur des listes) ou encore des libellés (voir plus loin dans le paragraphe).
10
3.5.3 Service Entité (ou Service C.R.U.D.)
Le Service Entité expose les opérations basiques suivantes :
Créer un nouvel objet métier dans le référentiel concerné.

Rechercher un ensemble d’objets métier selon des critères de recherche.
Lire un objet métier selon une clef d’accès unique.
Exporter un objet vers un format donné (excel, pdf…).
Mettre à jour un objet métier.
Ce type de service permet de faire la transition entre le monde des référentiels de données et le monde de l’application. Il
s’agit de transformer des données provenant d’horizons hétérogènes en objets métier utilisables par les applications mettant
10
Signifie « Create – Research – Update – Destruction » (les 4 opérations élémentaires sur un objet)

en œuvre la SOA, et d’assurer l’opération inverse afin d’enregistrer les modifications réalisées dans l’application. Ces
services sont importants dans la mesure où ils permettent de rendre les applications indépendantes du format de stockage
des données métiers ainsi que de leur localisation.
Concernant l’opération de recherche, il est intéressant de raisonner en « niveau de profondeur » sur l’objet métier retourné.
En effet, un objet métier est généralement lié à d’autres objets (« Clients » avec « contrats », « contrat » avec
« sinistres »…). Se pose alors la question de savoir quelle « grappe » d’objet voulait en pratique l’utilisateur qui demande un
objet… Veut-il simplement l’objet métier racine ou veut-il un ensemble plus large d’objets, tous reliés à l’objet racine, origine
de la requête ? Pour répondre à ces différents cas, il est d’usage de paramétrer les requêtes de recherche avec un type (ou
scénario) de recherche. Ainsi, selon le scénario précisé, la requête retournera l’objet métier seul ou un ensemble d’objet
selon une profondeur donnée sur la grappe d’objet. Bien évidemment, le programmeur du composant CRUD installera des
contrôles afin d’éviter qu’une requête mal définie tente de ramener « l’ensemble du SI »…
3.5.4 Service Transverse (ou Infrastructure)
Un Service Transverse offre des services dont la problématique n’est pas uniquement métier. Un service transverse peut
éventuellement être client d’autres services transverses mais cette dépendance est peu souhaitable.
Exemples de Services transverses :
Service de log
Service de gestion du Contexte Utilisateur
Service de gestion des libellés…
3.5.5 Service Host

Dans la majorité des grandes entreprises, l’existant est aussi constitué d’applications Mainframe. Les applications du HOST
doivent alors être exposées au travers de services Host accessibles par les applications distribuées. Le pont entre les deux
11
milieux (Host et distribué) peut se faire de différentes manières, nombreux sont les logiciels d’infrastructure qui se
proposent d’encapsuler et d’exposer les services HOST (IMS, CICS…) à l’extérieur.
3.6 Identification des services

12
L’identification des services est une étape importante dans la démarche SOA . On cherche en effet à identifier des Services
Métier Réutilisables :
Service : interaction unitaire avec le SI, comprenant une interface et exposé par un composant logiciel
Métier : s’exprime en langage métier, indépendamment de l’implémentation.
Réutilisable : tous processus de l’entreprise qui mobilisent cette fonction devraient utiliser le même service
11
Il est possible de disposer d’un serveur d’applications sur le HOST, facilitant ainsi la communication avec l’extérieur du Host.
12
On notera l’effort particulier de IBM dans la formalisation d’une méthode d’identification des services. La méthode SOMA.

Cette démarche s’appuie sur plusieurs axes à la fois :
Analyse des processus métiers (ou approche Top-Down)

Analyse des objectifs métiers
Analyse de l’existant (ou approche Bottom-up)
… et sur le bon sens !
SOMA : Méthode d’origine IBM, est un support méthodologique à l’alignement d’une “business architecture” et d’une
architecture orientée service par une analyse combinée “top-down” (business driven, process based) et “bottom-up”
(réutilisation des systèmes existants ou en projet).
La première étape « identification des services candidats » peut suivre 3 approches.
Le “Domain decomposition” est une analyse de processus métier. Elle répond donc aux règles de l’analyse de
processus. Le souci principal est d’obtenir une analyse appropriée à la décomposition en services par l’application des
principes suivants :
• Identifier l’événement métier déclencheur.
• N’utiliser que des termes métier (sans lien avec les applications ni la technologie).
Reste à savoir à quel niveau de décomposition s’arrêter ? Suivre la “Rule of thumb 3 levels” mais d’autres critères
peuvent s’ajouter :
• Tâche unitaire.
• Issue d’un acteur unique d’une organisation unique.
• Complétude nécessaire pour aborder la tâche suivante.
• Contient au moins une interaction avec le système d’information.
• Éventuellement transactionnelle.
A la fin de cette phase, chaque tâche devient un service candidat pour ajout dans le portefeuille des services candidats.
Goal Service Modeling consiste à identifier les objectifs Métier portés par le ou les processus (ex : Améliorer une
productivité, un chiffre d’affaire, une qualité de service, la qualité d’information…). Dans cette phase, vont être
recherchés les services qui permettent d’informer de l’atteinte de ces objectifs :
• Recherche de l’existence de services cohérents avec les objectifs.
• Identifier les indicateurs clé de performance (KPI) : quelle est l’information nécessaire à un manager responsable du
processus pour valider l’atteinte des objectifs ?
• Définir les services qui vont permettre d’obtenir cette information.
Enfin, l’Analyse des systèmes existants passera par :

• Faire la liste des fonctions des systèmes existants.
• Identifier les fonctions qui sont dans le périmètre fonctionnel du domaine mais qu’on ne trouve pas dans le portefeuille
des services candidats.

La deuxième étape de la méthode revient à sélectionner les services à exposer puis spécifier les services ainsi retenus.
La sélection repose sur une analyse de chaque service, le LITMUS, test sur 10 critères :
1. Fonction métier : la fonction correspond à une activité d’un processus du métier
2. Réutilisation : plusieurs consommateurs sont identifiés pour le service.
3. Recomposabilité : il est possible de réutiliser le service dans le cadre d’autres modes opératoires
4. Granularité : il n’y a pas de possibilité d’élargir la granularité du service pour augmenter sa réutilisation
5. Redondance : il n’y a pas d’autre service qui présente les mêmes entrées sorties et le même périmètre
fonctionnel
6. Pas de gestion d’état : les données d’entrée et les données persistantes sont suffisantes pour que la
fonction s’exécute. Il ne tient pas compte des interactions passées.
7. Ininterruptible, sans action de l’utilisateur : la fonction, telle qu’elle serait implémentée, s’utilise en une seule
interaction.
8. Encapsulation : la fonction, telle qu’elle serait implémentée n’a pas besoin de traitements ou données
implicites ou complémentaires, imposés par l’implémentation.
9. Description externalisable : la fonction, telle qu’elle serait implémentée, peut être exposée comme un web
service
10. Qualité de service : la fonction, telle qu’elle serait implémentée, répond à la qualité de service demandée
La troisième étape, celle relevant des Décisions d’implémentation, ne constituent pas un processus simple. Ces
décisions reposent sur les savoirs faire de l’architecte, sur la base des éléments recueillis lors des phases précédentes.
SOMA ne propose pas de démarche particulière à ce niveau.
L’identification pertinente des services est un critère important pour la bonne qualité du SI global. Cependant, vu la grande
quantité de services possibles pour les SI des grandes entreprises, il n’est pas envisageable de créer autant de composants
(au sens du composant logiciel autonome et déployé sur un serveur) que de services qui auront été identifiés. Il s’agira donc,
dans un second temps de réflexion, de regrouper les services au sein de composants. Les services sont alors appelés
« Opérations » du composant qui par extension, peut parfois prendre le nom de service… Assez naturellement, la politique
de regroupement consistera à regrouper au sein d’un même composant les services traitant des mêmes entités (ou objets)
métiers mais il pourra éventuellement être tenu compte d’autres critères de regroupement comme les contraintes liées au
contrat de service (regroupement des opérations à fort besoin de disponibilité au sein d’un même composant versus
opérations non critiques).

3.7 Référentiel des services
Le référentiel des services sera l’unique source d’information mise à disposition de la DSI en général et des équipes de
développement en particulier. Il contiendra une sorte de répertoire des services ainsi que la cartographie des applications
utilisatrices des services.
Figure 13 : Exemple de diagramme d’architecture applicative (sous MEGA)
Le référentiel doit également contenir la description des contrats de service, le détail des opérations (au format WSDL par
exemple), la liste des applications utilisant le service et une vision des données (sous forme de Diagramme de classe) des
objets manipulés.
Figure 14 : Description complète d’un composant SF
Ces informations seront évidement exposées et consultables via un site Intranet.
Figure 15 : Exemple de site Web contenant le référentiel SOA (sous MEGA)

Annuaire de services vs Référentiel de services
Il s’agit bien de deux concepts différents qui ont chacun leur propre importance.
• L’annuaire (ou Registry) : permet la publication et la sélection des métadonnées des services
• Le référentiel (ou Repository) : stocke les définitions des services, les dépendances et les relations entre services
Ces deux fonctions sont parfois couplées au sein du même outil. Par exemple, IBM offre une gestion intégrée de
plusieurs éléments au travers de son produit WSRR ©IBM.
Publication et découverte
• Définitions et descriptions des services
• Liens entre services et dépendances
• Définition du cycle de vie des services
• Définition des policies par service
Enrichissement
• Gestion dynamique des informations par les runtimes WPS, WMB, WESB, WAS…
• Sélection du endpoint d’un service
• Gestion de la disponibilité des services
• Gestion des policies
• Notification des changements
• Sécurité des informations transmises
Gestion
• Gère la relation entre services, les dépendances, les redondances
• Classification de services en groupes métiers
• Gestion des policies
• Gestion des changements des services
• Gestion des versions
• Analyse d’impact

Gouvernance
• Organisation des services, supervision des services
• Classification des services en fonction du cycle de vie
• Policies pour la publication et l’utilisation des services
• Sécurité d’accès basé sur des rôles

4 BONNES PRATIQUES
Après une présentation générale des pratiques d’Urbanisation et une introduction aux architectures orientées Services, ce
chapitre donnera quelques bonnes pratiques tirées de nos expériences.
Ces « Best Practices » se rattachent en général à l’une des quatre étapes du cycle de vie SOA.
Cependant, le présent document traitera plus particulièrement de celles en relation avec l’étape d’intégration car ce sont des
problématique d’architecture habituellement rencontrées quelque soit le contexte client ou environnement technique :
gestion des versions et des variantes,
gestion des libellés,
gestion des transactions,
gestion des données de références,
gestion des valeurs par défaut,
gestion des exceptions,
gestion de la sécurité,
gestion des flux et échanges,
préconisation d’organisation.
Les réponses apportées ici sont à resituer dans le modèle d’architecture exemple décrit dans le paragraphe §3.4.
4.1 Gestion des versions & variantes

Certaines modifications du contrat de service sont sans conséquence pour les consommateurs existants (par ex : ajouter
une opération…). D’autres types de modification (par ex : supprimer une opération, renommer une opération, changer les
paramètres d’une opération ou encore, pour des raisons métiers, mise en place d’un traitement différent au sein de
l’opération) peuvent avoir des conséquences pour les consommateurs.
Les solutions envisageables sont les suivantes :

Option 1 : Migration des applications appelantes (les actuels consommateurs) selon le même rythme que les
changements apportés sur les services appelés.
(-) Solution coûteuse et complexe à organiser dans sa mise en oeuvre
Option 2 : Simple rajout au sein du composant d’une nouvelle opération avec les modifications apportées, l’ancienne
opération continuant à exister.
(-) Risque de multiplication d’opérations ayant peu ou prou les même objectifs métiers
Option 3 : Développement d’une autre version du composant intégrant la nouvelle forme de l’opération modifiée.
(-) Solution moyennement simple dans sa mise en œuvre et à condition de faire l’acquisition d’un produit type
Annuaire (comme WSRR de IBM) qui déterminera quelle version du service il faut appeler.

Il n’y pas de solution à privilégier pour tous les cas de figures. Cependant, la solution du simple rajout de la nouvelle version
de l’opération (option 2) est l’une des plus simples à mettre en œuvre et les inconvénients sont relativement limités.
4.2 Gestion des libellés

Le constat de départ (ou énoncé de la problématique) est que le libellé d’une même entité est parfois différent selon les
applications ou le type d’IHM ou selon la langue de l’utilisateur (multilinguisme). Par exemple, le libellé « Madame » peut être
voulu écrit en toutes lettres (« Madame ») ou en abrégé (« Mme ») selon que l’application soit accessible via un navigateur
Web, un téléphone mobile, un PDA ou un terminal 3270.
Quatre scénarios d’implémentation d’une gestion normalisée des libellés ont été étudiés dans l’architecture de référence
SOA (voir figure 7). On suppose ici la mise en place d’un référentiel des libellés au sein d’une base dédiée mais
éventuellement esclave du référentiel géré sur le Host. On suppose également que le Host, garant des règles et données
métiers, ait la capacité à retourner le code du libellé et non pas le libellé lui-même.
Scénario 1 : gestion du libellé au niveau SF

Le SF se charge de traduire le code retourné par un service Host en libellé intelligible par l’utilisateur.
Scénario 2 : gestion du libellé au niveau SE

Le SE se charge de traduire le code en libellé

Scénario 3 : gestion du libellé au niveau SH
Les SH retournent directement les libellés
Ces trois premières solutions ne sont pas optimales dans la mesure où le libellé et son code circule inutilement sur une
partie de la chaîne de transmission. Le libellé n’est véritablement utile en bout de chaîne.
Scénario 4 : gestion du libellé par l’application

L’application se charge elle-même de traduire le code en libellé
Ce dernier scénario est le plus optimisé. Il permet de retarder la conversion du code en libellé le plus tard possible. Il est
cependant intéressant de pouvoir gérer quelques libellés par défaut (par exemple, libellé court, libellé long) dès l’origine de la
chaîne afin de ne pas obliger systématiquement l’application à demander le libellé correspondant à un code, quand le libellé
souhaité est des plus standards.
Ceci étant posé, les points qui restent à étudier seront :
Réplication. Les libellés sont gérés dans le HOST (par définition de son rôle centralisateur et garant des référentiels),
il faut donc mettre en place un mécanisme de réplications (avec quelle fréquence ?) entre le référentiel des libellés
HOST et la base répliquée locale.
Contenu du référentiel. Le contenu en lui-même et la structure du référentiel doit être étudié précisément.
- Combien attribuer de libellés pour une clef donnée ? (Libellé court, libellé long, libellé commercial, etc…)
- Comment constituer la clef de recherche unique pour un libellé donné ? (est-ce un simple code, une combinaison
entre plusieurs valeurs telles qu’entité, type d’IHM, longueur souhaité du libellé, profil de l’utilisateur, canal de
diffusion…)
Notons enfin que l’administration centralisée des libellés peut représenter une tâche non négligeable dans la mesure où il
peut exister autant de libellés que d’applications pour une valeur donnée, surtout si le mécanisme mis en place autorise (et
cela est souhaitable) l’extension des valeurs de libellés par les applications elles-mêmes.

4.3 Gestion des transactions
Les SF doivent fonctionner en mode transactionnel (ne serait-ce que parce qu’ils sont susceptibles d’orchestrer plusieurs
SE). Cependant, dans la réalité de certains projets, on constate une rupture de l’intégrité transactionnelle quand la
transaction englobe un service HOST, la raison en est souvent que la passerelle vers le HOST n’est pas Transaction
Manager au sens XA du terme.
Une possibilité à court terme rejoint les principes souvent utilisés aujourd’hui, à savoir reléguer la transaction au niveau du
HOST (proposer un SH qui gère les traitements transactionnels à son niveau, sous CICS). Cela impose le développement
d’un module particulier (SE chapeau) en rupture de conformité avec le modèle SOA retenu.
Ce regroupement d’entités et de traitements distincts sous le même module HOST n’est évidemment pas une solution
pérenne. Il est cependant possible, quoique coûteux, de coder des transactions inverses. Dans ce cas, le retour arrière est
géré par le SF qui, en cas de problème sur l’une des requêtes, lance les requêtes inverses des premières qui se sont
déroulées sans problème.

A long terme, il faudrait évidemment penser à mettre en place une passerelle vers le HOST qui conserve l’intégrité
transactionnelle (support du roll back transactionnel).
4.4 Gestion des données de référence

Dans l’entreprise, chaque direction consomme de l’information et en produit en retour. En corollaire, tout bloc du SI produit et
consomme des données que nous qualifierons de « publiques ».
Ceci pose quatre grands problèmes :
La disponibilité de la donnée en premier lieu. Où la trouver ? Dans quelle base de données ? Et comment y
accéder ?
La consistance : X dit blanc, Y dit noir. A se conforme à telle nomenclature, B à telle autre. Qui a tort, qui a raison ?
La stratification organisationnelle, voire la concurrence pure et simple de services, aboutit souvent à du doublonnage
de données de référence et donc à de l’incohérence.
La pertinence : la forme, la fraîcheur doivent être adaptées aux usages des consommateurs. Pour une même
donnée, les besoins sont souvent différents selon les consommateurs.
La sécurité : fiabilité de l’émetteur, confidentialité de l’échange… la sécurité de la donnée peut devenir un vrai enjeu.
Ces problèmes se posent de manière plus aiguë dans le cas des « bases de données référentielles ». L’existence de
plusieurs bases de données relatives à un même ensemble d’information se heurte, plus ou moins tôt et avec plus ou moins
d’acuité, à un ensemble de problèmes critiques, dont les principaux sont :
Conflit d’identité. Le même objet possède des identités différentes selon les sources de données.
Par exemple, le client X est identifié par la clé X1 dans un référentiel et X2 dans un autre.
Conflit de schémas. Le même concept est modélisé de manière différente
Par exemple, le client est modélisé par le champ « customer » d’un coté, et par les deux champs « nom » et « prénom
» par ailleurs.
Conflit sémantique. Le même terme est interprété de manières différentes.
Par exemple, un « compte » est un compte courant bancaire dans une application et un identifiant utilisateur
permettant de gérer la sécurité des accès pour une autre.
Conflit de valeur. Le même objet a des valeurs différentes selon les sources.
La balance d’un compte courant apparaît différente suivant les bases dans lesquelles on le consulte.
Redondance de valeur. Le même concept est dupliqué dans plusieurs applications indépendantes.
Par exemple, le tarif catalogue des produits est représenté par N bases avec des recoupements sur certaines
catégories de produits.
Plus grande complexité du SI à assurer la sécurité, en ce qui concerne les habilitations.
Dans une configuration de redondance de valeur, le cas classique est d’interdire l’accès à une donnée dans telle base
en oubliant d’en interdire l’accès dans telle autre.
Plus grande complexité du SI à assurer les mises à jour.
Dans une configuration de redondance de valeur, nécessité de mettre à jour toutes les bases ou fichiers contenant
cette donnée via des passerelles compliquées entre les différentes sources de données.
Le besoin de référentiel provient donc de cette situation où plusieurs ensembles de données coexistent et où leur multiplicité
pose des problèmes de cohérence.

Master Data Management (DMD)
Les données obsolètes, incomplètes, inexactes ou en doublon nuisent à la réputation et à la performance globale de
l’entreprise impactant directement sa rentabilité : insatisfaction clients, non-conformité des données publiées,
perturbation du fonctionnement opérationnel, erreurs de stratégie, …
La gestion de la qualité des données est stratégique et elle peut reposer sur une démarche spécifique type « MDM »
s’articulant autour de trois axes :
1 - Organisation : mettre en place une cellule dédiée à la gestion des données, ayant une fonction transverse dans
l’entreprise. Son rôle est d’assurer la gestion des données et la bonne application des processus dans le temps.
2 - Processus : définir des processus métier qui garantissent la disponibilité, l’exactitude, la cohérence, l’auditabilité et la
sécurité de toutes les données de références de l’entreprise.
3 - Outil : Déployer une solution informatique robuste, capable de supporter les processus.
Avec un véritable outil de Master Data Management, on peut :

• gérer efficacement les relations avec les clients grâce à une meilleure visibilité de l'ensemble des systèmes
hétérogènes ;
• distribuer facilement les données de base à des systèmes déterminés, grâce au mécanisme "publier et s'abonner" ;
• réduire la duplication des données de base à l'échelle de l'entreprise étendue.
Parmi les outils, SAP NetWeaver Master Data Management vous permet de stocker, d'enrichir et de consolider les
données de base, tout en assurant leur distribution homogène à toutes les applications et à tous les systèmes de votre
environnement informatique. SAP NetWeaver Master Data Management devient ainsi le pivot qui permet de fournir aux
applications client de toute l'entreprise des informations cohérentes et homogènes.
4.4.1 Définition d’un référentiel

Un référentiel contient des informations de référence. Comment déterminer si une donnée est référentielle ?
Les différents critères d’éligibilité d’un référentiel sont les suivants :
La notion de partage : C’est le critère essentiel. Il répond aux besoins de partager des données communes à
plusieurs acteurs appartenant à des entités organisationnelles différentes afin de leur fournir une vision unique sur les
données constitutives du référentiel. Ainsi, lorsqu’une donnée est utilisée par au moins deux blocs fonctionnels, elle
doit être hébergée dans un référentiel.
La notion de stabilité : les informations de référence peuvent être caractérisées par une validité stable dans le temps
de leur définition. Par exemple, un cours de bourse ne sera pas une donnée de référentiel, alors que la devise d’un
pays sera un bon candidat.
Le partage entre plusieurs fonctions (au sens urbanisation : zone, quartier ou bloc) est donc un préalable à tout classement
d’une information dans la zone référentielle. Une information de référence est aussi principalement caractérisée par la
stabilité de sa définition et par un fort accès consultatif d’un point de vue applicatif.

4.4.2 Principaux types de référentiel
On peut distinguer deux grands types de référentiels de données :
Les référentiels contenant des données de production (on dit aussi données « vivantes »). Ces référentiels se
décomposent eux-mêmes en deux sous ensembles :
- Les référentiels contenant des informations élémentaires : les plus courants concernent les tiers (clients,
fournisseurs…), les contrats, les produits….
- Les référentiels contenant des informations de synthèse servant à la consolidation ou à l’obtention d’une
vision globale sur tel ou tel domaine d’activité.
Les référentiels contenant des données de type nomenclature (on dit aussi données « mortes »). Par rapport au
précédent groupe, leurs caractéristiques sont une plus grande stabilité des informations qu’ils contiennent et la
possibilité d’anticiper leur mise à jour qui n’intervient pas de façon aussi aléatoire. On les appelle aussi « tables de
référence ». Ils peuvent eux-mêmes se structurer en deux sous groupes :
- Référentiels d’origine interne à l’entreprise. Ce sont, par exemple, les référentiels des types de clients, des
types de fournisseurs ou type de pièces documentaires jointes…
- Référentiels d’origine externe à l’entreprise. Ce sont, par exemple, des référentiels devises, pays, taux,
calendriers…
Ces deux types ne sont pas équivalents : les données de type nomenclature constituent un « environnement » préalable,
nécessaire à la bonne exécution des traitements de production. Mais c’est surtout la fréquence de mise à jour qui est
discriminante pour établir cette typologie, ainsi que la fréquence de consultation de la donnée.
4.4.3 Métadonnées d’un référentiel

L’identification des données des référentiels s’accompagne de l’analyse des métadonnées permettant de décrire, stocker et
diffuser les caractéristiques des données.

Chaque référentiel est donc décrit par des métadonnées, ensemble d’informations concernant les données et leurs
processus de mise à jour associés. Les métadonnées précisent la sémantique et l’origine des données. Elles constituent une
véritable aide permettant de connaître l’information contenue dans les référentiels.
Les métadonnées sont typiquement :
Caractéristiques Signification
Que signifie cette donnée ? A quoi sert-elle ? (Ex : que signifie CA d’un client)
Toute information identifiée comme information de référence doit obligatoirement faire l'objet
d'une définition explicite permettant notamment :
Sémantique d'apporter une vision claire et précise du contour de cette information de référence
(aucune ambiguïté ne doit exister sur les limites et le contenu de cette information de
référence),
une adhésion de tous les « consommateurs » sur la définition et le contour qu'elle porte
(partage de la définition).
D’où vient-elle ? Où, par qui et quand a-t-elle été créée et mise à jour ?
Origine
(Ex : le CA provient directement des applications de vente des produits)
Qui en a besoin ?
Destination
(Ex : le CA est « consommé » par l’application de calcul des rétributions des agents)
Règles de calcul Comment la calcule-t-on ? (Ex : le CA d’un client)
Règles d’agrégation Quel est le périmètre de consolidation ? (Ex : le CA par semaine, mois, an)
Stockage, format Où et comment l’information est-elle stockée ? Son format ? (Ex : CA en euros HT )
Quelle est la personne responsable de cette donnée ?
Propriétaire Tout référentiel doit avoir un propriétaire désigné explicitement. Pour identifier le propriétaire d'un
référentiel, le principe de "primo-créateur" est à privilégier, à savoir que le propriétaire est au plus
proche de la création de l'information de référence.
Date de disponibilité et Quelle est la date de mise à disposition de la nouvelle valeur de cette donnée ?
période de validité des (Ex : CA hebdo mise à disposition le lundi matin 7h00, taux de valorisation interne le 2 janvier de
données chaque année…)
Etat global du référentiel : provisoire, en attente de validation, validé, actif, inactif...

Statut du référentiel
Le cycle de vie du référentiel est tracé.
4.4.4 Services d’accès aux référentiels

Il n’est pas envisageable, ni même souhaitable, de regrouper tous les référentiels dans une base unique centralisée.
Selon l’opportunité (au niveau applicatif, existence d’un PGI/ERP...) et selon les règles d’urbanisation en cours au sein de
l’entreprise, les référentiels peuvent être :
Soit portés dans les applications prenant en charge des fonctions du SI,
Soit présents dans des applications dédiées à la gestion de référentiels.
Pour chaque référentiel, il est nécessaire de bien identifier sa localisation physique et de développer une architecture
d'échange (normalisé et indépendant) d'informations entre les applications pour permettre la circulation des informations
présentes dans les référentiels.
Lorsque le nombre de consommateurs et de producteurs est important, les contraintes techniques des échanges deviennent
prépondérantes. Certains acteurs du SI vont alors se spécialiser dans la distribution de la donnée, c’est-à-dire dans la
gestion de la localisation des acteurs et l’orchestration des échanges de manière optimale.

L'application propriétaire doit fournir des services de connexion auprès des applications utilisatrices pour que ces dernières
puissent récupérer les données références. L'application utilisatrice doit avoir la capacité d'être cliente des services d’accès
mis en œuvre dans l'application propriétaire.
Pour des raisons techniques (par exemple, pour des raisons de type de plates-formes technologiques ou de performances
d’accès), on peut envisager de dupliquer un référentiel. Il faudra simplement prendre garde à distinguer le référentiel maître
de ses clones techniques dans les procédures de mises à jour et autres traitements de gestion.
Dans notre architecture SOA de référence (voir paragraphe 3.4), ces considérations donneraient les propositions
suivantes :
Création un ST d’accès à un référentiel distribué des éléments de nomenclature,

Mettre en place une synchronisation automatique entre ce référentiel et ceux du Host ou des partenaires.

Cependant, il est parfois nécessaire de gérer des références métiers au niveau du SE (problématique de gestion des
fabriques d’objets métiers). Dans ce cas, le SE gère son propre référentiel (mais idéalement sous forme de fichiers
.properties)
On voit que cette solution est très proche techniquement de celle retenue pour gérer les libellés. Il y a matière à capitaliser
sur les développements et les charges d’exploitation.
Référentiels et progiciels
La présence de progiciels au sein du SI est très structurante car les progiciels constituent des standards de fait avec
lesquels il faut composer, même pour la gestion des référentiels de données de l’entreprise.
Dans ce cas et en ce qui concerne les référentiels, le rôle de l’urbaniste sera d’assurer la coexistence des référentiels
propres à l’entreprise et ceux que le progiciel héberge dans une logique fonctionnelle parfois différente. Par exemple, le
client au sens du module Fi-Co du progiciel SAP ne porte pas la même sémantique de celui du référentiel client dans le
réseau d’agence.
Si un référentiel préexiste à la mise en place du progiciel, le problème du choix du progiciel à retenir se pose ainsi :
• Asservir le progiciel, pour les données de référence, au référentiel interne existant et garantir la correspondance à
tout instant entre les deux référentiels,
• Remplacer le référentiel existant par le progiciel (sous réserve de l’adéquation du modèle de données et des
fonctions de service du progiciel à un rôle de référentiel).
S’il n’y a pas de référentiel préexistant à la mise en place du progiciel, alors cette mise en place constitue, a priori, une
opportunité naturelle pour créer le référentiel. Dans ce cas, la démarche de choix du progiciel pourra intégrer les
contraintes propres aux besoins sur le référentiel, en plus des besoins métiers à couvrir par le progiciel.

4.5 Gestion des valorisations par défaut
Dans des contextes clients particuliers, il peut exister un besoin de gestion des valorisations par défaut de certains attributs
d’appel aux services. Par exemple, dans le cadre d’une entreprise d’assurance, certaines informations nécessaires au calcul
d’un DEVIS sont valorisées par défaut. Typiquement, il peut être facultatif de rentrer sa date de naissance pour demander et
13
obtenir un tarif de base pour l’assurance de son véhicule (ex : le site Assurland …).
Quatre scénarios d’implémentation d’une gestion normalisée des valeurs par défaut ont été étudiés dans l’architecture de
référence SOA (voir figure 7). On suppose ici la mise en place d’un référentiel des valeurs par défaut au sein d’une base
dédiée mais éventuellement esclave du référentiel géré sur le Host.
Scénario 1 : gestion par le SF

Le SF se charge de compléter les paramètres manquants (ici le paramètre « p3 » dans l’exemple).
Scénario 2 : gestion par un SF d’orchestration

Variante du scénario précédent, un SF supplémentaire fait appel au service transverse de recherche des valeurs par défaut
et combine les valeurs. L’avantage ici est de ne pas modifier le SF principal connecté au SE et le SF supplémentaire gérant
une orchestration peut être défini par les outils d’orchestration (la logique est externalisée).
13
http://www.assurland.com/

Scénario 3 : gestion par le SH
Le SH accepte des paramètres manquants et les complète lui-même. L’inconvénient ici est les modifications nécessaires à
apporter au niveau service Host. C’est le moins favorable des scénarios.
Scénario 4 : gestion par l’application elle même

L’application appelle directement le service transverse de récupération des valeurs par défaut.
La cinématique de ce scénario sera décrite ainsi :

L’application effectue les contrôles de surfaces et admet l’absence de paramètres d’entrée lors de la saisie.
Elle complète les informations manquantes via l’appel du service transverse ad hoc.
Elle continue le processus et appelle le SF avec l’ensemble des paramètres nécessaires.
Ce dernier scénario semble le plus optimisé. Sa solution technique se rapproche de celles choisies pour la gestion des
libellés et pour la gestion des valeurs de référence. Dans tous ces cas, il s’agit en effet de donner à l’application la possibilité
d’appeler un service en charge des conversions (d’un code vers un libellé, d’une valeur pour un code…).
4.6 Gestion des exceptions

La gestion des exceptions est également un point sensible dans une architecture SOA et plus généralement, dans toute
architecture distribuée. En effet, se pose la question de la remontée de l’erreur et de la transformation du code d’erreur en
libellé intelligible pour l’utilisateur.
En s’appuyant toujours sur notre modèle SOA, on peut identifier plusieurs sources potentielles d’erreur :
Les services HOST ou services partenaires peuvent retourner une erreur.

Les services SF, SE ou ST peuvent eux même rencontrer des cas d’erreur lors de leur traitement.

Les services doivent lever une exception qui sera ensuite traitée par l’application (par exemple : affichage d’un message à
l’utilisateur). Il faut aussi garder une trace de l’incident et écrire une trace en fichier de log.
Il s’agit donc de mettre en place comme briques d’infrastructure la base de log des exceptions traitées et la base des libellés
correspondant aux codes erreurs remontés.
4.7 Gestion de la sécurité

L’objectif de cette section est de se focaliser sur la gestion de la sécurité. En effet, une architecture SOA doit apporter une
réponse aux questions suivantes :
Comment s’assurer de l’identité du fournisseur de service ?

Comment prendre en compte les droits d’accès (habilitation) à un service ?
Comment s’assurer de la confidentialité des informations échangées lors des appels de services ?
etc…
Toutes les solutions « classiques » de sécurisation (d’un site web par exemple) peuvent se retrouver ici (sécurité par le
réseau, sécurité via les protocoles, systèmes externes d’authentification…). Cependant, la situation dans une architecture
SOA peut parfois être plus complexe, du fait de la composition des applications composites, de la multiplicité des
fournisseurs (internes, externes), etc.
Nous nous intéressons ici plus particulièrement aux fonctionnalités d’authentification et d’habilitation. Nous n’aborderons pas,
en revanche, les architectures de sécurité autour des problématiques de SSO, de gestion des certificats ou encore de la
signature électronique.
Concrètement, les points auxquels il faut pouvoir répondre est : Comment implémenter les principes de sécurité.
D’authentification ? (s’assurer que la personne connectée est bien celle qu’elle prétend être). Cela passe le plus
souvent par une phase de login (vérification du couple « User / Pwd », éventuellement couplée avec un SSO).
D’habilitation ? (s’assurer que la personne connectée ait bien les droits pour faire ce qu’elle désire). Cela passe par
la gestion d’un ensemble d’éléments caractérisant l’utilisateur (profil applicatif au sein d’un annuaire LDAP par
exemple) qui autorise ou interdit l’appel.
Les aspects « intégrité » des messages, « non répudiation » des traitements, et de « confidentialité » (via un cryptage par
exemple) sont ici exclus de notre analyse.

La manière la plus simple d’implémenter la sécurité au sein d’une SOA 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.

En ce qui concerne les standards du W3C, les aspects de sécurité sont pris en compte dans les spécifications de
WS-Security, framework de base pour la sécurisation des Web Services. Elle permet la mise en œuvre d’une
sécurité au niveau des messages échangés et non pas seulement au niveau du transport.
XML Encryption : Confidentialité des données transmises
Cette spécification assure la confidentialité des informations transmises en proposant d’utiliser un mécanisme de
chiffrement. Seule la partie utile (portant les données utilisateurs) est chiffrée dans le message SOAP. Le
mécanisme de chiffrage peut se baser au choix sur les maintenant bien maîtrisés systèmes de clef publique / clef
privée.
XML Signature : Non répudiation des messages et intégrité du contenu
Cette spécification assure non répudiation des messages. Egalement basée sur le principe des signatures et
certificats numériques, elle permet au système de garantir que l’émetteur du message est bien celui qu’il prétend
être et de plus, autant l’émetteur que le récepteur de l’échange, ne pourront nier avoir été acteurs de l’échange.
SAML : Gestion du SSO entre plusieurs appels à des services
Cette spécification assure qu’un client puisse utiliser plusieurs services sécurisés sans l’obliger à se ré-authentifier
à chaque appel.
WS-Security)
Security Assertion Markup Language (SAML)
XML Signature XML Encryption
SOAP
Dans le cas où les échanges entre partenaires sont nombreux (nombreux liens entre services appartenant
indifféremment à l’un des partenaires en réseau), il est souhaitable de mettre en place une extension de ces
mécanismes élémentaires vers une gestion plus globale de fédération d’identité (voir les spécifications Liberty ou
WS-Federation). Cette fédération d’identité facilite les échanges en faisant l’économie de répliquer les serveurs
d’identités (annuaires LDAP) entre partenaires.
4.8 Utilisation d’un bus de service

La mise en œuvre d’une SOA bénéficiera généralement de la mise en oeuvre simultanée d’une plate-forme d’échanges telle
qu’un bus de services (type ESB ou EAI). En revanche, c’est une option qui devient nécessaire lorsque le trafic augmente et
lorsque l’on veut mesurer la qualité de service, en particulier les temps de réponse, et superviser le fonctionnement global
des services.

En effet, SOA met à la disposition des urbanistes une nouvelle approche pour les échanges inter-applicatifs. Pour autant,
SOA ne veut pas dire remplacer tous les échanges par des interactions de services. Dans le choix de la bonne solution, le
rôle de l’urbaniste est de définir les modes d’interaction entre les parties prenantes, les échanges, ainsi que les conditions de
performance, de disponibilité, et de sécurité de ces interactions. Une fois les modes d’interaction explicités par l’urbaniste, il
appartient aux architectes techniques de définir la solution technique (EAI, ESB, orchestration,…) la mieux adaptée.
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 l’ESB (Enterprise Services Bus) qui, comme son nom l’indique,
se propose de mettre à disposition de l’entreprise des services partagés sur un bus.
SAM (Service Activity Monitoring) : la supervision des services

La supervision d’un service consiste à le surveiller et à réagir afin qu’il soit toujours en mesure de satisfaire les demandes
de ses clients (demandeurs du service). La supervision au sens large couvre alors le suivi du fonctionnement nominal, la
détection des erreurs, de la performance rendue et de la sécurité.
Un modèle connu consiste à suivre chaque service au moyen d’un agent de supervision (type JMX ou WMI). De cette
façon, chaque interaction avec le service (appel au service, retour d’appel, arrêt, démarrage) est tracé et les informations
de log peuvent être remontées vers une console de supervision centrale (par exemple : Tivoli, HP OpenView…)
La supervision SAM repose donc sur l’utilisation d’indicateurs résumant les mesures prises de manières unitaires sur
l’ensemble des services. La difficulté se situe alors dans le choix des bons indicateurs métiers ou techniques et il est
important de les implémenter de la façon la moins intrusive possible.
BAM (Business Activity Monitoring) : la supervision des processus métiers
La supervision des Processus métiers peut être vue comme le prolongement du SAM dans la mesure où les activités du
processus métier reposent sur l’exécution de services SOA. Les outils de BAM se baseront donc sur les fonctions
offertes par le SAM pour supporter la supervision de l’état des instances de processus (quelle étape, quel état, quel
délai ?), la création de statistiques et d’historiques (combien d’appels de services pour combien d’instances déclenchées,
dans quels délais … ?).

4.9 Préconisations d’organisation
Ce chapitre décrit une organisation type qui devrait être déployée afin d’aider à l’application des principes d’urbanisation et
de mise en place d’une SOA. Cette organisation peut prendre la forme d’un service, d’une cellule ou encore d’une équipe
composite.
La finalité de ce cabinet d’urbanisme (composé d’urbanistes et d’architectes) serait de maintenir le système d’information
dans la trajectoire établie et réviser périodiquement la cible et le plan de migration. Le cabinet d’urbanisme aurait
typiquement pour missions « régaliennes » de :
Piloter le plan d’urbanisation
• Lorsque nécessaire, une mise à jour du plan d’urbanisation peut être décidée. Ce type de situation se
produit lorsqu’un facteur amène à réviser la stratégie de manière significative (fusion, acquisition,
nouveaux métiers…). l faut alors en déduire les mesures de réalignement du S.I. cible et de la trajectoire
de convergence.
Créer, maintenir et publier le référentiel documentaire d’urbanisation
• Les différentes cartographies constituent un actif précieux pour l’entreprise, permettant notamment des
analyses d’impacts rapides et fiables et la formation rapide de nouveaux intervenants sur le système
d’information.
Conseiller maître d’ouvrage et maître d’œuvre
• Avec les maîtrises d’ouvrage, l’urbaniste joue un rôle de conseil et d’expertise. Il les aide à voir la valeur
ajoutée métier de leurs besoins fonctionnels, à cadrer ces derniers par rapport au schéma stratégique mis
en place par l’entreprise et à les classifier.

5 CONCLUSION
Les enjeux des SI modernes reposent définitivement sur la maîtrise de plusieurs composantes :
La maîtrise des métiers, des produits, des marchés : les SI doivent jouer un rôle majeur dans la mise en œuvre de la
stratégie métier de l’entreprise, dans sa conquête d’avantages concurrentiels et dans sa politique de différentiation.
La maîtrise du temps : les SI doivent être réactifs - sans sacrifier la vision à plus long terme et sans nuire à la
cohérence et à la qualité de service rendu aux directions opérationnelles.
La maîtrise des coûts : les SI doivent contribuer à la maîtrise globale des coûts (processus, organisation, ressources).
Ils doivent eux-mêmes être conçus et fonctionner en respectant ces efforts d’économie.
La maîtrise des risques : qu’il s’agisse des risques financiers, opérationnels ou technologiques, les SI doivent aider à
les identifier, à les mesurer et à les contrôler.
La maîtrise des technologies : sans céder aux effets de mode, il s’agit d’une part de se prémunir contre les risques
d’obsolescence et d’autre part de tirer profit des évolutions technologiques pour offrir un service différentiant et de
qualité.
SOA, nouvelle architecture du SI qui met l’accent sur la réutilisation, la standardisation des interfaces et la flexibilité, peut
clairement aider à atteindre ces objectifs.
Ses apports sont multiples :
Remettre la logique métier au cœur du SI

- Les processus métiers peuvent s’exprimer sous forme de services fonctionnels exprimant directement les besoins
métiers, indépendamment des considérations techniques opérationnelles.
- L’analyse des processus permet d’identifier les services métiers spécifiques (fonctionnels locaux, liés à des
règles de segmentation du métier) et les services mutualisables entre métiers (fonctionnels généraux ou
techniques).
Rationaliser et simplifier le SI existant et le SI cible
- La spécification de services élémentaires/fonctionnels généraux gomme les silos applicatifs.
- Le découplage entre applications, applications / données, données / données minimise les redondances et donc
les risques d’incohérence.
La qualité intrinsèque de SI est améliorée

- L’architecture de services permet de piloter le SI sur la base de contrats de services pour répondre à deux enjeux
: l’optimisation des relations transverses entre SI (« interopérabilité » entre blocs applicatifs) et la réduction des
coûts par réutilisation de composants (à l’intérieur d’un même bloc applicatif pour des composants métiers ou de
manière transverse pour des composants techniques).
Les développements s’en trouvent accélérés

- Les cycles de développements sont raccourcis : le développement de composants de services réutilisables
focalise sur la construction de services nouveaux par combinaison d’éléments fonctionnels ou techniques
existants.
- L’intégration est facilitée : les services peuvent être intégrés à l’infrastructure via les ESB.
L’implémentation privilégiée d’une SOA reste les Web Services. Cependant, si les Web Services sont souvent une approche
intéressante, ils ne sont pas forcément adaptés à toutes les situations (notamment si besoin de transaction globale ou de
performance critique). En ce qui concerne leur mise en œuvre, il faut être vigilant sur la définition des services (règles
d’identification des services à mettre en œuvre et surtout partage de l’information entre les membres des équipes projet). Par
ailleurs, la gestion des transactions et de la sécurité restent, à ce jour, incomplètes, même si les spécifications du W3C
avancent sur ce sujet. Enfin, la mise en place de services externes (via des partenaires) nécessite une infrastructure lourde
pour pouvoir supporter les contraintes de monitoring ou de sécurité.
En complément d’une approche SOA et au delà du seul système d’information, la démarche d’urbanisation fournit au
management les moyens pour modéliser leur vision d’avenir de l’entreprise et faire partager cette vision à l’ensemble des
acteurs de l’entreprise.

La trajectoire d’urbanisation, couplée à une démarche SOA, permettra donc de passer progressivement d’un ensemble de SI
qui suivent chacun leur propre logique et présentant de nombreuses redondances, à un unique SI aligné avec la stratégie
globale de l’entreprise et facilitant la maîtrise des coûts et des risques.
La seule volonté du Groupe AUBAY est d’aider

ses clients et partenaires
à atteindre plus facilement cet objectif.

6 REFERENCES
[1] Club URBA-EA (« Urbanisme des SI - Enterprise Architecture »)

Ouvrage « Définition et mise en œuvre du plan d’urbanisme »
[2] Dunod – Management des systèmes d’Information

Ouvrage « SOA le Guide de l’Architecte »
[3] CRI Ouest – intervention Aubay 2004

Ouvrage « WebService : mise en œuvre dans un SI »
[4] AGF – intervention Aubay 2006

Ouvrage « GUPA : Guide d’Urbanisation – Principes d’Architecture »
[5] GMF – intervention Aubay 2007

Livre Blanc « Accompagnement de la démarche SOA »
[6] IBM – SOA Technology Summit 2005

Présentation “Moving ahead with SOA” (et autres présentations).
[7] IBM – WebSphere Software

Présentation et white paper WPS.
[8] OCTO Technology

Livre blanc” Architecture Orientée Services - Une politique de l’interopérabilité”
[9] IBM – WebSphere Software

Red book ” Implementing SOA using an ESB” (et autres redbooks)

7 GLOSSAIRE
BAM Business Activity Monitoring

DMZ DeMilitarized Zone
EAI Enterprise Application Intergration

EJB Enterprise Java Beans
ESB Enterprise Service Bus
IHM Interface Homme-Machine

LOLF Loi Organique relative aux Lois de Finances
MDM Master Data Management

MOM Middleware Orienté Message
POS Plan d’Occupation des Sols
QoS Quality of Service
SA Service Applicatif
SAM Service Activity Monitoring
SE Service Entité
SF Service Fonctionnel
SH Service Host
SOA Services Oriented Architecture
SOAP Simple Object Access Protocol

SOMA Service Oriented Modeling and Architecture
SOX Sarbanes-Oxley
ST Service Transverse (ou Technique)
WSDL Web Services Description Language
WSRR WebSphere Service Registry and Repository – IBM©

XA Interface de communication entre ressource et transaction

Livre Blanc « Urbanisation et SOA »
© 2008 AUBAY. Tous droits réservés

Imp Soa 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Imp Soa 1

Transféré par

Droits d'auteur :

Formats disponibles

URBANISATION & ARCHITECTURE

ORIENTÉE SERVICE (SOA)

Bibliographie : Livre blanc ECM (2006), Livre Blanc EAI (1999).

Ont également participé à la constitution de ce livre blanc :

Pour tous renseignements complémentaires : cdevaux@aubay.com ou pesteves@aubay.com

Urbanisation & Architecture Orientée Service (SOA) - 2

Urbanisation & Architecture Orientée Service (SOA) - 3

Urbanisation & Architecture Orientée Service (SOA) - 4

Le présent livre blanc est composé de 3 chapitres.

Urbanisation & Architecture Orientée Service (SOA) - 5

Urbanisation & Architecture Orientée Service (SOA) - 6

Deux grandes préoccupations vont ainsi guider la démarche d’urbanisation :

Urbanisation & Architecture Orientée Service (SOA) - 7

Cohérence forte / couplage faible

2.3 Règles d’or de l’urbanisation

Urbanisation & Architecture Orientée Service (SOA) - 8

R2 : Limiter les nouveaux développements

Urbanisation & Architecture Orientée Service (SOA) - 9

R4 : Partager les données communes

R5 : Partager les traitements métiers

Urbanisation & Architecture Orientée Service (SOA) - 10

Urbanisation & Architecture Orientée Service (SOA) - 11

3.1 Concept de service

Un service est donc une prestation élémentaire :

Urbanisation & Architecture Orientée Service (SOA) - 12

Concrètement, un service, c’est l’ensemble de composants suivants :

Urbanisation & Architecture Orientée Service (SOA) - 13

3.2 Fiche signalétique d’un service

Elle reprend l’ensemble des éléments suivants :

3.3 Contrat de service

Concrètement, le contrat de service se compose donc des éléments suivants :

Politique d’administration (suivi qualité de service)

Urbanisation & Architecture Orientée Service (SOA) - 14

Exemple de description WSDL d’un service de contrôle d’une adresse postale :

3.4 Un exemple de modèle SOA

Urbanisation & Architecture Orientée Service (SOA) - 15

3.5 Typologie de services

3.5.1 Service Applicatif (ou Use Case) 9

Urbanisation & Architecture Orientée Service (SOA) - 16

Le Service Entité expose les opérations basiques suivantes :

Créer un nouvel objet métier dans le référentiel concerné.

Urbanisation & Architecture Orientée Service (SOA) - 17

3.5.4 Service Transverse (ou Infrastructure)

3.5.5 Service Host

3.6 Identification des services

Urbanisation & Architecture Orientée Service (SOA) - 18

Analyse des processus métiers (ou approche Top-Down)

La première étape « identification des services candidats » peut suivre 3 approches.

Enfin, l’Analyse des systèmes existants passera par :

Urbanisation & Architecture Orientée Service (SOA) - 19

Urbanisation & Architecture Orientée Service (SOA) - 20

Figure 13 : Exemple de diagramme d’architecture applicative (sous MEGA)

Figure 14 : Description complète d’un composant SF

Ces informations seront évidement exposées et consultables via un site Intranet.

Figure 15 : Exemple de site Web contenant le référentiel SOA (sous MEGA)

Urbanisation & Architecture Orientée Service (SOA) - 21

Urbanisation & Architecture Orientée Service (SOA) - 22

Urbanisation & Architecture Orientée Service (SOA) - 23

4.1 Gestion des versions & variantes

Les solutions envisageables sont les suivantes :

Urbanisation & Architecture Orientée Service (SOA) - 24

4.2 Gestion des libellés

Scénario 1 : gestion du libellé au niveau SF