Cours d’introduction Modèles d’interactions pour le …t4clive.free.fr/pour%20bien%20reussir%20ton%20BTS%20%3B-)/co…Coopération : Le point de vue global Une application coopérative

Modèles pour le client serveur 1

Cours d’introduction

Modèles d’interactions pourle client serveur et exemples

d’architectures les implantant

Gérard Florin

Conservatoire National des Arts etMétiers

Laboratoire CEDRIC


IntroductionProblématique de la coopération

Application coopérative Application réalisée par des programmes

communicants (processus, objets, ...).

Avantages potentiels

- Modularité.- Réutilisation (par composition).- Performances.

Motivations actuelles importantes pourles applications coopératives

- Applications systèmes et réseaux(algorithmique répartie).

- Applications objets, objets répartis, àbase de composants.

- Systèmes d’informations,Parallélisme, Intelligence artificielle=> Presque tous les types d’applicationsinformatiques sont concernées.


Des problèmes spécifiques à lacoopération

Cycle de vie

- Exprimer la coopération.- Développer l’application.- Déployer l’application.- Gérer son exécution.

Sous des hypothèses d’environnement

- Performances.- Pannes.- Sécurité.- Répartition.


Exprimer la coopération

Le principal problème abordé actuellement.

Coopération : Le point de vue local

Ensemble de programmes coopérantsutilisant des données locales

Programmes : schéma de contrôle local àun site (flot d’exécution local).

Données : traitées par le programme,disponibles localement sur le site.

Vision plutôt ascendante : ‘émergence’ ducomportement coopératif.

Terminologies multiples

Application répartie , distribuée ,coopérative, n tiers


Coopération : Le point de vue global

Une application coopérative offre unservice externe en encapsulant une structure

de données réparties

Programme réparti : schéma de contrôleglobal à un ensemble de sites(comportement de groupe).

Données : une structure de donnéesencapsulée par le traitement (en faitdistribuée sur les différents sites, ‘structurede données partitionnée).

Vision plutôt descendante : lecomportement coopératif visé est placé a

priori.


Coopération avec utilisation d’interactionsclient serveur

Client serveur : une approcheuniversellement adoptée pour structurer les

applications coopératives.

A l’origine des services généraux offertspar les couches application réseau.

Exemples : Serveurs de fichiers Serveurs de base de données, Serveurs d’impression Serveurs de noms (annuaires) Serveurs applicatifs usager.

Client A

Client B

Serveur

Service 1

Service n


Modèle client serveur

Un ensemble de choix de réalisations del’interaction de communication en point

à point ayant des points communs.

Client serveur : Vue du client

- Mode de synchronisation locale desprimitives requête, réponse.

- Mode de synchronisation distante.- Parallélisme interne au client.

Client Service distant

Réponse

Requête


Client serveur : Vue du serveur

- Gestion des requêtes.- Exécution du service :

séquentiel, concurrent- Mémorisation ou non de l’état du client.

Alternatives au mode client serveur

Des schémas de contrôle applicatifsréutilisables (‘design patterns’) générantdirectement des modes complexesd’interaction

Impliquant des groupes d’entitéscommunicantes.

Exécution du service

RequêtesRéponses


Développer une applicationen client-serveur

Choisir une sémantique de base précisesupportant le mode client serveur

Pour exprimer la synchronisation entre descoopérants au moyen d’une interaction de

base (‘design pattern’).

Propriétés des outils d’expression de lacoopération

1 Définition d’un modèle d’interaction etd’exécution.

Présentation des différentes catégoriesde modèles dans cette introduction.2 Définition d’une API (interface deprogrammation) supportant le modèle.

Dans les cours de détail.3 Outils de développement.4 Environnements d’exécution.

Services systèmes d’accueil surdifférents types d’infrastructure.


Architecture globale

Outils dedéveloppement

Outils d’administration

Services applicatifs(fichiers répartis, transactionnels,…

Services systèmes(communications, désignation,sécurité…)

Médiateur (Middleware)

Application

Systèmes d’exploitationMachines et réseaux


Plan du cours :Les modèles d’interactions actuels pour

le client serveur

Modèles de communication par messages.

Modèles de communication à événements.

Modèles client serveur de base de données. (ODBC).

Modèles client serveur en RPC.

- Client serveur à RPC traditionnel (DCE).

- Client serveur à objets répartis.(CORBA, DCOM).

- Client serveur à composants (EJB, CCM).

Egalement

Modèles à base de code mobile.Modèles à mémoire virtuelle partagéerépartie.


MODELES CLIENT SERVEUR

A MESSAGES


Client serveur par messages:Introduction

Mode de communication basique parmessages asynchrones

- Communication asynchrone : Emission non bloquante Réception bloquante.- Communication par messages typés.- Communication sur les processusdestinataires ou sur des boites à lettres(portes) de communication.

CLIENT SERVEUR

Requète

Réponse

Send(bals,serv, params

Msg=get(bals)

Put(balc,res)Msg=get(bals)

exec(serv)bals

balc


Communications par messages :exemples de mise en oeuvre

Interfaces des piles réseaux

Couche transport : Sockets, TLI, NetBEUI .

Interfaces de programmation parallèle

PVM , MPI.

Interfaces de systèmes répartis

Chorus, Mach

Autres environnements par message

Multi-agent,

Dernière version du modèle : les MOM

(fin des années 1980)

Mode messages asynchrones +

Mode asynchrone avec persistance : lesfiles de messages.


Communication à files de messages :

MOM Messages Oriented Middleware

Deux modes de fonctionnement:. mode message (habituel).. mode file de messages (caractéristique)

Messages

Identification unique.

Structure.

Entête : identifiant, informationsprotocolaires pour l’acheminement. Attributs : couples (nom, valeur)utilisables pour la sélection des messages. Données : charge utile.

Paramètres d’acheminement. Durée de vie Priorité Sécurité. Confidentialité, contrôle d’accès.


Motivations pour les files de messages

Les styles Asynchrones et Synchrones ontdes forces et des faiblesses.

Mode synchrone (bloquant)

Il est terminant (on est certain de la fin).Avec acquittement (réponse).

PB : arrêt complet du fonctionnement duclient quand le serveur ne répond pas.

Mode asynchrone (non bloquant)

Pour assurer l’acquittement et laterminaison il faut un protocole.

L’asynchronisme des modes messageshabituels devient assez vite égalementbloquant car on peut saturer un site distantqui ne peut pas tenir le rythme des servicesdemandés (serveur non opérationnel).

=> Amélioration : les files de messages.


Files de messages

Structures de données de stockage demessages asynchrones

- Identification unique

- Propriétés de persistance (style transactionnel)Les messages dans les files sont journalisés(résistance aux défaillances, gestion desclients en ligne ou hors ligne).

- Partagées (par les applications).

- Mode de réception variable (selon ledestinataire).

Exemples : IBM MQSeries, MicrosoftMessage Queue Server, DECmessageQ,TIPCO, etc.


EXEMPLE MOM : IBM MQSERIES

LES QUATRE TYPES DE MESSAGES

‘Datagram’: messages isolés

‘Request’ : l’émetteur attend une réponse.

‘Reply’: réponses aux requêtes

‘Report’ : pour informer d’événementsexceptionnels.

LES ONZE PRIMITIVES

MQCONN - Connecte une application à ungestionnaire de file (‘queue manager’).

MQOPEN - Ouvre un objet MQSeriescomme une file et retourne un descriptif(‘handle’).

MQGET - Demande pour obtenir desmessages d’une file locale. MQGET peutêtre utilisée de façon bloquante ou non.


LES ONZE PRIMITIVES (SUITE)

MQPUT - Envoie un message sur une filelocale ou distante

MQPUT1 - Séquence de MQOPEN,MQPUT d’un message et MQCLOSE.

MQCLOSE - Fermeture avec destructiond’une file.

MQDISC - Déconnexion avec ungestionnaire de files MQSeries.

MQINQ - Interrogation d’attributs d’objetsMQSeries (des files).

MQSET - Positionnement ou modificationd’attributs d’objets MQseries.

MQCMIT - Indique au gestionnaire de lafile que toutes les opérations ‘get’ et ‘put’depuis le précédent point desynchronisation sont validées.

MQBACK - Demande de reprise arrièrepour tous les ‘get’ et ‘put’ depuis le dernierpoint de synchronisation.


Les files de messages : conclusion

AvantagesUne interaction par message asynchroneavec des améliorations.

Augmentent l’interopérabilité, la portabilitédans la mesure ou l’interface MOM isolel’application des logiciels sous jacents.

Les infrastructures client serveur à MOMsont assez simples et donc à maturité=> de nombreuses entreprises utilisent desMOM (exemple le secteur bancaire).

Les autres styles de ‘middleware’ ne sontpas simples ni jugés aussi murs.=> Introduction de service MOM enCORBA (chez IBM Mqseries en DSOM)

InconvénientsSémantique limitée du mode messageasynchrone.



A EVENEMENTS


Client serveur à événements :Introduction

Besoin : définir une approche ‘asynchrone’(événementielle) de communication..

Programmation événementielle :systèmesréactifs, messages asynchrones, graphique,

Environnements : un plus dans lesenvironnements objets répartis (servicesd’événements CORBA, composantsCORBA, JMS Java Messaging Service).

Concepts

- Notions d’événements (un signal) et deréactions (un code, une procédure exécutépar un abonné lors d’un événement).

- Attachement : association dynamiqueentre un événement et une réaction.

- Communication anonyme :indépendance entre l’émetteur d’unévénement et les consommateurs de cetévénement.


Communication événementielle :schéma général

- Des sources produisent des événements :publish.

- Des consommateurs s’abonnent à desévénements : subscribe.

Programme cons

Subscribe (event1,reaction1)

Reaction1 :

Programme prod

Publish (event1)

Service de gestiondes événements etdes abonnementsSubscribe (event1,

12

3Bal


Communication événementielle :Sémantique de consultation des boites à

lettre

Mode ‘Pull’

- Le consommateur doit consulter sa boite àlettre pour traiter les événements en attente.

=> Il contrôle le moment de traitement desévénements.

Mode ‘Push’

- Le consommateur attache une méthode àchaque type d’événement.

=> L’occurrence d’un événement déclencheautomatiquement le traitement associé.


Communication événementielle :Architecture du service d’événement

centralisée

Mode ‘Hub and Spoke’

- Le service centralisé de gestion desévénements dialogue en mode point à pointavec des clients producteurs ouconsommateurs d’événements.

Courtiercentraliséd’événements

Clientproducteur

Clientproducteur

Clientconsommateur


Communication événementielle :Architecture du service d’événement

répartie

Mode ‘Snowflake’

- Les courtiers coopèrent pour offrir unservice réparti de gestion des événements.

Courtier

Clientproducteur

Clientproducteur

Clientconsommateur

Courtier

Courtier


Communication événementielle :Architecture du service d’événement à

bus de messages

- Les courtiers coopèrent au moyen d’unprotocole à diffusion des événements.

Courtier

Clientproducteur

Clientproducteur

Clientconsommateur

Courtier

Courtier

Répéteur


ENVIRONNEMENT A EVENEMENTS,EXEMPLE : JMS ‘JAVA MESSAGE

SERVICE’

Une API JAVA pour offrir un accèsunique aux différents protocoles de files

de messages (MOM MQSeries, Tibco …). - Gestion événementielle des messages. - Mode ‘publish’/’subscribe’

JMS

Clientproducteur

Clientconsommateur

JVM

Pile MQ X

Accès MQ X

JMS

JVM

Pile MQ X

Accès MQ X

Réseau


Java Message Service : Architecture

JNDI

JMS Client

Destination

Connectionfactory

Connection

Session

MessageProducer

MessageConsummer


Commentaires Architecture JMS

- JMS utilise JNDI (‘Java Naming andDirectory Interface’) pour trouver lalocalisation des ressources souhaitées.

- Un client JMS (le créateur d’uneapplication JMS) doit réaliser les étapes :

1.Créer une connexion avec leprestataire d’échange de messages.

2.Créer une ou plusieurs sessions pourémettre et recevoir des messages.

3.Créer des producteurs de messages(‘MessageProducers’) qui publient desmessages et des consommateurs demessages (‘MessageConsumers’) quireçoivent les messages.


Client serveur à événements :Conclusion

Avantages

Une sémantique de communication‘asynchrone’ demandée par différentes

applications (différents métiers).

- Diffusion d’informations sur le WEB(Smartsockets, Castanet, Ambrosia,ActiveWeb, iBus, TIB/rendezvous).

- Diffusion de logiciels.

- Workflow

Inconvénients

- Des outils souvent propriétaires.

- Des outils de développementsommaires.


Modèle client serveurDe données


Le client serveur de données :Principes généraux

Une approche des applications clientserveur orientée accès distant à une base de

données.

Fonctions du client

Traitements applicatifs non lié au stockagedes données :

- dialogue avec l’utilisateur,- traitements divers,- ….

Fonctions du serveur

Stockage des données ,- Interprétation des requêtes,- Optimisation des requêtes- Gestion de la persistance- Gestion de la sécurité des données- …..


Le client serveur de données :schéma de base

Très nombreux standards et produitspropriétaires.

Client Serveur

Codeclient

SGBD

Requête SQL

Résultats:tuples

Médiateur(Middleware)


Exemple : Client serveur de bases dedonnées relationnelles

L'API CLI de l’X/OPEN"Call Level Interface"

Une API en mode message pour l'accès àdes BD relationnelles (31 primitives).Une standardisation de la formulation desrequêtes offrant la conformité SQL2. | AllocHandle | BindCol | BindParam | Cancel | CloseCursor | Connect | CopyDesc | DescribeCol | Disconnect | EndTran | ExecDirect | Execute | Fetch | FreeHandle | GetCol | GetCursorName | GetConnectAttr | GetDescField | GetDescRec | GetDiagField | GetDiagRec | GetEnvAttr | GetStmtAttr | NumResultCols | Prepare | ReleaseEnv | SetCursorName | SetDescField | SetDescRec | SetEnvAttr | SetStmtAttr


Exemple : Le client serveur de bases dedonnées orientées objet

Objectifs

Permettre la portabilité des sources d’uneapplication utilisant une approche BD objetsur différents moteurs de SGBD objets.

Solutions ODMG : ‘Object DataManagement Group’

- Choix d’un modèle objet (sur ensembledu modèle objet de l’OMG ‘ObjectManagement Group’).

- Langage de définition de donnéesODL (‘Object Description Language’) basésur IDL CORBA).

- Langage d’interrogation orienté objetOQL (‘Object Query Language’)

- Intégration aux langages objets existants.


Environnements client serveur dedonnées : Exemple ODBC

"Open Data Base Connection"

. Un produit définit par extensions à partirla CLI de l’X/OPEN (depuis 1992).

. Ensuite de très nombreux rattachements àce standard de facto. Existence sur lesprincipaux OS de pilotes pour un grandnombre de bases de données.

. Mais des évolutions successives avec desvariations importantes (V1, V2, V3 ..).

Exemple ODBC 2.0

. Noyau: 23 primitives de base.

. Niveau 1: 19 appels pour les accès auxcatalogues des bases de données, les grosobjets et des fonctions spécifiques despilotes.. Niveau 2: 19 appels supplémentaires pourdes accès utilitaires.


Organisation générale de ODBC

API ODBC

Pilote 1FAP 2

Pilote 2FAP 1

Gestionnaire de pilotes

OracleSQL*Net DRDADB2

API Pilotes fournisseurs

- Couche de réception des requêtes ODBC.

- Couche de gestion des pilotes (à quelpilote passer une requête?)

- Selon un format standard pour les pilotesODBC.

- Chaque pilote de bases de donnéesencapsule les requêtes dans le formatpropre à chaque fournisseur de bases dedonnées.

- Notion de FAP (‘Format And Protocol’)structure des messages et codage desdonnées pour un SGBD.


Client Serveur de données : Conclusion

- La transmission à distance de requêtesd'accès à des bases de données est unproblème résolu:

. Choix d'un service (dérivé de SQL)

. Choix d'un protocole.

- Difficulté : le client serveur de donnéesest rendu très opaque par le jeu des éditeursde logiciels qui veulent couvrir tout lespectre des interactions client serveur dansdes solutions propriétaires :

. Commandes de bases SQL enrichiesde multiples fonctionnalités.

. Procédures stockées et déclencheursajoutent des RPC synchrones ouasynchrones.

. Les propositions propriétaires nonstandardisées sont trop nombreuses.

Nombreux problèmes à résoudre pourune homogénéisation des approches et

peu de volonté d'y arriver.


Modèle client serveuren RPC traditionnel


APD ‘Appel de procédure distante’RPC ‘Remote Procedure Call’

Introduction

Objectif d’un RPCPrésenter les interactions distantes sous une

forme (syntaxe) et un effet (sémantique)analogue à celui d’un appel de procédure

local.

- L’opération appelée (le serveur) estprésentée sous la forme d’une procéduresituée sur un site distant dont unprogramme appelant (le client) demandel’exécution.

- L’interaction est généralement synchronecomme un appel de procédure habituel (lemode asynchrone est possible)

- Le RPC offre un changement importantpar rapport à la structuration au modemessage (qui ne permet qu’undéclenchement asynchrone d’action àdistance définie par une séquence de code).


RPC : Principes de réalisation encommunication par messages

Birrell et Nelson 1984

V

V

Appelant Appelé

Réseau

SoucheAppelant

SoucheAppelé

1

2

3

4

5


RPC : Notion de souche ou talon (‘stub’)

Deux procédures intermédiaires (chezle client et le serveur) pour l’adaptation del’invocation à l’environnement réparti.

Elles transforment un appel local enappel distant.Z Un exemple type de démarche réflexivede tissage (‘wrapping’).

Souche Appelant (‘stub’)

- Reçoit l’appel en mode local.- Emballe les paramètres d’appel dans unmessage de requête (‘marshalling’).- Emet le message de requête.- Se met en attente du message de réponse.- Déballe les paramètres réponse.- Retourne les paramètres réponse commeun retour local.


Souche Appelé (‘skeleton’)

- Reçoit le message d’appel.

- Déballe les paramètres d’appel(‘unmarshalling’).

- Fait réaliser l’exécution par la procédureappelée.

- Récupère par le retour local les résultats.

- Emballe les paramètres réponse dans lemessage de réponse.

- Emet le message réponse vers la soucheappelant.


Invocation distante et invocation locale

Objectifs pour une invocation distante

Le plus souvent affiché : obtenir eninvocation distante la même sémantiquequ’en invocation locale (atteindre une‘transparence’ de la répartition).

Très difficile à atteindre (actuellement onest encore loin de compte)

- Syntaxe : beaucoup plus lourde enappel distant qu’en appel local

Description de la signature en IDL.Usage d’interfaces systèmes (API).Modes de désignation (références).

- Sémantique de l’appel distant différentede celle de l’appel local

PerformancesTransmission des argumentsModes de panne


RPC : De nombreuses difficultés de miseen œuvre

PerformancesRéalisation des invocations distantes avecdes temps de réponse satisfaisants.

Gestion des pannesPannes franches du client ou du serveur.

Ouverture (interopérabilité)Des langages évolués utilisés.De la représentation des données.Des systèmes d’exploitation utilisés.Des architectures de réseau.

Désignation et liaisonStructuration des références.Localisation des serveurs.

SécuritéAutorisation des accès aux procédures

Authentification des clientsVérification des droits.


RPC : Traitement des pannes

Cas des pannes franches ou transitoires

- Mécanismes de reprise- Sémantique des reprises en cas de pannedans l’exécution d’un RPC.

Nombre de fois ou le serveur est exécuté

Exactement une fois- Difficile (sauvegarde totale du

contexte, reprise sur erreur).

Au plus une fois (‘at most once’)- Identification des appels, une seule

exécution . Exception si erreur.

Au moins une fois (‘at least once’)- Tentatives d’exécution jusqu’à ce que

l’une réussisse.

N’importe quoi


RPC Interopérabilité : Problèmes dereprésentation des données

Présentation = Conversion desparamètres échangés entre l’appelant et

l’appelé.

A partir d’une syntaxe abstraite :description dans un langage évolué des

types de données échangés

Génération d’une syntaxe de transfert :syntaxe de la représentation des paramètres

dans les messages.

Opérations de codage / décodage : à partirde la génération des souches.


RPC : Syntaxes de transfert

Choisir un format de représentation desdonnées échangées.

- facile à comprendre, à générer. Coder et décoder efficacement à partir desreprésentations locales.

- rapidement,- faible volume généré.

Solutions des codages ‘binaires’

Les paramètres sont codés sous une formebinaire prédéfinie, compacte, nondirectement lisible (exemple format CDRde CORBA).

Solutions de codages ‘caractères’

Les paramètres sont codés en format textelisible (‘human readable’) typiquement enutilisant XML.


RPC : Syntaxes abstraites

Besoin de langages de descriptiond’interface : IDL

‘Interface Definition Language’

- Spécification unique de l’appel (IDL deslangages de déclaration de types communappelant/appelé).

- Spécification indépendante du langagede programmation de l’appel (IDL langageunique, langage pivot).

- Amélioration de la réalisation del’invocation distante par des directivesspécifiques (références uniques, paramètresmodes in out, contraintes d’échéances, ….).

Mise en œuvre

- IDL langage déclaratif de typage.- Utilisé pour générer des souches.- Code stocké dans un répertoired’interfaces.


RPC : Utilisation du code IDL

Procédureappelante(client)

Procédureappelée(serveur)

Description IDLde l’interfaceappelée

Générateurde souches

Souche client

Compilateurlangage client

Définitionscommunes

Code del’appelant(client)

Compilateurlangage serveur

Souche serveur

Code del’appelé(serveur)

Bibliothèque


RPC : Désignation et de liaison

Désignation (nommage)

Créer des références (des structures dedonnées) qui supportent le mécanismed’invocation (ici à distance).

De préférence indépendantes de lalocalisation (migration).

- L’adresse du site du serveur (@IP).- L’adresse dans le protocole qui

permet de l’atteindre (@port TCP)- La procédure à exécuter.

Plus finement- Le conteneur de la procédure à

atteindre.- La désignation de la procédure dans le

conteneur.


Liaison

Retrouver la procédure à partir de laréférence.

- Liaison statique (au préalable)- Liaison dynamique avec utilisation

d’un annuaire de références.- Liaison dynamique avec utilisation

d’un annuaire d’interfaces (liaisonretardée).

RPC : Mise en œuvre de la liaison

Enregistrement

Communication réseau

Consultation

Interaction RPCProcédureAppelante(client)

ProcédureAppelée(serveur)

SoucheAppelant(client)

SoucheAppelé(serveur)

Service de nommage(désignation)

Pile réseauAppelant(client)

Pile réseauAppelé(serveur)


EXEMPLE : ENVIRONNEMENT D'APPEL

DE PROCEDURE DISTANTE DCE

DCE : ARCHITECTURE

- DCE ‘DISTRIBUTED COMPUTING

ENVIRONMENT’ est une boite à outils pourdévelopper des applications réparties.

- Services organisés autour d’un RPC.

SYSTEME D'EXPLOITATION

FONCTIONS DE TRANSPORT D'UNE ARCHITECTURE RESEAU

ACTIVITES

"THREADS"

Appel de

procédure

distante

RPC

SERVICES

DE

SECURITE

SERVICES

ANNUAIRE

DNS X500

SERVICES

DE

SYNCHRO

D'HORLOGE

SERVICES

DE

FICHIERS

REPARTIS

APPLICATION DCE

Remarques

- Certains services en utilisent d’autres.

- Existence de fonctions transversales :administration et outils de développement.


DCE : Evaluation

Avantages

- Accès à un ensemble d’API systèmesrépartis via des interfaces normalisées.

- Pour une structuration d’applicationsréparties ‘gros grain’ (les entitéscommunicantes sont plutôt des processus)

- Un standard assez diffusé (surtoutcomme base de Microsoft DCOM).

Inconvénients

- Développement d’applications ’grain fin’(les entités sont de la taille d’un objet oud’une variable) très lourde.

Utilisation des API des services d’activités(‘threads’) et d’appel distant (RPC).

- Peu d’outils de développement disponible.


RPC Version de base : Conclusion

Un mécanisme améliorant et simplifiantde façon significative la structuration des

applications réparties par rapport aumode message.

Un mécanisme de bas niveau

- Permet de décrire l’interaction d’appel deprocédure entre deux programmes : pas devision globale de l’application.

- Mécanisme de base d’appel synchrone :besoin de sémantiques plus variées, deservices additionnels : désignation,sécurité, …

- Outils de développement limités à lagénération automatique des souches mais àla base rien pour le déploiement, la miseau point ….



A OBJETS REPARTIS


Client serveur à objets répartis

A la convergence de deux approches.

L'approche objet

- Objet : une unité de programmationtrès utilisée permettant une structurationdes applications performante.

- Objet : associe les traitements et lesdonnées en rendant les codes moinscoûteux à développer, à maintenir, àréutiliser.

Données

Methode M1Methode M2

Objet O

AbstractionComportement communs => Typage.

EncapsulationAssociation des actions aux données.

HéritageRéutilisation du code.

PolymorphismeRéutilisation des références.


La répartition

Une intégration de l’univers objet et del’univers réparti

Données

Méthode M1 Méthode M2

Données

Méthode M3

M3

Site S1 Site S2Objet O1 Objet O2

- Placement des objets sur différentssites, les réseaux permettent réalisation del’opération d’invocation entre objets.

- L'interface du système d'objet répartiest un ensemble de primitives ou unlangage objet concurrent et réparti offrant lapossibilité d'implanter et d'exécuter à lademande des objets (donnée, traitement)sur des sites quelconques. . Création à distance d'instances . Exécution à distance des méthodes.

. Autres fonctions ou services: transactionnel, sécurité,placement ...


Objets répartis : Réalisation d’uneinvocation

Eléments d’une invocation

- Référence d’objet (‘pointeur universeld’objet au niveau système réparti)

- Identification de la méthode appelée(une chaîne).

- Paramètres d’appel et de retour etsignaux d’exception Modes de transmission possibles

. par valeur (types élémentaires et typesconstruits).

. par référence (objets)


Client serveur à objets répartis : mise enœuvre d’une invocation

Retour ParamètresExceptions

Référence MéthodeParamètres

APPEL

Objet clientSOUCHE

CLIENT

Objet serveurS SO EU RC VH EE U R

EtatMéthode 1Méthode 2

Méthode n


Systèmes d’objets répartis homogènes‘langages’

- Une représentation unique des objetspropre à un langage.

Typiquement java,Instanciation de classes java.

- Un mode d’interaction optimisé(simplifié).

Typiquement Java RMI(‘Remote Method Invocation’).


Systèmes d’objets répartis hétérogènes‘ouverts’

- Supportent une variété importante deformes d’objets (choix des références, dereprésentation, d’invocation, ….) définispar différents environnements langages etsystèmes.

- Un mode d’interaction unique surlequel se projettent tous les modesd’interaction.

OMG/CORBA‘Object Management Group / CommonObject Requests Broker Architecture’

Microsoft OLE/DCOM"Object Link Embedding / DistributedComponent Object Model".


ENVIRONNEMENT A OBJETS REPARTIS,EXEMPLE : CORBA

Un modèle de référence pour unearchitecture dédiée aux d'objets répartis.

"ORB Object Request Broker"

ServicesCORBA

Objets applicatifs

FacilitésCORBA

Environnement cooperatif de composants client-server

Echangeur de requêtes objets

CORBA permet à des objets (descomposants) d'interagir en univers

ouvertDécouvrir la localisation, réaliser lesinvocations, pour de nombreux langages,environnements d'exécution, réseaux decommunication.


ARCHITECTURE CORBA 2.0

Client

Invocation dynamique

Souches clients (invocation

statique)Interface

ORB

Référentiel d'interfaces

Souches serveurs Squelettes

Squelettes dynamique

Serveur(appelant) (appelé)

Adaptateur d'objets

Noyau échangeur de requêtes ("ORB Core")

In Arguments

Out ArgumentsValeurs retour

Operation ()

(protocoles GIOP / IIOP)

Valeurs d'appel

DIIIDL Stubs

DSI IDL Skeletons"OA

Object Adapter"

Référentiel d'implantations

Ex : L'interface d'invocation statiqueLangage IDL CORBA

("Interface Definition Language").

Les souches clients sont définies dans l'IDLCORBA ("Interface Definition Language").


Exemple de déclaration d'interface enlangage IDL

module Voiture{ /* Définition d'une classe cabriolet */ interface Cabriolet :véhicule_thermique ;

{attribute integer consommation ;exception Panne (string explication) ;void accélère ( in short durée)

raises (Panne) ;void freine ( in short durée)

raises (Panne) ;....}

interface Monospace :véhicule_thermique;

{attribute integer place ;void accélère ( in short durée)....}

} /* Fin de module */


Objets répartis : Conclusion

Avantages

Si le paradigme objet réparti est adopté :uniformisation de toutes les abstractions

utilisées sous le concept objet.

Simplifie et uniformise les accès et lescommunications offerts par les réseaux,les interfaces systèmes et les codesutilisateurs.

- Désignation universelle. - Interactions de communication

simplifiées et universelles. - Protection et sécurité universelle


Inconvénients (actuels)

- Performance des systèmes etapplications développées en approcheobjets répartis.Les solutions objets imposent des délaisd'interactions très importants.

- Faiblesse des outils dedéveloppement (production desapplications, déploiement,administration ….

- Faiblesse de la normalisationpermettant l'interopérabilité desapplications.



A COMPOSANTS


Client serveur à composants :Origines

La gestion de documentscomposites

Objectif : simplification du processus decréation et d’utilisation des documentscomposites c’est à dire formés à partir dedocuments d’origines différentes.

Problèmes à résoudre : interopérabilitéentre composants logiciels binaires crééspar des utilitaires différents.

Solutions : Environnement d’interactionunique en approche client serveur, formatsde données pivot, procédure de conversion.

Exemples:OLE/COM, OPENDOC/CORBA

La synthèse graphique

A partir d’objets graphiques : mêmeproblème que précédemment.


Illustration gestion de documentscomposites

OLE/COM : Objects Linking andEmbedding Component Object Model

Opendoc :

Document composite

Lien versdocument 1

Lien versdocument 2

Copie dedocument 3

Liens(linking)

Document 1(image)

Document 2(tableau)

Document 3(texte)

Incorporation(embedding)


Client serveur à composants :la vision actuelle (1)

Quelques idées pour une notion decomposant qui diffère du modèle objet

réparti.

1 Composant : une unité de code de taillesignificative

Idée assez souvent reprise bien qu’un peucontroversée.

2 Composant : une unité de réutilisationet d’intégration

Réutilisation : code (binaire) existant àintégrer dans une application.Notion de composant sur étagères.COTS : ‘Components Off The Shelf’.Intégration : rajouter de la glu.ADL : ‘Architecture Definition Language’.


Client serveur à composants :la vision actuelle (2)

3 Composant :une unité d’administrationen réparti

Déploiement : Un code développé pour unenvironnement système et qui doit retrouverpour son exécution cet environnement(conteneur).Suivi : du fonctionnement du composant.

4 Composant: pour associer despropriétés non fonctionnelles à un code

Code de base : pour un environnementdonné, doit être adapté pour supporter unautre environnement : pannes, temps réel,…Propriétés non fonctionnelles : ajoutées àla sémantique fonctionnelle du service. Persistance : service transactionnel. Echéances : QOS temps réel, Sécurité : authentification des clients etautorisation des accès.


Composants : Les avantages attendus

La possibilité de construire des logiciels parassemblage de composants commerciaux.

Réutilisation de logiciels existants testés.

Amélioration de la modularité et desinterfaces.

Cycle de développement raccourci.

Extensibilité en exécution (‘Run-time’)des applications basées composants.

Des systèmes plus maintenable.

Amélioration des moyens decommunication.

Construction de systèmes plus portables.

Des modèles de développements logicielsplus abstraits (scripts langages ADL)


ENVIRONNEMENT A COMPOSANTS,EXEMPLE : CCM ‘CORBA COMPONENTS

MODEL’

Un apport important de CORBA 3 quiétend sur différents points le modèle

objet réparti.

CORBA extensions CIDL ‘ComponentImplementation Definition Language’

Notion de ports facettes, réceptacles,sources et puits d’événements, attributs.

Pour définir un graphe de connexions.- Interfaces multiples.- Interfaces offertes (réceptacles) et

demandées (clauses use et provide)

Un service de configuration decomposants

- Notion d’attributs


Fonctionnalités CCM

Un service d’événements prévu d’emblée‘Notification Service’ (modèle push)

Une standardisation du cycle dedéveloppement CIF

‘Component Implementation Framework’

Une standardisation du cycle dedéploiement

Notion de conteneur : gère un composantselon ses besoins.

- Une vue unifiée pour le composant del’environnement en exécution.

- Interfaces offertes aux composantspour les services CORBA (minimumPOA et ORB, autres servicespersistance, sécurité, selon besoins).

Une proposition qui récupère la baseobjets répartis CORBA existante


Client serveur à composants : Conclusion

Avantages

Un objectif atteint: offrir des solutions àquelques problèmes bien identifiés del’approche objets répartis en insistantd’abord et avant tout sur la réutilisation.

Inconvénients

De nombreux problèmes restent posés

- Courtage : Retrouver un composant enfonction de ses propriétés syntaxiques maisaussi sémantiques pour apparier lesinterfaces demandées et offertes, les besoinssystèmes et les conteneurs.

- Cadre pour l’adaptation des composantsà des environnements quelconques :programmation par aspects.

- Faiblesse de la réflexion d’ensemble surla répartition.



A CODE MOBILE


Code Mobile : Généralités

Assurer les interactions distantes endéplaçant le code à exécuter.

Exemples : requêtes SQL, applet Java,sérialisation d’objets JAVA …

Motivation essentielleRapprocher les traitements des donnéespour réduire le volume des échanges.

Nombreux exemples évoqués- Collecte d’informations disséminéesdans un réseau (recherche et filtrage).- Surveillance de données.- Administration de réseaux.- Reconfiguration, Placement.- Réseaux actifs.- Distribution d’informations ciblées.- Applications orientées flots dedonnées (‘workflow’).- Négociation (agendas, commerceélectronique, enchères, …).- Calcul parallèle (envoi de calculs).- Jeux en réseaux.


Code Mobile : Nombreux problèmes

Interopérabilité des codes exécutables :- Mêmes architectures machines,

mêmes environnements systèmes- Utilisation d’interpréteurs dans les

mêmes environnements.

Sécurité (avec méfiance mutuelle)- du site acceptant du code.- De l’agent mobile

Structuration des applications à basede code mobile : Intégration avec d’autres approchesdu client serveur. Transparence de la programmation encode mobile ?

Partage des ressources Quelle cohérence ?

Que déplace t’on ?Comment ? Migration faible/forte ?


Code Mobile : Modèles d’exécutionpour la mobilité

- Code à la demande. Mobilité Faible.On bouge du code sans contexte variable(Exemple : ‘applet’ java)

- Agents Mobiles. Mobilité Forte.On bouge du code exécutable, desdonnées locales, un contexte d’exécution

Processus 1

Site A Site B

CodeProcessus

Code

Site A

Code, CTX

Processus 2

Site B

Code, CTX


Code Mobile : Etude de la mobilité‘forte’

Notions utilisées

Objets: les unités de codes exécutables(clients et serveurs) (objets passifs).

Sites : environnements d’exécution.

Activités: flots de contrôle des appelss’étendant sur plusieurs objets ou sites.

Domaines : ensembles de droits sur desressources d’une machine (en particulier surdes segments de mémoire).

Base de la classification

- Les activités sont dans le même domaine.- Les activités sont dans des domainesdifférents du même site.- Les activités sont dans des domainesdifférents de sites différents.


Types de partage

Partage dans le même domaine- Réalisé systématiquement (notion degrappe, cluster d’objets).

Partage entre domaines différents- Opération de changement de domaine.- Mécanisme de couplage entre domaines etobjets.

Partage en exclusion mutuelle- Une seule activité est autorisée à uninstant donné à utiliser un objet- Agréable pour assurer la cohérence desérialisation des objets.

Partage avec réplication- Nécessité de mise en œuvre d’unestratégie de cohérence par l’applicationentre les différentes copies.


Partage par migration en exclusionmutuelle

N’autoriser le partage que sur un seul site.=> Exclusion mutuelle entre les sites ayantaccès à l’objet.=> Mécanisme de déplacement des objetsou des activités.

Migration des activités

- Une activité voulant accéder à un objetdéjà couplé sur un autre site change de site.- On effectue alors un partage d’accès entreactivités sur le même site (même domaineou domaines différents).

Migration des objets

- Une activité voulant accéder à un objetd’un autre site demande le découplage del’objet (opération de fermeture nécessaire sil’objet est en cours d’accès).- L’objet est déplacé sur le site client.- L’objet est couplé sur le site client.


Partage par réplication

- Autoriser la possibilité le couplaged’un même objet sur plusieurs sites enmême temps.

- Assurer la cohérence entre les versionsdes objets qui permet aux applicationsutilisatrices de fonctionner correctement.

a) Les problèmes de cohérences sont vusau niveau applicatif : détection deslectures et des écritures dans lesvariables partagées à la compilation=> Appel à un code de mise en œuvred’une cohérence de partage.

b) Les problèmes de cohérence sont vusau niveau des accès mémoire : plusfacile en exécution à l’aide des outils dedétection matériels.=> Le partage est vu au niveau de lamémoire physique (approche demémoire virtuelle partagée répartie).


ENVIRONNEMENTS A CODE MOBILE,EXEMPLE : LES AGLETS

Une extension proposée par IBM Japonqui étend le modèle des applets Java.

- Comme une applet une aglet permet latransmission d’un code Java.- L’API Aglet permet également letransport de l’état (en fait une partie).- La gestion de la sécurité est renforcéepar l’utilisation par les aglets d’ungestionnaire de sécurité spécifique.


Le cycle de vie d’une aglet

Created: création : initialisation de l’état,lancement des activités ‘threads’.

Cloned: duplication : l’état courant originald’une aglet est dupliqué dans un clone).

Dispatched: Une aglet migre sur un autrehôte avec son état.

Retracted: Une aglet ayant migré estramenée du site distant avec son état.

Deactivated: Une aglet est mise ensommeil : son état est stocké sur disque.

Activated: Une aglet désactivée estréctivée : son état est restauré partir dudisque.

Disposed of: Une aglet est détruite : sonétat est perdu.


Migration d’une aglet

Mécanisme de sérialisation Java(JDK 1.1)

Un objet Java appartenant à une aglet esttransmis d’un site à un autre au moyen dumécanisme de sérialisation : transformationen une suite d’octets et opération inverse.

Sérialisation d’une aglet

- Sérialisation d’un objet Java de baseassocié à l’aglet.- Sérialisation de l’arbre des objets Javaformant l’aglet.- Sérialisation d’une partie du contexte. Image du tas dans sa partie données. Pas de sérialisation du pointeurd’exécution courant, ni de la pile(difficultés techniques liées à la JVM).=> Pas tout à fait encore complet.=> Tout ce que l’on veut envoyer doit êtreplacé manuellement dans le tas au momentde la migration.


L’API Aglets

Cinq classes standards peuvent êtreredéfinies pour adapter l’aglet lors d’uneopération de migration:onCloning() : appelé avant clonageonDispatch() : appelé avant migration.OnReverting(): appelé avant retraction.onDeactivating() : appelé avant la

désactivation.onDisposing() : appelé avant la

destruction.Les points d’entrées correspondants sont :clone(), dispatch(), retract(),deactivate(), dispose().

Lors d’une initialisation, on exécute selonles cas run()de la classe.onCreation() : la première foisonClone() : lors d’un clonageonArrival() : lors d’une migration ou

d’un retouronActivation() : lors d’une activation.


Code Mobile : Conclusion

- Des avantages indiscutables pour le clientserveur dans certaines circonstances :besoin de dynamicité, d’adaptabilité,

Possibilité d’exécution à distance Code à la demande

- Un domaine très porteur Nombreux prototypes de recherche Concepts et mécanismes encore en coursd’étude.

- Des problèmes non résolusSécurité.

Environnements de développement. Des applications à réaliser.



A MEMOIRE PARTAGEE REPARTIE


Mémoire partagée répartie:Généralités

Réalisation des interactions distantesen mémoire commune répartie comme

espace de communication.

ExemplesOpération read et write sur des pages. Exemples : treadmarks, …Modèles à espaces de tuples Exemples : BD réparties, javaspacesModèles à espaces d’objets répartispartagés.

Motivation essentielle

Offrir à un développeur les conditions detravail de l’univers centralisé :programmation de la coopération parvariables partagéesmasquant les difficultés de la répartition.


Mémoire partagée répartie : Lesproblèmes principaux

Performance des implantations.

Support des diverses cohérences. Cohérences fortes Atomique, séquentielle Cohérences faibles Causale, relachée.

Support des outils de développementexistants : langages, compilateurs, dévermineurs.


Mémoire partagée répartie : principesde réalisation

Une simulation d’un espace mémoireunique dans un ensemble d’espaces

mémoires réels distribués.

- Espace d’objets répartis partagés.- Interface d’accès commune (nommage,invocation des méthodes, …)- Mode de réalisation par projection del’espace virtuel partagé dans l’espacemémoire réel des différents sites.

Mémoire

Site A

Objet 1

Mémoire

Site B

Objet 3

Espace virtuel commun

Objet 1 Objet 2 Objet 3


ENVIRONNEMENTS MEMOIRE PARTAGEE

REPARTIE, EXEMPLE : JAVASPACES

- Un javaspace : un espace de tuples ouentrées.

- Une entrée : un ensemble de référencesà des objets Java.

JAVASPACE

Entrée

Références


Javaspaces : les opérations de base

- Ecriture dans un javaspace (read).

- Lecture dans un javaspace (write)

- Retrait dans un javaspace (take)

- Notification de l’écriture d’une entrée (notify).

- Transaction regroupant plusieursopérations dans plusieurs javaspaces(respect des propriétés ACID). Cohérence transactionnelle (de sérialisation) Persistance transactionnelle (technique de validation).


Javaspaces : les techniquesd’utilisation

- Pas de modifications sur les données :on ajoute ou on retire des références.

- Coopération entre applicationsréparties pour connaître des références(mécanismes d’accès au moyen de‘templates’, des modèles pour larecherche d’entrées). Découplage entreclient et serveur.

- La sérialisabilité transactionnellegarantit la cohérence des accès.

- Le partage des objets réels s’effectueensuite au moyen de l’invocation deméthodes (RMI).

- Les objets réels peuvent être dupliqués.Tout reste à construire (cohérence) dansle partage des objets réels.


Mémoire partagée répartie:Conclusion

Avantages

- Facilité de développement d’uneapplication répartie ou de portage d’uneapplication centralisée en univers réparti.

- Performances excellentes lorsquel’objet est chargé localement.

Inconvénients

- Performances mauvaises lorsquel’objet est distant (les cohérences fortessont très coûteuses en réparti).- Les cohérences faibles sont plusperformantes mais délicates d’emploi.

- L’approche est très peu ouverteun seul langage interprété ou une seuleforme de présentation des données sinonil faut en plus convertir les données àchaque déplacement.


Conclusion : Modèles et outils deprogrammation pour le client-serveur


Problème majeur pour le développeurd’applications: quel modèle, quel outil

Une très grande variabilité de l’offreaussi bien sur le plan des modèles que

sur celui des plateformes.

- Mode de synchronisation distante : synchrone ou asynchrone.

- Approche langage ou système effort de développement complexité du système produit.

- Développement d’un nouveau codepour le réparti ou intégration dessolutions centralisées existantes.

- Granularité des codes communicantsgrain moyen ‘in the small’ : objet répartigros grain ‘in the large’ : composants.


Bibliographie

Références générales

R. Balter ‘Modes de structuration d’applicationsréparties’. Cours de l’école d’été : Construction desapplications réparties.http://sirac.inrialpes.fr/ecole/99/cours/index.html

G.Gardarin, O. Gardarin. ‘ le client serveur’ Eyrolles1996

R. Orfali, D. Harkey, J. Edwards ‘ Client serveur guidede survie’ Wiley

Modèles à messages et à événements

http://www.software.ibm.com/ts/mqserieshtttp://www.openhorizon.comhttp://rv.tibco.com

Modèles à RPC et à Objets

http://www.osf.org/dcehttp://www.omg.org/corba.htm


Bibliographie (suite)

Modèles à code mobile

D. Hagimont, J. Mossière ‘Problèmes de désignation,de localisation et d’accès dans les systèmes répartis àobjets’ TSI 15(1) 1996

Sacha Krakowiak ‘Code mobile, Principes et mise enœuvre’ Cours de l’école d’été : Construction desapplications réparties.http://sirac.inrialpes.fr/ecole/99/cours/index.html

J.E. White, Telescript Technology: The Foundation for theElectronic Market-place, General Magic Inc., MountainView, CA, 1994.

Documents

Cours d’introduction Modèles d’interactions pour le …t4clive.free.fr/pour%20bien%20reussir%20ton%20BTS%20%3B-)/co…Coopération : Le point de vue global Une application coopérative