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
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
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
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
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