Plan

Middleware
Introduction
1. Modèle de programmation
Lionel Seinturier 1.1 Côté serveur
1.2 Communications
Université des Sciences et Technologies de Lille
2. Client/serveur orienté objet
Lionel.Seinturier@univ-lille1.fr
3. Bibliographie

25/09/08

Middleware 1 Lionel Seinturier Middleware 2 Lionel Seinturier

Introduction Introduction
Problématique Vocabulaire

• application répartie
..... • exécutées par des plates-formes dite middleware (en français intergiciel)

Software
Permettre à un programme de s’exécuter sur plusieurs machines Middleware
(PC, mainframe, laptop, PDA, …) reliées par un réseau
- à large échelle (Internet) Middleware unifie l'accès à des machines hétérogènes
- local (intranet) en terme de
• CPU
Operating system
∩ de plusieurs domaines de l’informatique • OS
• langage de programmation
- système d’exploitation - système d’exploitation répartis Hardware • représentation des données en mémoire
- réseau - librairies de programmation réseau
- langage de programmation - langages de programmation étendus

Middleware 3 Lionel Seinturier Middleware 4 Lionel Seinturier

 Introduction Introduction
Middleware Problématique du middleware

• masque hétérogénéité Les environnements middleware permettent

Application répartie
des machines et des à ≠ types de matériels (PC, mainframes, laptop, PDA, téléphones, ...)
systèmes de communiquer à distance
• masque répartition Middleware = intergiciel
des traitements et
données
• fournit une interface OS x OS y
aux applications
(modèle de
programmation + ..... Middleware
API)

« Middleware is
everywhere »
© IBM

Middleware 5 Lionel Seinturier Middleware 6 Lionel Seinturier

Introduction Introduction
Problématique Problématique

Nombreux paradigmes de communication associés Deuxième paradigme

Ö le principal : interaction requête/réponse ou client/serveur Ö interaction par messagerie (MOM : Message-Oriented Middleware)

requête retrait
prog. rés prog. prog. dépose Boîte à prog.
client eau serveur client message lettres serveur
réponse message

Interaction client/serveur Attention ≠ envoi message sur socket

Protocoles de niveau applicatif (pas transport) + propriétés (ex transactionnelles)
= 1 requête + 1 réponse
= demande d'exécution d'un traitement à distance et réponse
MOM : comm. asynchrone (fonctionnement client et serveur découplés)
≈ appel procédural étendu au cas où appelant et appelé
Interaction client/serveur comm. synchrone
ne sont pas situés sur la même machine

Middleware 7 Lionel Seinturier Middleware 8 Lionel Seinturier

 Introduction Introduction
Problématique Client/serveur

En général, le middleware Notion d'application client/serveur 2 tiers ou 3 tiers

• n'est pas visible par l'utilisateur final
Découpage d'une application
• est un outil pour le développeur d'applications
• se retrouve enfoui dans les applications • présentation
• traitements
• données
Middleware permet de mettre en oeuvre des serveurs
• à finalité fixe : serveur Web, serveur de fichiers, serveur de BD, ...
Problématique
• effectuant des traitements quelconque : CORBA, EJB, .Net, Web Services, ...
Par rapport à 1 client et 1 (ou +sieurs) serveurs
qui assure ces fonctionnalités ?

Middleware 9 Lionel Seinturier Middleware 10 Lionel Seinturier

Introduction Introduction
Client/Serveur 2 tiers Client/Serveur 3 tiers
Caractéristiques Caractéristiques
• 1 gros serveur (mainframes) client • 1 serveur de données et 1 serveur de traitement
présentation
• n terminaux légers connectés au serveur • n PC avec IHM "évoluées"

client Avantages Avantages

présentation
• pas de duplication de données (état global observable) serveur • meilleure répartition de charge
• gestion simple de la cohérence et de l’intégrité des données traitement • économiquement moins cher
• maîtrise globale des traitements • + évolutif

Inconvénients Inconvénients
• modèle trop rigide qui n’assure pas l’évolutivité serveur • administration + compliquée
serveur • souvent solutions propriétaires fermés données • mise en oeuvre + compliquée
données • économiquement trop coûteux
+ traitement

Middleware 11 Lionel Seinturier Middleware 12 Lionel Seinturier

 Introduction Introduction
Client/Serveur 3 tiers Évolution du middleware

Evolution historique du terme client/serveur 3 tiers • envoi de message

• RPC
• tiers 1 (PC) tiers 2 (serveurs départementaux) tiers 3 (serveur central) • RPC objet
• tiers 1 (client) tiers 2 (BD locale) tiers 3 (BD globale) • bus logiciel
• serveur d'applications
Actuellement • service
• tiers 1 (client) tiers 2 (serveur de traitement) tiers 3 (serveur de données)

Middleware 13 Lionel Seinturier Middleware 14 Lionel Seinturier

Introduction Introduction
Envoi de messages Remote Procedure Call (RPC)
• primitives send & receive
• appel d'une procédure sur une machine distante
• conception des progs client et serveur en fonction messages attendus et à envoyer
• groupement de 2 messages : appel & retour
ports ports • adressage : @IP + nom fonction
socket
• définition des signatures des procédures
socket
• compilateur de souches client et serveur
@ IP @ IP
Exemple : RPC Sun
• socket : au-dessus des protocoles TCP & UDP
struct bichaine { char s1[80]; char s2[80]; };
• primitive bloquante vs non bloquante program CALCUL {
• fiabilité version V1 {
int multpar2(int) = 1;
• ordre des messages string concat(struct bichaine) = 2;
• contrôle de flux void plus_un() = 3;
• mode connecté vs non connecté } = 1;
} = 0x21234567;

Middleware 15 Lionel Seinturier Middleware 16 Lionel Seinturier

 Introduction Introduction
RPC Objet Bus logiciel CORBA
.....
• mise en commun concepts RPC et prog objet • multi-OS, multi-langage
• appel d'une méthode sur un objet distant • métaphore du bus logiciel
• éventuellement +sieurs objets par machine • langage IDL
• adressage serveur de noms + nom logique ORB ORB
x y
module tp7 {
Exemple : Java RMI interface CalculatriceItf {
import java.rmi.Remote; double add( in double val1, in double val2 );
import java.rmi.RemoteException; double sub( in double val1, in double val2 );
double mult( in double val1, in double val2 );
interface CompteInterf extends Remote { double div( in double val1, in double val2 );
public String getTitulaire() throws RemoteException; };
public float solde() throws RemoteException; };
public void deposer( float montant ) throws RemoteException;
public void retirer( float montant ) throws RemoteException; • services : nommage, courtage, transaction, …
public List historique() throws RemoteException;
}

Middleware 17 Lionel Seinturier Middleware 18 Lionel Seinturier

Introduction Introduction
Composants et serveurs d'application Service

CORBA CCM • SOA : Software Oriented Architecture

Sun EJB serveur d'applications serveur d'applications • SaaS : Software As A Service
Microsoft .NET/(D)COM+
conteneur conteneur Modèle "économique" tout est service
composant
connexions
• monter en abstraction client composant composant Principes des SOA
/ objet
• architecture logicielle • Encapsulation existant encapsulé pour pouvoir être réutilisé avec SOA
composant
Service
Service

Service

• Loose coupling minimiser les dépenses

• Contract communication ne se font que via un accord entre services
serveur d'applications • Abstraction masquer la logique du service au monde extérieur
• framework • Reusability découpage des services pour promouvoir la réutilisabilité
• héberger, administrer Système/Middleware • Composability services peuvent être composés et coordonnés pour former des services composites
• Autonomy services contrôlent la logique qu'ils encapsulent
• Optimization services peuvent être optimisés individuellement
voir aussi servlet (Tomcat, …) • Discoverability services sont fait pour être découvert

Middleware 19 Lionel Seinturier Middleware 20 Lionel Seinturier

 Introduction Introduction
Service Service

1ère vague Épuration 2ème vague … en fait

Constat d'une trop grande hétérogénéité du middleware réintroduction des notions de composants et d'architecture logicielle
taille, OS, langage, cible matérielle, modèle de programmation • Enterprise Software Bus (par ex. Sun JBI)
Focalisation sur un PPCM (plus pétit commun dénominateur) • OSGi
• domotique (box, …)
d'où W3C Web Services = HTTP + XML + SOAP • embarqué (secteur automobile, …)
• modularité (voir Java 7), système à plugins (Eclipse, serveur d'applications)
adoption par Sun (Java EE), Microsoft (.NET) comme solution • SCA (Software Component Architecture)
pour l'intéropérabilité (interne et externe) • donner une structuration aux applications orientée services
• supporter différents
langages de programmation, protocoles de communication,
langages de définition d'interfaces, services non fonctionnels

Middleware 21 Lionel Seinturier Middleware 22 Lionel Seinturier

Introduction Introduction
Concepts de base du middleware Concepts de base du middleware

Cœur du middleware • objet, composant, service

• interface, contrat
Ensemble de concepts génériques [Pautet 2001] • souche, squelette
• service techniques (aussi appelés non fonctionnels ou extra-fonctionnels)
• adressage définir une référence unique • annuaires (registre, moteur de recherche, pages jaunes, …)
• transport échange de données • sécurité (contrôle d'accès, cryptage, authentification, …)
• liaison associer une entité locale à une référence • transaction
• représentation transformation des données dans un format commun • persistence des données,
• protocole interactions entre entités • concurrence
• activation à la réception d'un message, définition de l'entité traîtant • synchronisation
• exécution associe les ressources nécessaires • réplication
• migration
•…

Middleware 23 Lionel Seinturier Middleware 24 Lionel Seinturier

 Introduction 1. Modèle de programmation
Fournisseurs de solutions middleware Modèle de programmation
• OMG CORBA
• W3C Web Services 1.1 Côté serveur
• OSGi service + composant + architecture logicielle (Java)
• OSOA service + composant + architecture logicielle (Java, C++, PHP, …)
1.2 Communications client/serveur
• Sun Java + Java EE (J2EE) Modes
• IBM, Oracle, BEA fournisseurs de solutions Java EE Concepts
• Microsoft C# + .NET Notion de connexion
Gestion d'états
• mais aussi tous les autres "grands" du domaine (HP, BEA, IONA, Fujitsu, SAP, …) Représentation des données
• de nombreuses briques open-source (Apache, Eclipse, OW2/ObjectWeb) Passage de paramètres
• de nombreux domaines applicatifs Traitement des pannes
• applications Web (commerce en ligne, …), systèmes d'information, BD
• embarqué (domotique, applications mobiles – téléphones, PDA – , capteurs, …)
• infrastructure télécom
• calcul intensif sur clusters et grilles
Middleware 25 Lionel Seinturier Middleware 26 Lionel Seinturier

1. Modèle de programmation 1. Modèle de programmation

Modèle de programmation Modèle de programmation

2 programmes Point de vue du client

requête
• 1 programme client 1. envoie une requête prog. rés
• 1 programme serveur 2. attend une réponse client eau
réponse
Ö processus distincts
Ö mémoires distinctes
Ö machines distinctes (sauf si répartition logique)
Point de vue du serveur
Selon le contexte 1 programme peut être client et serveur (ex. Napster, ...) 1. attend une requête requête
rés prog.
2. effectue un traitement et
• 1 programme client eau serveur
produit une réponse réponse
• 1 programme serveur qui pour rendre le service est client d'un 3è programme
3. envoie la réponse au client
• 1 programme serveur
Ö être client, être serveur, n'est pas immuable mais le serveur doit aussi pouvoir traiter
mais dépend de l'interaction considérée les requêtes de plusieurs clients

Middleware 27 Lionel Seinturier Middleware 28 Lionel Seinturier

 1.1 Côté serveur 1.1 Côté serveur
Plusieurs clients simultanément Plusieurs clients simultanément - 1 processus unique

1 bis. sélection de la requête à traiter

(FIFO ou avec priorité) prog. while (true) { 1 2 3 } prog.
serveur serveur

Plusieurs mises en oeuvre possibles pour le traitement de la requête Plusieurs clients envoient des requêtes simultanément
mais le serveur n'en traite qu'une à la fois
• 1 activité unique
• 1 activité par requête → simple
• 1 pool d'activités → pas de risque de conflit de concurrence
→ suffisant dans certains cas
rq : activité = processus ou thread (ex. 1 requête toutes les 10s qui demande 2s de traitement)

Middleware 29 Lionel Seinturier Middleware 30 Lionel Seinturier

1.1 Côté serveur 1.1 Côté serveur

Plusieurs clients simultanément - 1 processus par requête Plusieurs clients simultanément - pool de processus

Chaque arrivée de requête • pool fixe

déclenche la création d'un processus prog. • pool dynamique prog.
serveur serveur
while (true) { 1 fork() } Pool fixe
p1 p2 p3 ...
2 3 2 3 2 3 ... • 1 nombre constant de processus
• 1 processus qui reçoit les requêtes et les dispatche aux processus du pool
→ les clients sont servis + rapidement • si aucun processus n'est libre, les requêtes sont mises en attente
→ conflits éventuels en cas d'accès simultanés à une ressource partagée (ex. fichier)
Avantage
Problème : une concurrence "débridée" peut écrouler la machine - pas de risque d'écroulement
→ restreindre le nombre de processus traitants (pour peu que le nombre de processus soit correctement dimensionné)

Inconvénients
- un pool de processus inactifs consomme des ressources inutilement
- les pointes de traffic sont mal gérées
Middleware 31 Lionel Seinturier Middleware 32 Lionel Seinturier
 1.1 Côté serveur 1.1 Côté serveur
Plusieurs clients simultanément - pool de processus Persistance des données

Pool dynamique Problématique

prog.
Toujours avoir des processus prêt sans surcharger serveur le serveur gère-t-il des données globales partageables par tous les clients ?
inutilement la machine vocabulaire : état du serveur (NB: ≠ état du protocole)
→ le nombre de processus varie
→ mais le nombre de processus prêts est toujours compris entre 2 bornes Mode sans persistance (le + simple) Mode avec persistance
→ mélange des politiques 1 proc/req et pool fixe
• le service s'exécute uniquement en ex : serveur de fichiers,
fonction des paramètres serveur de BD
• nb max de proc (ex. 150)
• nb max de proc inactifs (ex. 20) : au delà on détruit les proc ex : calcul d'une fonction mathématique
Pb en cas d'accès simultanés
• nb min de proc inactifs (ex. 5) : en deça on crée de nouveaux proc
par ≠ clients
• nb proc créés au départ (ex. 15) Situation favorable pour de nbreux pbs
→ contrôle de concurrence
de système réparti (tolérance aux pannes,
rq : solution retenue par Apache équilibrage de charge, reprise après panne)

Middleware 33 Lionel Seinturier Middleware 34 Lionel Seinturier

1.2 Communications 1.2 Communications

Modèle de programmation Modes de communication

Client Serveur Client Serveur Client Serveur

1.1 Côté serveur
Synchrone Asynchrone Semi-synchrone
1.2 Communications client/serveur
Modes • Synchrone le client attend la réponse pour continuer son exécution
Concepts • Asynchrone le client n’attend pas de réponse et continue tout de suite
Notion de connexion • Semi-synchrone
Gestion d'états le client continue son exécution après l’envoi et
Représentation des données récupère le résultat ultérieurement
Passage de paramètres
Traitement des pannes - à futur explicite le résultat est stocké dans une boîte à lettres (BAL)
le client consulte cette BAL pour récupérer le res.
- à futur implicite le résultat est fourni automatiquement au client
par ex. via une variable du prog. client

Middleware 35 Lionel Seinturier Middleware 36 Lionel Seinturier

 1.2 Communications 1.2 Communications
Concepts boîte à lettres Mise en oeuvre des concepts
≡ interface d'accès
modèle de programmation
opération
Client Serveur
1. Appel local
enveloppe 1 10 6 5 2. Préparation du
≡ message message d’appel
Souche Souche 2. Envoi
client serveur 4. «Upcall» vers
Bât. M3
la souche serveur
USTL 2 9 7 4
5. Décodage du message
8 6..10 : Chemin inverse
Transport Transport
service de client serveur
façon d'écrire 3
messagerie les données ressources
≡ protocole adresse ≡ buffer, threads,
≡ encodage Vocabulaire français souche ou talon
cx rsx Vocabulaire anglais souche cl. = stub ou proxy, souche serv. = skeleton

Middleware 37 Lionel Seinturier Middleware 38 Lionel Seinturier

1.2 Communications 1.2 Communications

Connexion Gestion d'états du protocole de communication

Problématique Problématique
Délimitation des communications entre un client et un serveur 2 requêtes successives d'un même client sont-elles indépendantes ?
→ faut-il sauvegarder des infos entre 2 requêtes successives d'un même client ?
Mode non connecté (le + simple)
• les messages sont envoyés “librement” Mode sans état (le + simple)
• example : NFS
• pas d'info sauvegardée
• les requêtes successives d'un même client sont indépendantes
• ex : NFS, HTTP
Mode connecté
• les messages sont
Types de requêtes envisageables
• précédés d’une ouverture de connexion Rq : la cx est le + souvent
- demande d'écriture du k-ième bloc de données d'un fichier
• suivis d’une fermeture de connexion liée au transport (TCP)
• facilite la gestion d'état plutôt qu'au protocole
Types de requêtes non envisageables
• permet un meilleur contrôle des clients applicatif lui-même
- demande d'écriture du bloc suivant
• ex : FTP, Telnet, SMTP, POP, JDBC, HTTP
Middleware 39 Lionel Seinturier Middleware 40 Lionel Seinturier
 1.2 Communications 1.2 Communications
Gestion d'états du protocole de communication Représentation des données

Mode avec état Problématique

• les requêtes successives s'exécutent Comm. entre machines avec des formats de représentation de données ≠
en fonction de l'état laissé par les appels précédents → pas le même codage (big endian vs little endian)
→ sauvegarde de l'état → pas la même façon de stocker les types (entiers 32 bits vs 64 bits, ...)

Notion proche : session cliente dans un serveur Web 2 solutions

Suivi de l'activité d'un client entre le moment où il arrive et celui où il quitte le site
On prévoit tous les cas de conversions possibles
Pb : y a-t-il un mécanisme explicite qui indique au serveur que le client part ? (n2 convertisseurs)
- si oui (ex. déconnexion notifiée au serveur) alors ok
- si non
pb : aucun sens de conserver ad vitam les données de la session On prévoit un format pivot et on
heuristique : la session expire au bout d'un délai fixé effectue 2 conversions (2n convertisseurs)
inconv. : un client très lent peut revenir après expiration
→ (re)commencement d'une nouvelle session
Nbreux formats pivots : ASN.1, Sun XDR, sérialisation Java, CORBA CDR, ...
Middleware 41 Lionel Seinturier Middleware 42 Lionel Seinturier

1.2 Communications 1.2 Communications

Passage de paramètres Passage de paramètres

Problématique Mais copie/restauration pas parfait

Client et serveur ont des espaces mémoire ≠
Problème du double incrément
→ passage par valeur ok
→ passage par référence void m(&x, &y) { x++; y++; }
pas possible directement a=0; m(a,a);
une ref. du client n'a aucun sens pour le serveur (et vice-versa) résultat attendu a=2, résultat obtenu a=1 !!
Ö détecter les doubles (multiples) référencements
Solution : mécanisme copie/restauration Ö pas facile dans le cas général

1. copie de la valeur référencée dans la requête

2. le serveur travaille sur la copie Problème en cas de mises à jour concurrentes de la valeur référencée
3. le serveur renvoie la nouvelle valeur avec la réponse
4. le client met à jour la réf. avec la nouvelle valeur

Middleware 43 Lionel Seinturier Middleware 44 Lionel Seinturier

 1.2 Communications 1.2 Communications
Passage de paramètres Passage de paramètres

Définitions couramment adoptée (au lieu de valeur/référence) pb : IN/OUT et OUT pas tjrs faciles à gérer dans les lang. de prog.
- mode IN (entrée) passage par valeur avec la requête
ex : Java
- mode OUT (sortie) passage par valeur avec la réponse
- mode IN/OUT (entrée/sortie) copie/restauration de la valeur - types simples (int, float, ...) transmis par valeur
- objets transmis par référence
IN
Ö comment transmettre en IN/OUT (ou OUT) un int ?
Ö ≡ comment implanter la copie/restauration non prévue par la VM ?

Serveur
Client

- sans modifier le code du client, ni celui du serveur

- seuls codes "maitrisables" : souches client et serveur

OUT

• IN si le serv. modifie la valeur, le cl. ne "voit" pas cette modif.

• OUT si le cl. transmet une valeur, le serv. ne la "voit" pas

Middleware 45 Lionel Seinturier Middleware 46 Lionel Seinturier

1.2 Communications 1.2 Communications

Passage de paramètres Passage de paramètres

pb : IN/OUT et OUT pas tjrs faciles à gérer dans les lang. de prog. Solution
- pas possible de ne pas modifier les codes client et serveur
Illustration
- le client transmet un conteneur pour la valeur
4 4 4 class IntHolder { int x; }

Ö la souche cliente peut mettre à jour la valeur contenue

Serveur
Souche

Souche
Client

x=4;
x=5;
o.m(x);
4 4 4
5 5

Serveur
Souche

Souche
ih.x=4; Client
- la souche connaît simplement la valeur 4 o.m(ih);
ih.x=5;
- elle n'a pas la ref. de x
Ö elle ne peut pas la mettre à jour
ih.x=5 5 5

Middleware 47 Lionel Seinturier Middleware 48 Lionel Seinturier

 1.2 Communications 1.2 Communications
Traitement des pannes Traitement des pannes

Dans la majorité des cas Comportement possible en présence de pannes

• symptôme : absence de réponse
client envoie requête
• cause inconnue : réseau ? client ? serveur ?
si panne signalée par détecteur
alors signaler la panne au client
Techniques logicielles de détection des pannes
¾ la requête s’exécute (si pas de panne), sinon elle ne s’exécute pas
• heart beat périodiquement le serveur signale son activité au client ¾ comportement dit “au plus 1 fois” (0 fois ou 1 fois)
• pinging périodiquement le client sonde le serveur qui répond

¾ les résultats ne sont jamais sûr à 100%

¾ périodicité délicate à régler
¾ impossibilité de distinguer une “vraie” panne d’un ralentissement dû à une surcharge
¾ pas une vraie détection, possibilité de fausse détection
¾ on parle de suspicion de panne

Middleware 49 Lionel Seinturier Middleware 50 Lionel Seinturier

1.2 Communications 1.2 Communications

Traitement des pannes Traitement des pannes

2ème comportement possible en présence de pannes : “au moins 1 fois” (1 fois ou n fois) 3ème comportement possible en présence de pannes

client envoie requête idem “au moins 1 fois”

tant que résultat non reçu + numérotation des messages
attendre délai // éventuellement attente interrompue par détecteur en vue de détecter (côté serveur) les réémissions
renvoyer requête
¾ le traitement s’exécute exactement 1 fois
¾ tentatives de réémissions pour compenser les pertes de message
¾ en cas de fausse détection de panne
le message est reçu +sieurs fois Ö le traitement s’exécute +iseurs fois
ok si idempotent
i.e. plusieurs exécutions du même traitement ne doivent pas poser problème
idempotent x:=5 lire_fichier(bloc k) ecrire_fichier(bloc k)
¬idempotent x++ lire_fichier_bloc_suivant()

Middleware 51 Lionel Seinturier Middleware 52 Lionel Seinturier

 2. C/S OO 2. C/S OO
Client/serveur orienté objet Client/serveur orienté objet

But : coupler la notion d'objet avec les concepts client/serveur

2.1 Nommage
Objectifs
2.2 Sécurité d’accès
• meilleure modularisation des applications
2.3 Durée de vie • entités logiciels plus réutilisables
• applications mieux packagées, portables et maintenables plus facilement
2.4 Objets concurrents
2.5 Synchronisation Résultats
• unité de distribution = objet
2.6 Migration • un objet = un ensemble de traitement fournis par ses méthodes
• interaction client/serveur = invocation de méthode
2.7 Réplication
2.8 Ramasse-miettes Ö Nombreux aspects techniques à intégrer pour y arriver

Middleware 53 Lionel Seinturier Middleware 54 Lionel Seinturier

2.1 Nommage 2.2 Sécurité d’accès

Identifier les objets dans un environnement réparti Gérer le partage des objets dans un environnement réparti

• deux objets ≠ sur le même site ou sur des sites ≠ Pour des raisons de sécurité, l’accès à certains objets peut être restreint
ne doivent pas avoir la même identité (on parle de référence)
- en fonction de l’identité de l’objet appelant
• la référence sert à «retrouver» l’objet pour pouvoir invoquer ses méthodes
ex : seuls les accès en provenance de l’intranet sont autorisés
• généralisation de la notion de pointeur à un environnement réparti
- à partir d’une liste de contrôle d’accès
ex : mot de passe, mécanismes de clés de session, ...
Deux techniques principales
• un ID sans rapport avec la localisation généré par une fonction mathématique La restriction peut
+ une table de translation entre l’ID et la localisation de l’objet
- interdire complètement l’accès à l’objet
• un ID en deux parties : son site de création + un numéro local unique
- fournir une vue «dégradée»
ex : autoriser les méthodes qui fournissent un service de consultation
Recherche d’un objet à partir de sa référence
mais interdire celles qui modifient l’état de l’objet
• annuaires de localisation centralisés ou répartis, ou diffusion
• interrogation du site contenu dans la référence + liens de poursuite Ö Nombreuses informations à ajouter aux objets

Middleware 55 Lionel Seinturier Middleware 56 Lionel Seinturier

 2.3 Durée de vie 2.4 Objets concurrents
Gérer la durée de vie des objets Deux types d’objets concurrents

• Objets temporaires : leur durée de vie correspond à celle de leur créateur

Objet passif Objet actif
• Objets persistants
- l’objet reste présent en mémoire tant qu’il n’est pas détruit L’activité Une (+sieurs) activité dédiée
- la persistance peut être limitée par la durée de vie du système • manipulée de façon explicite à l’objet exécutent les méthodes
ou s’étendre au delà des redémarrages • orthogonal à l’objet
• se «plaque» sur les méthodes
Plusieurs possibilités
appelant
- tous les objets sont persistants ou non appelant
- un objet est crée persistant ou non
Ex :
- un objet temporaire peut devenir persistant et vice-versa
thread Java
- un objet référencé par un objet persistant est persistant ou non

Middleware 57 Lionel Seinturier Middleware 58 Lionel Seinturier

2.5 Synchronisation 2.5 Synchronisation

Restreindre la concurrence d'exécution des méthodes Synchronisation comportementale

En présence d'invocations de méthodes concurrentes Fonction de l’état des données de l’objet

toutes les invocations ne sont pas forcément traitables simultanément
ex : Pile avec empiler et depiler
- soit pour des raisons strictement nécessaires (cohérence de l'application) vide : empiler
- soit pour assurer une qualité de service (ex. ne pas écrouler la machine) 1/2 : empiler et depiler
plein : depiler
Ö on en met en attente ou on en rejette certaines

3 types de synchronisations Synchronisation intra-objet

• pour 1 méthode d'un objet Fonction de l’état d’exécution de l’objet
- synchronisation intra-objet
- synchronisation comportementale ex : Fichier avec lire et écrire
soit plusieurs lire simultanément
• pour plusieurs méthodes situées sur des objets ≠ soit 1 seul ecrire
- synchronisation inter-objets

Middleware 59 Lionel Seinturier Middleware 60 Lionel Seinturier

 2.5 Synchronisation 2.5 Synchronisation
Outils pour les synchro. intra-objet & comportementale Synchronisation inter-objets

Assurer l'exécution cohérente d'une suite d'invocations de méthodes

sémaphores objets avec méthodes P et V
Exemple : un transfert entre deux objets comptes bancaires
moniteurs objet avec méthodes synchronized Assurer qu’un ensemble de 2 ou +sieurs invocations de méthodes
wait et notify (ex Java) compte1.depot(50);
compte2.retrait(50);
expressions opérateurs , * | // pour spécifier s’effectuent complètement ou pas du tout ( + propriétés ACID /* cf. BD */ )
de chemin les séquences valides de méthodes
gardes chaque méthode est associée
à une condition booléenne Problématique de la théorie de la sérialisatibilité et des moniteurs transactionnels
Ö intégration du moniteur dans le système réparti objet avec un
graphes chaque objet est associé à un ensemble d’états
- protocole de validation (2PC ou 3PC)
états/transitions chaque état est associé à un sous-ensemble de
- mécanisme de verrouillage des ressources
méthodes pouvant être exécutées
- mécanisme de détection et de traitement des conflits

Middleware 61 Lionel Seinturier Middleware 62 Lionel Seinturier

2.6 Migration 2.7 Réplication

Déplacer des objets Dupliquer des objets sur +sieurs sites

• d’un espace d’adressage à un autre Objectif principal : tolérance aux fautes

• d’une zone de stockage à une autre (mémoire, disque)
• d’un site à un autre
Active Passive
Objectifs (primary-backups)
- réduire les coûts de communication entre objets «bavards»
client
- répartir la charge vers les sites inutilisés client
- augmenter la disponibilité d’un service en le rapprochant de ses clients
réplique
réplique 1 primaire
Nombreux problèmes à résoudre état
réplique 2
- interrompre ? attendre la fin ? des traitements en cours avant de migrer réplique 2
- impact de la migration sur la référence ? réplique 3
réplique 3

Middleware 63 Lionel Seinturier Middleware 64 Lionel Seinturier

 2.8 Ramasse-miettes 3. Bibliographie
Détruire les objets qui ne sont référencés par aucun autre
• S. Krakowiak. Middleware Architecture with Patterns and Frameworks.
Objectif : récupérer les ressources (mémoire, CPU, disque) inutilisées
http://sardes.inrialpes.fr/~krakowia/MW-Book/
Difficulté / aux systèmes centralisés : suivre les références entre sites distants
• Collectif. Intergiciels et construction d'applications réparties.
Deux techniques http://sardes.inrialpes.fr/ecole/livre/pub/
• comptage de références : on associe un compteur à chaque objet • R. Orfali, D. Harkey, J. Edwards. The Essential Client/Server Survival Guide. Wiley 1996.
+1 lorsque la référence est acquise • B. Meyer. Object-Oriented Software Construction. Prentice Hall 1997.
-1 lorsque elle est libérée
inconvénient : utilisation mémoire + pas de gestion des cycles de réf. • A. Tanenbaum. Distributed Operating Systems. Prentice-Hall 1995.
avantage : simple • C. Atkinson. Object-Oriented Reuse, Concurrency and Distribution.
Addison Wesley 1992.
• traçage (mark and sweep) : parcours graphe objets à partir d’une racine
objets non marqués détruits • R. Balter, J.-P. Banâtre, S. Krakowiak.
inconvénient : temps CPU pour le traçage Constructions des systèmes d’exploitation répartis. 1991.
avantage : pas de modification des objets

Middleware 65 Lionel Seinturier Middleware 66 Lionel Seinturier