Chp2 - Vers les Architectures Orientées Services

Architectures Orientées Services

Chapitre 2 – Vers les Architectures Orientées Services

Dr. Lilia SFAXI

LA3 SIL - 2013-2014

Institut National des Sciences Appliquées et de Technologie

2

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

Plan






4Du modèle centralisé au client-serveur

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

Mainframe

Données

5

Le Modèle Réparti

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

Logiciels clients

Logiciels serveurs

6

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

o Logiciels serveurs

Problèmes

o Définition d’une architecture adaptée à un contexte de besoins

o Où placer la coupure client/serveur

7

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 Ajout de stations clientes

o Changement de serveur

o Passage à l’échelle

Intégrité des données partagées

8

Modèles Client-Serveur (1/2)

Modèle serveur de fichiers

o Partage de fichiers sur un réseau (ex: NFS)

o Bases de documents, d’images

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

Lecture/Ecriture de

fichiers

Serveur de BD

Appels SQL /Résultats

9

Modèles Client-Serveur (2/2)

Modèle serveur de transactions

o Un seul message pour un ensemble d’opérations

o Écriture de code sur client et serveur

o Applications à temps de réponse critique (OLTP)

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

Moniteur TransactionnelTransactions

Serveur de groupware

Messages

Serveur de BD

10Modes d’Interaction entre Clients et Serveurs

SGBDR

RPC

MOM

Moniteurs Transactionnels


SGBDR: Accès aux bases de données relationnelles

o SQL standard

o Interfaces :

SQL intégré dans le code source (ESQL)

Appel direct de SQL (API Call Level Interface)

ODBC (Open Data Base Connectivity), JDBC…

RPC

MOM


Client Client

Interface ODBC

DLL ODBC

Gestionnaire des Pilotes

Pilote ODBC (SGBD x)

Pilote SGBD x

SGBD x


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 Utilisation d’un service d’annuaire pour localiser le service

MOM


ApplicationCliente

Bibliothèque RPC

Appel de Procédure/Résultat

Serveur RPC

Code des Procédures


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


ApplicationCliente

MCA (Message Channel Agent)

Serveur RPC

MCA (Message Channel Agent)


SGBDR

RPC

MOM


o Applications transactionnelles

o Fonctions principales:

Gestion des processus

Gestion des transactions en contexte distribué (plusieurs gestionnaires de données)

o Implémentation du protocole de validation à 2 phases (two phase commit)

• BD partagées• Flux de requêtes important et

non planifié• Travail répétitif• Grand nombre d’utilisateurs• Haute disponibilité, intégrité• Nécessité d’équilibrage de

charge

Moniteur Transactionnel

Serveur de BD

Prepare

OK

Commit

Ack

Préparation

Préparation

Écriture/Commit dans le journal

Validation

Écriture d’un enregistrement

15

Plan






16

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

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’objetsObjets Applicatifs

Services Objets

Courtier de requêtes objet (ORB)

Objets utilitaires

18

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 ORB2IIOP

19

Plan du Chapitre






20

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

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

De 2 à 3 Niveaux

IHMSQL, E/S fichiers

App

Niveau1 Niveau2

Client-Serveur à deux Niveaux

IHMRPC, ORB, MOM, http

Niveau1 Niveau2

Client-Serveur à trois Niveaux

App

App

SQL, E/S fichiers, API

legacy

Niveau3

23

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

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

IHM

Niveau1 Niveau2

Service

Niveau3

Service

Service

Gestion BD

25

Plan du Chapitre






26

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

Composant

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 fournies

Interfaces de contrôle

Interfaces requises

28

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

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

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

Modèles à Base de Composants Existants

COM (Component Object Model, Microsoft)

o Résout le problème d’interopérabilité

o Mais : ne propose pas une vue externe constante (les interfaces peuvent varier)

JavaBeans (Sun)

o Simplifier la construction d’applications grâce à la composition visuelle

o Vise les applications non distribuées avec interface utilisateur

EJB(Enterprise Java Beans, Sun)

o Vise les applications réparties en trois tiers (MVC)

o 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

Plan du Chapitre






33

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

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

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

o 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

36Éléments de BaseBus d’Entreprise (ESB : Enterprise Service Bus)

Présence de plusieurs participants sous forme de :

o Fournisseurs de service : composants de service, deux familles:

Composants qui prennent en charge l’implémentation des services

Composants qui délèguent son implémentation à un tiers (mainframe, ERP, application existante)

o 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

37Éléments de BaseContrat 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é…)

38Éléments de BaseDonnées

Données d’échange

o Informations véhiculées entre les participants à travers l’invocation des opérations de service

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

39

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

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

Les Web Services : Principes

1: Je recherche un service WEB

2: J’ai trouvé! Voici le serveur hébergeant ce service

3: Quel est le format d’appel du service que tu proposes?

4: Voici mon contrat (WSDL)

5: J’ai compris comment invoquerton service et voici ma requête

6: J’ai exécuté ta requête et voici le résultat

42

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

Chp2 - Vers les Architectures Orientées Services

Technology

Transcript of Chp2 - Vers les Architectures Orientées Services