Chapitre 3: SOA et Services
Web
Matière: SOA (Architecture Orienté Service)
Enseignante: Nourhene Ellouze
Niveau: GLSI3
Plan
1. Introduction
2. SOA
▪ Principes
▪ Services
▪ Implémentation
3. Services Web SOAP
▪ SOAP
▪ WSDL
▪ UDDI
▪ Standards WS-*
▪ Développement des services web
2
1. Contexte et Motivations
3
Introduction
▪ Depuis la fin des années 1990 et dans les années 2000 :
▪ Un fort développement d'internet, de la dématérialisation et de la production des biens
immatériels.
▪ Les besoins de l’entreprise et de leurs clients augmentaient d’une manière excessive
▪ Les développeurs d’application dans une entreprise se retrouvaient en défi face
à deux situations nécessitant un grand changement :
▪ Situation interne qui nécessite un changement
▪ Situation externe qui procure de nouvelles exigences
4
Introduction
Situation interne qui nécessite un changement
▪ Des systèmes composés de dizaines voire de centaines d’applications qui :
▪ Utilisent différents protocoles de communication.
▪ Utilisent des formats de messages (de données) différents.
▪ Se retrouvent dans des serveurs locaux ou distants.
▪ Sont écrites dans des langages différents (Java, C#, C++, Python ou pire encore COBOL, ...)
▪ Problèmes :
▪ Comment faire communiquer l’application développée avec les autres ? Ou pire encore comment
faire communiquer toutes les applications entre elles ?
▪ Comment identifier les produits et fonctionnalités déjà implémentés dans d’autres applications
pour pouvoir les réutiliser et éviter de les réimplémenter à nouveau pour gagner à la fois du
temps et éviter la redondance ?
▪ Comment localiser les applications (déterminer leurs URL ou leur IP) pour pouvoir communiquer
avec elles ? Et pire encore comment faire si une application change d’adresse ?
▪ Comment faire tourner les applications même en absence ou défaut de connexion réseau ? 5
Introduction
Situation externe qui procure de nouvelles exigences
▪ Nouvelles exigences
▪ Changement du créneau commercial actuel,
▪ Augmentation des contraintes de concurrence,
▪ Évolution et bouleversement des besoins du client,
▪ Evolution rapide de la technologie de l’information.
▪ Problématiques et exigences:
▪ Comment développer et mettre en place des systèmes flexibles qui peuvent rapidement
s’adapter avec le changement de l’environnement du commerce pour qu’il permet à
l’entreprise d’y garder sa place.
▪ Comment concevoir et développer des produits réutilisables afin d’éviter les remises en
cause de l’existant à chaque fois qu’il y a de changements.
▪ Comment permettre l’interaction avec le système à travers des moyens et outils très
simples. 6
Historique
▪ En 1992, une nouvelle vision de l'architecture du traitement de l'information
en entreprise a été développée afin de régler la problématique de l'accès et de
l'intégration de l'information en introduisant la notion de médiateur.
▪ Apparition des architectures d’intégration basées sur une brique de médiation
entre applications « médiateur » qui sont appuyées par des outils d’intégration
de type EAI.
▪ Un médiateur est un composant logiciel qui exploite des connaissances
encodées concernant un ensemble de données et crée les informations
nécessaires à une couche de niveau supérieur d'une application.
7
Historique
▪ En 1996, les bases de la SOA ont été fondé "Gartner Group " en exploitant
l’idée de médiateur
▪ ESB (Entreprise Service Bus) joue le rôle du médiateur entre services
▪ La technologie ESB est l’héritière de l’EAI
▪ L'exploitation de cette architecture n'a commencé à apparaître qu'à partir de
l'année 2000 après le succès du langage XML (apparu en 1998).
▪ En fait le terme SOA n'est popularisé qu'à partir de l'année 2002 après
l'orientation de beaucoup d'entreprises commerciales vers cette architecture.
8
Historique : Evolution des applications
Une Application découpée par
des services techniques reliés
par un bus d’intégration
Connecteur Connecteur pour Connecteur pour
envoie EMAIL
Une grosse application pour envoie SMS paiement (Paypal)
Connecteurs
pour SMS, EMAIL
et paiement
Interfaces web
Base de données
API REST/SOAP
Entreprise Service Bus
Interfaces
Base de API REST/SOAP
web données
Clients Clients
Architecture dite Architecture
« Monolithique » Orientée Service
9
2. Principes SOA
10
SOA: Définition
▪ L'architecture orientée services (SOA: Service Oriented Architecture) constitue
un style architectural de développement et d'intégration dynamique des
applications d'entreprise.
▪ SOA se base sur la notion de service qui est considéré comme la brique de base
de cette architecture
▪ SOA est une réponse très efficace aux problématiques que rencontrent les
entreprises en terme de réutilisabilité, d'interopérabilité et de réduction de
couplage entre les différents systèmes qui implémentent leurs SI
11
SOA: Définition du groupe « Gartner »
▪ L’architecture orientée service constitue un style d’architecture basée sur le
principe de séparation de l’activité métier en une série de services.
▪ Ces services peuvent être assemblés et liés entre eux selon le principe de
couplage lâche pour exécuter l’application désirée.
▪ Ces services sont définis à un niveau supérieur à celui de l’approche «
Composant » traditionnelle.
12
SOA : Paradigme
▪ Le paradigme SOA : Chercher, Publier et Consommer
▪ Publier (Publish): le fournisseur publie l'information sur son service.
▪ Chercher (Search): le client cherche un service approprié.
▪ Consommer (Consume/ Bind): le client consomme le service.
Annuaire /Entrepôt
Consommateur du
Service cherche un Fournisseur du Service
service répondant à ces publie son service via le
exigences (Un contrat lui contrat
est retourné) Chercher 2
1 Publier
Fournisseur
Consommer Contrat du Service
3
Consommateur du Service envoie des
Consommateur messages (respect du contrat) au
du Service fournisseur du Service 13
SOA : Architecture
▪ L'architecture SOA repose sur un ensemble d’acteurs et éléments standardisés :
▪ WSDL: Web Service Description Language.
▪ SOAP: Simple Object Access Protocol.
▪ UDDI: Universal Description Discovery and Integration.
▪ ESB : Enterprise Service Bus
Annuaire /Entrepôt
UDDI
Consommateur du
Service cherche un WSDL Fournisseur du Service
service répondant à ces publie son service via le
exigences (Un contrat lui contrat
est retourné) Chercher 2
1 Publier
SOAP
WSDL Fournisseur
Consommer Contrat du Service
3
ESB
Consommateur du Service envoie des
Consommateur messages (respect du contrat) au
du Service fournisseur du Service 14
SOA : Architecture
▪ Les acteurs :
▪ Le fournisseur de service (Service Provider ) : est chargé de :
1. Définir le service: implémentation, description, contrat d'utilisation.
2. Publier sa description dans l’annuaire
3. Réaliser les opérations
▪ L’annuaire (Entrepôt) (Discovery Agency) : est chargé de :
1. Recevoir et enregistrer les descriptions de services publiées par les fournisseurs
2. Recevoir et répondre aux recherches de services lancées par les clients
▪ Le client (Service Requestor) : peut
1. Lancer la recherche sur un service approprié.
2. Obtenir la description du service grâce à l’annuaire.
3. Utiliser le service.
15
SOA : Architecture
▪ Les éléments de base standardisés :
▪ Service: "Un service est un comportement défini par contrat, qui peut être réalisé et
fourni par tout composant pour être utilisé par tout composant sur la base unique du
contrat "
▪ Annuaire (UDDI) : liste dynamique de recherche de descriptions de services dans
laquelle les fournisseurs de services publient leurs descriptions.
▪ Contrat (description WSDL) : contient la description du service et de son utilisation,
échangée entre le fournisseur de service et le client.
▪ Bus (ESB : Enterprise Service Bus) : le moyen par lequel s'effectue la communication
entre le client et le fournisseur du service. Son but est avant tout de permettre la
communication des applications qui à la base ne sont pas pensées pour fonctionner
ensemble.
▪ SOAP (Simple Object Access Protocol) : Protocole de communication a sein de la SOA.
16
Les services
17
Qu’est-ce qu’un service ?
▪ Un service est un comportement défini par contrat, qui peut être réalisé et fourni par tout
composant pour être utilisé par tout composant sur la base unique du contrat
▪ Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur
ajoutée d’un domaine métier
▪ Huit aspects caractérisant un service
Dans la suite nous
détaillons chaque aspect
d’un service
18
Service : Contrat standardisé
▪ Les services d’un même Système Technique sont exposés au travers de contrats
respectant les mêmes règles de standardisation.
▪ Contrat, entre le fournisseur de service et le consommateur de service, composé de :
▪ Un contrat syntaxique proposant une représentation technique du service
→ C’est le contrat d’utilisation du service (son interface) qui spécifie le nom du
traitement, les opérations, les messages d’entrée, les messages de sortie,…
▪ Un contrat sémantique spécifiant une description informelle du traitement
→Il précise les règles et les contraintes d’utilisation du service
▪ Un contrat qualité (niveau) de service (QoS et SLA) précisant les engagement de service
→ Il précise, par exemple, le temps de réponse attendu, procédures en cas de panne,
temps de reprise après interruption,…
19
Service : Contrat standardisé (Exemple)
▪ Pour un service web, son contrat peut être formé comme suit :
▪ Un document WSDL décrivant l’interface du service (les modalités d’accès) → fait partie du contrat syntaxique.
▪ Un ensemble de schémas XML (XSD) qui définissent:
▪ les types de données échangées par le service → font partie du contrat syntaxique.
▪ les formats de données et les contraintes structurelles →font partie du contrat sémantique.
▪ Richesse des types et restrictions XSD permet d’auto-documenter les valeurs possibles.
▪ Un ensemble de policies qui définissent les règles d’utilisation du service → font parties du contrat
sémantique.
▪ Les règles et contraintes qu’elles expriment adressent des domaines variés : Sécurité, encodage, langue, versioning,
métiers, …
▪ De documentations complémentaires qui :
▪ complètent le contrat sémantique.
▪ Par exemple, dans les spécifications décrivant les prés et post condition d’utilisation du service (elles ne sont pas toutes
implémentables sous forme de policy).
▪ constituent le contrat de niveau de service (QoS & SLA)
▪ Un contrat qui définit un ensemble d’indicateurs et de valeurs seuils. Il n’est pas question ici des moyens techniques à mettre en
œuvre pour leur supervision (traces, alertes, …).
20
Service : Contrat standardisé (Exemple)
Le contrat de service est une notion complexe qui ne se limite pas à la (simple)
définition d’interfaces 21
Service : couplage lâche
▪ Les services doivent êtres indépendants et faiblement couplés aux autres
composants du SI
▪ Tous les échanges d’un service avec le monde extérieur se font à travers des messages
standards, en utilisant SOAP par exemple
→ couplage lâche vis-à-vis de son environnement
▪ L’interrogation direct d’un service crée une dépendance entre ces deux services
▪ Si le service directement appelé change d’adresse ou est supprimé → le service appelant
n’est plus utilisable non plus
▪ Le seul couplage toléré dans une SOA est celui avec un UDDI contenant vos contrats
publiés.
▪ Le seul couplage toléré dans une SOA est celui avec un UDDI contenant vos
contrats publiés.
▪ Le consommateur d’un service est lié au contrat de ce dernier, et ne doit être lié qu’à
celui-ci (Pas au service lui-même). C’est ce que l’on appelle le couplage lâche. 22
Service : couplage lâche
▪ L’utilisation d’un service BUS/Orchestration évite que les services aient
besoin de connaître les autres services
Services 2
Services 1 Services 2
1 2
Services 1
3
Services 5
Services 3
Services 3 4
Moteur Orchestration
Services 4 Services 4
Couplage fort Couplage lâche
23
Service : abstraction
▪ Le contrat du service ne doit contenir que les informations pertinentes à son
invocation
▪ Fonctionnement du service dit en « boîte noire »
▪ Seul le contrat exposé au consommateur du service est connu
▪ Le fonctionnement interne du service ne doit pas être visible (Logique métier,
Implémentation)
▪ Il est par conséquent important d’assurer la prédictabilité d’un service
▪ Pas de variation dans le comportement et dans la réponse d’un service lors de la
réception d’une requête
▪ Ce principe est induit par le respect du contrat du service.
24
Service : réutilisabilité
▪ La réutilisabilité des services constitue une des pierres angulaires de la mise en
œuvre d’une SOA
▪ SOA vise à éviter le gaspillage des ressources en éliminant les redondances inhérentes au modèle
en silo.
▪ La réutilisabilité d’un service désigne la capacité du service à répondre aux besoins de
plusieurs types de consommateurs
▪ Le service doit exprimer une logique agnostique afin qu’il puisse être positionné comme une
ressource réutilisable
▪ Les principaux paramètres qui peuvent influencer sur le degré de réutilisation de
service sont :
▪ La centralisation et la standardisation des ressources
▪ La démarche suivie dans la conception du service
▪ La granularité du service
▪ La résistance au changement 25
Service : découvrabilité
▪ Un service doit être accessible depuis un entrepôt ou un annuaire pour faciliter
sa découverte
▪ Le fournisseur de services a la charge de déposer et de mettre à jour ses
services depuis l’annuaire
▪ Le service est enrichi par un ensemble de métadonnées pour faciliter la
recherche du consommateur de services
▪ S’appuie sur des standards (UDDI, ebXML)
▪ D’après la gouvernance SOA
▪ Un service est défini avec l’intention d’être réutilisé
26
Service : autonomie / sans état
▪ Pour garantir la prédictabilité, un service :
▪ doit disposer de l’ensemble des informations nécessaires à son exécution → Autonome
▪ ne doit dépendre d’aucun service externe →Couplage lâche
▪ doit être sans état de façon à minimiser la consommation de ressources
▪ Service Autonome
▪ Absence de besoin à d’autres services pour accomplir sa tâche
▪ Le comportement d’un service ne dépend pas du contexte dans lequel il est invoqué
(contexte fonctionnel ou contexte technique)
▪ Service sans état
▪ Aucune requête ne dépende de la réponse d’une autre
27
Service : composabilité
▪ Un service doit fonctionner de manière modulaire et non pas intégrée
▪ Assurer la décomposition d’un service complexe en sous services plus simples
entre eux (garantie l’autonomie)
▪ S’inscrire dans une logique de composition de services à travers l’utilisation de
l’orchestration (couplage lâche)
▪ L’orchestration favorise l’indépendance des services et assure que des services
n’appellent pas directement d’autres services
28
