Ce document explore les architectures orientées services, en commençant par le modèle client-serveur et en abordant les architectures à objets distribués, web et basées sur des composants. Il détaille les caractéristiques et les modes d'interaction entre clients et serveurs, ainsi que les éléments fondamentaux des architectures orientées services, tels que les composants de service et le bus d'entreprise. Enfin, il met en lumière l'importance des services web et les protocoles associés pour une intégration efficace dans un environnement distribué.

1. Institut National des Sciences Appliquées et de Technologie
Architectures Orientées Services
Chapitre 2 – Vers les Architectures Orientées Services
Dr. Lilia SFAXI
LA3 SIL - 2013-2014

2. 1
Plan du Chapitre

Les architectures client-serveur

Les architectures à objets distribués

Les architectures Web

Les architectures à base de composants

Les architectures orientées services

3. 2
Plan

Les architectures client-serveur

Les architectures à objets distribués

Les architectures Web

Les architectures à base de composants

Les architectures orientées services

4. 3
Du modèle centralisé au client-serveur
Mainframe
Données
Architecture Centralisée
Architecture Répartie
Approche type Mainframe
PC, bureautique, client-serveur
Contrôle renforcé des données et de la logique
métier
Peu de contrôle sur les données, très peu sur la
logique métier
Centralisation des choix, des mises à jour
Problème de choix, installation et mise à jour des
applications
Coût d’administration faible
Coûts d’administration par utilisateur élevé
Faible autonomie de l’utilisateur
Très (trop?) grande autonomie de l’utilisateur

5. 4
Le Modèle Réparti
Logiciels clients
Logiciels serveurs

Distribution de la charge

Matériel banalisé et standard

Outils logiciels de coût réduit et de grande diffusion

Ouverture

Mais :
o
Administration et déploiement difficiles
o
Construction de systèmes par intégration de progiciels

6. 5
Client-Serveur : Définition

Approche d’architecture qui vise à répartir un système informatisé sur des machines
distantes, grâce à des matériels banalisés et des protocoles standards, et fondée sur
une notion de service.

Séparation d’entités distinctes fonctionnant de concert pour accomplir une tâche

Deux types de logiciels:
o
o

Logiciels clients
Logiciels serveurs
Problèmes
o
Définition d’une architecture adaptée à un contexte de besoins
o
Où placer la coupure client/serveur

7. 6
Client-Serveur : Caractéristiques

Partage des ressources

Modèle d’interaction de type requête

Transparence relative à la localisation

Indépendance vis à vis des matériels et des systèmes d’exploitation

Capacité d’évolution du système
o
o
Changement de serveur
o

Ajout de stations clientes
Passage à l’échelle
Intégrité des données partagées

8. 7
Modèles Client-Serveur (1/2)

Modèle serveur de fichiers
o
o

Partage de fichiers sur un réseau (ex: NFS)
Bases de documents, d’images
Lecture/Ecrit
ure de
fichiers
Modèle serveur de bases de données relationnelles
o
Traitements de sélection sur le serveur
o
Utilisation du produit commercial d’un éditeur
Serveur de fichiers
Appels SQL /
Résultats
Serveur de BD

9. 8
Modèles Client-Serveur (2/2)

Modèle serveur de transactions
o
o
Écriture de code sur client et serveur
o

Un seul message pour un ensemble d’opérations
Applications à temps de réponse critique (OLTP)
Transactions
Moniteur Transactionnel
Serveur de BD
Modèle serveur de groupware (travail collaboratif)
o
En général middleware propre à l’éditeur
o
Tendance vers l’utilisation de l’email comme support aux échanges
Messages
Serveur de groupware

10. Modes d’Interaction entre Clients et
Serveurs

SGBDR

RPC

MOM

Moniteurs Transactionnels
9

11. 10
Modes d’Interaction entre Clients et
Serveurs

SGBDR: Accès aux bases de données relationnelles
o
SQL standard
o
Interfaces :

Appel direct de SQL (API Call Level Interface)

ODBC (Open Data Base Connectivity), JDBC…

RPC

MOM

Moniteurs Transactionnels
Client
Interface ODBC
DLL ODBC
SQL intégré dans le code source (ESQL)

Client
Gestionnaire des Pilotes
Pilote ODBC
(SGBD x)
Pilote SGBD
x
SGBD
x

12. Modes d’Interaction entre Clients et
Serveurs

SGBDR

RPC : Appel de Procédures à distance
o
Appel d’une procédure qui s’exécute sur un site distant
o
Invocation et attente de réponse (appel synchrone)
o
Archivage de l’entête des procédures (Interface Définition Language)
o
Évolution vers l’objet: RMI (Remote Method Invocation)
o
11
Application
Cliente
Bibliothèque RPC
Utilisation d’un service d’annuaire pour localiser le service

MOM

Moniteurs Transactionnels
Appel de
Procédure/
Résultat
Serveur RPC
Code des Procédures

13. Modes d’Interaction entre Clients et
Serveurs
12
Application
Cliente

SGBDR

RPC

MOM : Middleware Orienté Message
o
File d’attente de messages (mode asynchrone)
o
Mode publish & subscribe


Communication lâche d’égal à égal

Expression d’intérêt sur un ou plusieurs types d’évènements
MCA (Message Channel Agent)
MCA (Message Channel Agent)
Moniteurs Transactionnels
Serveur RPC

14. 13
Modes d’Interaction entre Clients et
Serveurs
Serveur
de BD
Moniteur
Transactionnel

SGBDR

RPC

MOM

Moniteurs Transactionnels
Préparation
o
Applications transactionnelles
o
Fonctions principales:


o
Gestion des processus
•
•
•
•
•
•
BD partagées
Flux de requêtes important et non
planifié
Travail répétitif
Écriture/Commit
Grand nombre d’utilisateurs
dans le journal
Haute disponibilité, intégrité
Nécessité d’équilibrage de charge
Gestion des transactions en contexte distribué (plusieurs gestionnaires
de données)
Implémentation du protocole de validation à 2 phases (two
phase commit)
Prepare
Préparation
OK
Commit
Ack
Écriture d’un
enregistrement
Validation

15. 14
Plan

Les architectures client-serveur

Les architectures à objets distribués

Les architectures Web

Les architectures à base de composants

Les architectures orientées services

16. 15
Modèle à Objets Distribués

Coopération de services distribués modélisés comme des objets

Deux modèles
o
CORBA (Common Object Request Broker Architecture) de l’OMG
o
COM + (Microsoft)
objet

17. 16
CORBA

Éléments du modèle
o
Objets applicatifs
o
Objets utilitaires (catalogues de classes, messagerie…)
o
Services d’objets utilisables dans certains environnements (création d’instances, services
transactionnels, persistance…)
o
Courtier d’objets
Objets Applicatifs
Objets utilitaires
Courtier de requêtes objet (ORB)
Services Objets

18. 17
CORBA

Échanges
o
Entre objets liés par un même ORB
o
Entre ORBs de différentes implémentations (protocole IIOP: Internet Inter-ORB
Protocol)
ORB1
IIOP
ORB2

19. 18
Plan du Chapitre

Les architectures client-serveur

Les architectures à objets distribués

Les architectures Web

Les architectures à base de composants

Les architectures orientées services

20. 19
Evolution liée à Internet

Interconnexion de réseaux à l’échelle mondiale fondée sur les protocoles
TCP/IP

Applications : web, email, ftp…

Évolution du client-serveur en local vers le client serveur sur Internet

Modèle du « client léger », mode « non connecté »

Exploitation des technologies internet dans le modèle client-serveur

21. 20
Architecture 3 tiers

Principe : séparation des trois niveaux
o
IHM : interface Homme-Machine
o
Application
o
Gestion des données

Réduction du trafic réseau entre postes clients et serveurs

Les applications peuvent être déployées et administrées de manière
indépendante des IHM

Placement des serveurs logiciels sur un ou plusieurs serveurs physiques

Nombreuses variantes architecturales possibles

22. 21
De 2 à 3 Niveaux
IHM
SQL, E/S
fichiers
IHM
App
Niveau1
RPC, ORB,
MOM, http
App
SQL, E/S
fichiers, API
legacy
App
Niveau2
Client-Serveur à deux Niveaux
Niveau1
Niveau2
Client-Serveur à trois Niveaux
Niveau3

23. 22
De 2 à 3 Niveaux
Architecture à 2 Niveaux
Architecture à 3 Niveaux
Simplicité, création d’applications plus
rapide
Applications mieux dimentionnables,
« scalabilité »
Convient aux applications
départementales
Plus faciles à déployer
Difficulté d’administration et de
déploiement
Adapté aux données issues de sources
multiples
En général pas extensible aux applications
à l’échelle de la grande entreprise
Services abstraits qui minimisent les
échanges sur le réseau
Sécurité (pas d’exposition du schéma de la
BD)

24. 23
Architecture à n Niveaux

Niveaux Intermédiaires  Collection d’applications
o
Chaque application peut être un composant indépendant en charge d’une
fonction
o
Chaque fonction peut être utilisée et peut appeler d’autres fonctions
o
Encapsulation des applications du patrimoine d’entreprise
Service
Gestion
BD
Service
IHM
Service
Niveau1
Niveau2
Niveau3

25. 24
Plan du Chapitre

Les architectures client-serveur

Les architectures à objets distribués

Les architectures Web

Les architectures à base de composants

Les architectures orientées services

26. 25
Approche Orientée Composants

Construction d’applications à partir de l’assemblage de composants

Principe : le développement et assemblage de composants peut être
réalisé séparément par des acteurs différents à des endroits différents

Utilisation de la composition comme mécanisme de réutilisation au lieu
de l’héritage

27. 26
Composant
Interfaces
de contrôle
Interfaces
fournies

Brique logicielle préfabriquée conçue pour être
composée (assemblée) avec d’autres composants

Réutilisable

Son utilisation ne nécessite pas de connaissance sur
l’implémentation

Unité binaire : code source n’est pas forcément livré
avec le composant
Interfaces
requises

28. 27
Caractéristiques (1/2)

Classe de composant (équivalente à la notion de classe en OO)
o
Définit l’implémentation du composant (logique fonctionnelle)
o
Peut être vue à partir :



d’une vue externe : vision des clients sur les instances du composant
D’une vue interne : vision de l’environnement d’exécution sur les instances du
composant
Instance de composant (équivalente à la notion d’objet en OO)
o
Obtenue à partir d’une classe de composants
o
Fournit les fonctionnalités du composant à l’exécution
o
Unique par rapport aux autres instances, peut avoir un état

29. 28
Caractéristiques (2/2)

Paquetage de composant
o
Unité permettant de réaliser la livraison et le déploiement d’une classe de composant de
manière indépendante
o
Contient tout ce qui est nécessaire pour réaliser la création d’instances de la classe de
composants



Code binaire du composant
Ressources nécessaires à son exécution (bibliothèques, images, fichiers de config)
Environnement d’exécution
o
Fournit du support aux applications construites à partir du modèle à composants, lors de
l’exécution
o
Sorte de mini-système d’exploitation : gère les aspects divers (cycle de vie des instances,
propriétés non fonctionnelles)

30. 29
Modèle Orienté Composants

Permet de réaliser le développement et l’exécution d’applications
à base de composants

Définit :
o
les caractéristiques des composants
o
Leur assemblage
o
Le support d’exécution

31. 30
Modèles à Base de Composants Existants

COM (Component Object Model, Microsoft)
o
o

Résout le problème d’interopérabilité
Mais : ne propose pas une vue externe constante (les interfaces peuvent varier)
JavaBeans (Sun)
o
o

Simplifier la construction d’applications grâce à la composition visuelle
Vise les applications non distribuées avec interface utilisateur
EJB(Enterprise Java Beans, Sun)
o
o

Vise les applications réparties en trois tiers (MVC)
Ne supporte pas que la partie contrôleur soit distribuée
CCM (CORBA Component Model, OMG)
o
Définir l’architecture d’une application distribuée sous forme de composition d’instances de composants
o
Utilisation d’un langage abstrait pour la description d’interfaces (IDL) + d’un langage CIDL pour décrire les
implémentations)  Obligation de tout écrire en langage abstrait pour de compiler pour le langage cible
o
Supporte les applications distribuées

32. 31
Plan du Chapitre

Les architectures client-serveur

Les architectures à objets distribués

Les architectures Web

Les architectures à base de composants

Les architectures orientées services

33. 32
Tout Devient « Service »…

Service :
o

Fonctionnalité réutilisable dont le comportement est défini de façon
contractuelle
3 Acteurs
o
Consommateur de service décrit le service à consommer
o
Fournisseur de services découvert en temps d’exécution à l’aide d’un
intermédiaire (Registre de service)
o
Registre de service contient l’ensemble des descripteurs de services et les
références vers les fournisseurs de services

34. 33
Architecture Orientée Service

Définit principalement 4 éléments de base
o
Composant de service
o
Bus d’Entreprise (ESB)
o
Contrat de Service
o
Données

35. Éléments de Base
Composant de Service

Brique de base de l’architecture, composé d’une vue externe et
interne

La vue externe ou spécification :
o
Expose la facette service proprement dite
o
Constituée :


o

d’un ensemble d’opérations de service regroupées en interfaces
appareillage pour les utiliser (types de données échangées, contrat de
service, propriétés…)
Décrite par un fichier WSDL ou équivalent
La vue interne :
o
Décrit le contenu du composant
o
Masquée aux consommateurs du composant
o
Contient des informations relatives à la logique interne (détail de
traitement ou bases de données) + références vers les services
utilisés par le composant
34

36. Éléments de Base
Bus d’Entreprise (ESB : Enterprise Service Bus)

Présence de plusieurs participants sous forme de :
o
Fournisseurs de service : composants de service, deux
familles:


o

Composants qui prennent en charge l’implémentation des
services
Composants qui délèguent son implémentation à un tiers
(mainframe, ERP, application existante)
Consommateurs de service : applications, progiciels ou
autres composants de service
ESB :
o
Colonne vertébrale reliant les participants à travers les
interfaces de service
o
Possibilité de modifier les implémentations ou de remplacer
les composants sans changer la structure du système
35

37. Éléments de Base
Contrat de Service

Détaille les conditions d’utilisation du service sous forme de:
o
Pré- et Post- conditions : Détaillent les conditions d’utilisation sur les opérations de service
o
Protocole d’utilisation: les séquences valides d’invocation de ses opérations
o
Contraintes (QoS, SLA: Service Level Agreement, sécurité, fiabilité…)
36

38. Éléments de Base
Données

Données d’échange
o
o

Informations véhiculées entre les participants à
travers l’invocation des opérations de service
TDE : Types de donnée d’échange : établissent
la sémantique, structure et format de ces
données, définis à l’aide de schémas XML ou
classes UML
Données persistantes
o
Informations contenues et gérées dans les
bases de données
o
Structurées de façon habituelle (SGBD
relationnel, par exemple)
37

39. 38
Les Web Services

Unité logique applicative accessible en utilisant les protocoles standards
d’internet, réutilisable et indépendante de la plateforme et de
l’implémentation

Objectifs
o
Accès rapide à l’information
o
Système ouvert réduisant les coûts
o
Administration simplifiée
o
Utilisation d’internet comme support de communication

40. 39
Caractéristiques des Services Web

Application fournissant des traitements et des données à d’autres
applications déployées sur le Web et vues à travers une interface

Protocole SOAP (Simple Object Access Protocol) over HTTP

Données en XML

Annuaire de services : UDDI (Universal Description Discovery and
Integration)

Langage WSDL (Web Service Description Language) pour la description du
service

41. 40
Les Web Services : Principes
2: J’ai trouvé! Voici le serveur hébergeant ce service
3: Quel est le format d’appel du service que tu proposes?
1: Je recherche
un service WEB
4: Voici mon contrat (WSDL)
5: J’ai compris comment invoquer
ton service et voici ma requête
6: J’ai exécuté ta requête et voici le résultat

42. 41
Sources

Cours

Y. Pollet: Architectures : du client-serveur à la SOA (Introduction aux
architectures réparties), CNAM, Chaire d’intégration des systèmes.

Thèses

Humberto Cervantes : Vers un modèle à composants orienté services
pour supporter la disponibilité dynamique, LSR, équipe Adèle