SUJET : Conception et Développement d’un SOA autour

Des démarches administratives

Architecture multi niveau (N-Tier)

Haute disponibilité
Séparation en couche
Sécurité
N-Tier
Pare feu applicatif
Système d'authentification unique (SSO)
Service mandataire
Portail de service
Application composite
Plate forme applicative

Infrastructure
 N-tiers
Publique
Internet, pare jeux principale
Présentation
SSL: Passage HTTPS vers HTTP
Firewall applicatif
Répartiteur de charge
Réverse proxy/Réécriture HTML
Serveur de présentation
Proxy CAS
Application
Cas
Proxy LDAP
Serveur d'application (PHP, Typo3, Java,
etc.)
Serveur de cache (Pour PHP)
Interne
 • Service Provider

• Underlying Capability

• Service Bus

• Service Consumer
• The Service A definer pour SOA !!

• Service Invocation

• Service Interface

• Loosely coupled

• Registry

• Service Level Agreement (SLA)

Qu’est ce qu’un SOA ?

Pourquoi SOA ?

Quelles sont les propriétés d’un SOA, Architecture ?

Pertinence de l’utilisation du modele SOA tel quel ?

Comment mettre en place une interface pour un service donné ?

PROBLEMATIQUE
A un moment ou l'autre de son existence, chaque citoyen est amené à entreprendre des démarches
administratives.

De la naissance au décès, des évènements heureux ou malheureux amènent des démarches

administratives. Le citoyen doit également demander à l'administration communale des actes ou
documents. Plusieurs décisions ont été prises en ce sens, afin que l’information soit disponible pour
le citoyen plus facilement, sans trop de tracas et de difficultés.

Le site des démarches administratives mis en place par l’ADIE, s’inscrit dans la vision e-citoyen qui
constitue un des nerfs de guerre de la dite structure. Ce site répertorie environ 200 démarches
actuellement, mais devra à terme regrouper la totalité des démarches administratives connues qu’elles
soient pour un particulier ou une entreprise. Demain, les citoyens auront la possibilité de traiter leurs
diverses démarches directement en ligne sans pour autant avoir à se déplacer comme c’est
aujourd’hui le cas. Il s’agit des télé-procédures dont le premier jalon a été posé avec la télé-
déclaration de TVA qui est actuellement utilisée par les entreprises du CGE.

Le citoyen a à disposition plusieurs moyens de récupérer l’information, que se soient sous format
papiers, soient au format électronique. Les supports intervenant à cet effet sont nombreux et
diversifiés avec notamment le plus usité : l’ordinateur.

Il existe aussi la télévision, les téléphones portables, les bornes tactiles etc. …

Ce mémoire s’inscrit dans la facilitation de l’accès aux informations pour le citoyen. Il s’agira
donc de trouver les voies et moyens, qui permettront d’utiliser pleinement les périphériques cités plu
haut.

L'objectif étant de véhiculer l’information, quel que soit la plateforme utilisée.

L'architecture orientée services ambitionne justement d'aider les développeurs à gérer l'hétérogénéité
des « milieux applicatifs » .

Certaines procédures peuvent aujourd'hui, en tout ou en partie, être consultées sur le site des
démarches administratives.

La dématérialisation permet de simplifier la relation entre les usagers et l’administration. Elle est
aussi un puissant levier pour améliorer l’efficacité du service rendu en évitant ainsi

Dans les architectures informatiques traditionnelles, les processus métier, les applications et les
données sont souvent enfermés dans des silos indépendants et incompatibles, chers à maintenir et
obligeant les utilisateurs à naviguer entre divers réseaux, applications et bases de données afin
d'effectuer des tâches bien spécifiques.

INTRODUCTION
(ARCHITECTURE ORIENTEE SERVICES POUR DISPOSITIFS ET INFORMATIQUE AMBIANTE)

L’avènement de nouveaux usages de l’informatique dite mobile et ambiante ne permet plus de

concevoir des applications logicielles dédiées à des plates-formes prédéfinies, standardisées,
composées d’un ensemble de dispositifs qui sont a priori connus. Les logiciels nécessitent toujours
plus de capacité d’adaptation face à une multitude de contextes d’utilisation. Que dire alors de l’enjeu
proposé par une informatique qui se voudrait adapter dynamiquement une application logicielle à un
environnement d’exécution découvert dynamiquement, évoluant tout aussi dynamiquement, et
partiellement connue à priori.

Le paradigme qui permet de gérer une telle application par assemblage de composants se révèle alors
particulièrement pertinent lorsqu’il est associé à un ensemble de composants orientés services pour la
découverte dynamique de dispositifs.
La notion de SOA (Architecture Orientée Services) définit un modèle d'interactions au niveau
logiciel mettant en oeuvre des connexions entre des composants logiciels « fournisseurs » à
l'attention de composants logiciels « consommateurs ». Cette approche a largement été adoptée pour
le développement de systèmes de traitement de l’information favorisant par là même, la distribution
de fonctionnalités indépendantes, leur réutilisabilité et leur intégration [1] [2] [3].
La notion de Web Service caractérise un service auquel on accède par n'importe quelle technologie «
Web », en grande partie pour assurer l’indépendance entre l’implémentation du service et les
technologies de communication utilisées (couche session par HTTP et représentation des données
basés sur XML).

La notion de Web Service pour Dispositifs s’inscrit donc dans cette double démarche tout en
nécessitant des améliorations significatives. Un certain nombre de travaux ont exploré ce concept de
service pour dispositifs notamment pour favoriser une approche SOA plus adaptée aux systèmes
interactifs. En effet, les Web Services pour Dispositifs doivent intégrer une phase de recherche et de
découverte de services [4], que ce soit sur un réseau personnel ou local, ou plus largement sur un
réseau d'entreprise.
Pour les services découverts, on obtient une description, en général au format XML, qui reprend les
principes d’un Web Service classique. Une autre particularité des Web Services pour Dispositifs est
la notion indispensable d'évènements. Dans les Web Services classiques, les communications se font
de manière synchrone par requête/réponse. Un dispositif doit quant à lui pouvoir signaler un
changement d’état pour garantir une meilleure réactivité.

Mieux développer, et surtout mieux maintenir les fonctionnalités conçues : voici deux objectifs de
l'architecture orientée services.

Cette nouvelle couche d'abstraction fait suite à d'autres abstractions créé au fur et à mesure des
besoins et des avancées technologiques : la création des fonctions et procédures, la programmation
orientée Objet, les logiciels à base de composants.

L'architecture orientée services ambitionne d'aider les développeurs à gérer l'hétérogénéité des
"milieux applicatifs" : l'objectif est d'autoriser les applications ou service à communiquer et de travail
ensemble, quel que soit leur plate-forme respective.

La SOA promet donc l'interopérabilité des applications par le biais de services. Un service qui n'est
rien d'autre qu'un composant dont les interfaces et contrats d'utilisation sont connus, et qui est
indépendant de tout système. Pour ce faire, XML est utilisé dans lors des échange d'informations,
enrobé le plus souvent d'une enveloppe SOAP (lire notre article du 7 juillet 2005).
Plus généralement, une architecture SOA peut être construire sans utiliser XML ni les services Web,
mais avec des formats de type CVS, ou des technologies comme Corba ou COM/DCOM, mais XML
offre certainement une plus grande ouverture.

L'architecture en elle-même se représente en faisant intervenir trois acteurs : le consommateur, le

service, et le répertoire de services. Le consommateur correspond à l'application cliente (ou à un
autre service), qui fait appel au service pour une tâche précise. Ce consommateur trouvera les
informations à propos du client au sein du répertoire de services, où sont enregistrés et triés un
grand nombre de ceux-ci. Un répertoire peut être privé, c'est-à-dire interne à l'entreprise, ou public.

Le service répond à trois fonctionnalités caractéristiques : il est indépendant, il peut être découvert et
appelé de manière dynamique, et il fonctionne seul.

Le répertoire de services a un rôle primordial dans la SOA. C'est lui qui reçoit la requête du
consommateur, lui qui découvrira le service idoine, et lui qui agira en tant que proxy
(intermédiaire) entre consommateur et service. En s'assurant que les fournisseurs de
services informent régulièrement les répertoires de leurs nouveautés, le consommateur
peut constamment profiter de celles-ci sans pour autant devoir mettre à jour ses
méthodes.
Ainsi, une banque pourra mettre à jour son service de calcul d'intérêt, et si celui-ci est
enregistré correctement sur un répertoire (public ou privé), l'utilisateur pourra sans rien
changer profiter des évolutions.

Le tout enfin, enfin, repose fondamentalement sur les services Web. La SOA utilise tous
les standards dédiés aux services Web (XML, HTTP, WSDL, UDDI, SOAP...) pour s'assurer
de l'interopérabilité de son fonctionnement. Ce n'est pas pour autant qu'ils sont
synonymes : une SOA n'est pas en soi une technologie, mais un principe de conception,
tandis que les services Web en sont une implémentation technologique.

Architecture orientée services

L'architecture orientée services (calque de l'anglais Service Oriented architecture, ou SOA) est
une forme d'architecture de médiation qui est un modèle d'interaction applicative qui met en œuvre
des services (composants logiciels) :

• avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent
XML),
• et des couplages externes "lâches" (par l'utilisation d'une couche d'interface interopérable, le
plus souvent un service web WS-*).

Le service est une action exécutée par un « fournisseur » (ou « producteur ») à l'attention d'un
« client » (ou « consommateur »), cependant l'interaction entre consommateur et producteur est faite
par le biais d'un médiateur (qui peut être un bus) responsable de la mise en relation des composants.

Ces systèmes peuvent aussi être définis comme des couches applicatives.

L'architecture orientée services est une réponse très efficace aux problématiques que rencontrent les
entreprises en termes de réutilisabilité, d'interopérabilité et de réduction de couplage entre les
différents systèmes qui implémentent leurs systèmes d'information.

Les architectures SOA ont été popularisées avec l'apparition de standards comme les Services Web
dans l'e-commerce (commerce électronique) (B2B, inter-entreprise, ou B2C, d'entreprise à
consommateur), basés sur des plates-formes comme J2EE ou .NET et la déclinaison libre Mono de
cette dernière.

Elles mettent en application une partie des principes d'urbanisation.

Au sein de l'architecture orientée services, on distingue les notions d'annuaire, de bus, de contrat et de
service, ce dernier étant le noyau et le point central d'une architecture orientée services.

Le service étant à grandes mailles, il englobe et propose les fonctionnalités des composants du
système. La SOA est un concept d'architecture, la WSOA (WebService Oriented Architecture) en est
sa déclinaison ou plus précisément son implémentation avec des WebService.

Exemple
On peut citer la SNCF, qui a mis en place une architecture de type SOA pour son système de
réservation (recherche d'horaire, demande de tarif, réservation...) qui prend en charge à la fois les
terminaux des guichets des agences et gares, et les sollicitations de son site web de commande en
ligne.

Description de l'architecture
L'annuaire de services

L'annuaire de services référence l'ensemble des services (et des contrats associés) disponible au sein
du SI, il participe ainsi activement à la mise en œuvre d'une cartographie dynamique du SI. Dans un
modèle de bus, l'annuaire peut être auto-alimenté par le service (enregistrement). Les annuaires
UDDI forment aujourd'hui le standard de référencement des services.

Le bus de service

Dans une architecture SOA, le bus a un rôle de médiateur (middleware) entre le consommateur et le
producteur du service, il permet ainsi de réaliser le couplage lâche. Le bus peut aussi fournir une
gamme de services :

• sur la base des patterns EIP (Enterprise Integration Pattern), fournir des fonctionnalités de
split, combine, etc. permettant de combiner l'appel sur plusieurs services,
• des fonctionnalités de versioning de service,
• des fonctionnalités de supervision et contrôle (avec SLA) des services.

Le service

Le service est un composant clef de l'Architecture Orientée Services. Il consiste en une fonction ou
fonctionnalité bien définie. C'est aussi un composant autonome qui ne dépend d’aucun contexte ou
service externe.

Une architecture orientée services consiste essentiellement en une collection de services qui
interagissent et communiquent entre eux. Cette communication peut consister en un simple retour de
données ou en une activité (coordination de plusieurs services).

Un service est une entité de traitements qui respecte les caractéristiques suivantes :
 • Grande Maille (coarse-grained) : Les opérations proposées par un service encapsulent
plusieurs fonctions et opèrent sur un périmètre de données large au contraire de la notion de
composant technique.
• Interface : Un service peut implémenter plusieurs interfaces, et aussi plusieurs services
peuvent implémenter une interface commune.
• Localisable : Avant d’appeler (bind, invoke) un service, il faudra le trouver (find).
• Instance unique : A la différence des composants qui sont instanciés à la demande et peuvent
avoir plusieurs instances en même temps, un service est unique. Il correspond au design
pattern Singleton.
• Couplage faible (loosely-coupled) : Les services sont connectés aux clients et autres services
via des standards. Ces standards assurent le découplage, c'est-à-dire la réduction des
dépendances. Ces standards sont des documents XML comme dans les web services.
• Synchrone ou Asynchrone.

Les protocoles et les normes

Les architectures SOA reposent principalement sur l’utilisation d’interface d’invocation (SOAP) et
de vocabulaire de description de données (WSDL et XML) qui doivent être communs à l’ensemble
des agents (fournisseurs de services et utilisateurs de services).
Ce dispositif permet de réutiliser les applicatifs métiers, le but étant de permettre à l’entreprise de
s’adapter rapidement à un nouveau contexte de marché.

En terme d'intéropérabilité, les architectures SOA reposent en partie sur les normes décrites à travers
le WS-I.

Parmi les différentes couches de normes et protocoles qui permettent de bâtir de telles architectures,
on relève :

• la gestion d'un annuaire de services (quels sont les services mis à disposition et par qui)
avec : UDDI (Universal Description Discovery and Integration) normalisé par l'OASIS,
• la description des interfaces des services (quelles sont les données nécessaires à l'exécution
du service, que fournit-il en retour, ...) avec : WSDL (Web Services Description Language)
recommandé par le W3C,
• l' invocation (ou l'appel) du service (la requête transmise au service) avec : SOAP (Simple
Object Access Protocol) recommandé par le W3C,
• le format des données échangées avec : XML (eXtensible Markup Language) recommandé
par le W3C,
• et enfin, le transport des données avec les protocoles internet : HTTP et TCP/IP qui sont des
normes RFC.

Une architecture SOA pourra être également complétée par :

• la gestion de la sécurité avec : SSL (Secure Sockets Layer), XML Signature, XML
Encryption, SAML (Security Assertion Markup Language) ou encore XKMS (XML Key
Management Specification, qui gère les infrastructures à clé publique ou PKI)
• l' orchestration (on parle également de chorégraphie) des services pour constituer des
processus métier avec : BPEL4WS (Business Process Execution Language For Web Services)
devenu WS-BPEL et qui est un dérivé à la fois de WSFL (Web Services Flow Language)
d'IBM et de XLang de Microsoft qu'il a remplacé, devenant de fait le standard de
l'orchestration des services web. On peut aussi citer WSCI (Web Services Choregraphy
Interface). L'orchestration suppose l'existence d'un chef d'orchestre (WS-BPEL est un langage
d'orchestration), tandis que la chorégraphie implique des interactions pair-à-pair. WS-CDL
 (Web Services Choregraphy Description Language) est un exemple, le plus récent, d'un tel
langage.
• la gestion transactionnelle (gestion du two-phase commit pour la mise à jour contrôlée de
plusieurs bases de données réparties entre plusieurs fournisseurs de services : la transaction
« attend » de recevoir l'acquittement (le commit) des différents serveurs sollicités et en cas de
problème avec l'un d'eux, est en mesure de demander aux autres serveurs de « défaire » les
mises à jour partielles effectuées afin de maintenir l'intégrité des données) : WS-Transaction
d'IBM, XAML (Transaction Authority Markup Language) ou encore BTP (Business
Transaction Protocol).

A quelles technologies s'adosse une architecture de type SOA ?

Apparues assez récemment sous l'impulsion de plusieurs grands éditeurs (dont Microsoft, IBM et
Sun), les interfaces XML de type Web Services reposent une bibliothèque de standards conçus
précisément pour construire une architecture orientée services. Les uns couvrant les questions
d'invocation de composants (WSDL, etc.), les autres les problématiques liées au transport et à la
description des informations transmises (SOAP, etc.).

Force est de constater que des technologies plus anciennes (nées à la fin des années 1990)
poursuivaient les mêmes objectifs. Les plus connues d'entre-elles sont Corba et DCOM. Ces
alternatives qui peuvent se révéler intéressante pour certains projets n'en demeurent pas moins
limitées : à la différence des Web Services, elles restent cantonnées à des environnements d'exécution
bien particuliers - les serveurs d'applications J2EE pour Corba et les systèmes Microsoft dans le cas
des composants DCOM.