Transcript Diapositiva 1

MIDDLEWARE
Le middleware est un logiciel de connexion qui se
compose d'un ensemble de services et/ou de milieux
de développement d'applications distribuées qui
permettent à plusieures entités (processus, objets
etc.) résidents sur un ou plusieurs ordinateurs,
d'interagir à travers un réseau d'interconnexion en
dépit des différences dans les protocoles de
communication, architectures des systèmes locaux,
systèmes opérationnels etc..
MIDDLEWARE
Applications Distribuées
Milieu de
développeme
nt applicatif
Services de configuration
et administration du
système
Services
d'abstraction
coopérative
Services de
communication
Infrastructure de communication (exemple TCP/IP)
Middleware (support pour
la coopération applicative)
Applications de base
WEB
Telnet
Email
FTP
RPC
CORBA
SNMP
Zone des
applications
Process-to-process
Interopérabilité de
transport de
l'information
Host-to-host
Infrastructure de transport
de l’information
802.1
Bridging e Switching
802.3
802.3u
802.3z
CSMA/CD
802.5
FDDI
TOKEN
RING
ISO
9314
802.11
X.25
Frame Relay
Wireless
Réseaux Locaux
Backbone
ATM
Middleware: Services
Service de Communication. Ce service offre un API qui
permet à l'application distribuée d'échanger les
informations entre ses composantes résidentes sur des
ordinateurs avec des caractéristiques d'hardware et/ou
logiciels différentes. Le but de ce service est de cacher
les disomogéneité dûs à la représentation des données
utilisés par les différents ordinateurs, aux systèmes
opérationnels locaux et aux différents réseaux qui
constituent l'infrastructure de la plate-forme. Pour les
communications on entend des différents paradigmes
d'interaction comme des RPC, la messagerie applicative,
le modèle publish/subscribe, etc.
Middleware: Services
Services d'abstraction et coopération. Ces services
représentent le coeur du middleware et ils comprennent
entre les autres:

Directory Service ou service de "pages blanches", qu'il
pourvoit à l'identification et à la localisation d'entités. Ce
service rend les applications au-dessus du middleware
indépendantes du sous-système d'acheminement des
messages.

Security Service, finalisé à la protection des éléments
critiques comme les données et les services applicatifs à
travers des techniques comme authentification, autorisation
et cryptographie.
 Time Service qui garantisse que tous les clock internes entre
client et serveur soient synchronisés dans un acceptable
niveau de variance
Middleware: Services
Services pour les applications. Ces services permettent à une
application d'avoir un accès direct, avec le réseau ou avec les
services offerts par le middleware. Par exemple un service orienté
aux transactions, à l'intérieur d'un middleware, il peut fournir un
support pour l’accès transactionnel aux bases de données
hétérogènes.
Services d'administration du système.
monitorage
 configuration
 aménagement.

Milieu de développement applicatif.
instruments d'aide à l'écriture
 debugging
 chargement d'applications distribuées aux objets et basées sur
processus.
 (Interface Definition Langage) pour l'interconnexion entre formulaires
écrits en différents langages de programmation et résidents en
ordinateurs distincts.

Middleware: Objectifs
interopérabilité et connectivité pour
applications distribuées sur plateformes hétérogènes
 trait-d'union des applications utilisées à
l'intérieur d'une entreprise.

Système
Informatif A
Système
Informatif C
Remote Procedure Call
Un Appel aux Procédures Distant, RPC
transforme l'interaction Client/Serveur dans
un appel à la procédure, semblable à celle
locale, en cachant au programmateur la plus
grande partie des mécanismes implémentés qui
la composent, comme:
•
•
•
l'échange de messages,
la localisation du serveur qui fournit le service
les différentes représentations possibles des
données des machines impliquées dans l'interaction.
RPC
Ce déguisement arrive en quatre phases:




À temps d'écriture du code. Les RPC employés/fournis devront
etre déclarée par le programmateur explicitement à travers l’
import/export des définitions des interfaces
À temps d'exécution. Chaque machine sur laquelle il est en
exécution un programme client et/ou serveur devra avoir un
support à temps d’exécution pour les RPC, RPC run-time support,
apte à exécuter quelques opérations des RPC comme par exemple
la localisation du serveur ou l'enregistrement d'un nouveau
service offert par un nouveau serveur.
À temps de compilation. Pendant la compilation pour chaque appel
à la procédure distante, des lignes de code sont accrochées au
programme originaire (stub). Cettes lignes permettent des
opérations standardes sur les données (empaquetage et codage
reconnue universellement) et les appels au RPC run-time support;
À temps de liaison. Pendant la liaison le programme source est mis
en communication avec le RPC run-time support pour obtenir le
code exécutable.
RPC Timeline
Client
Serveur
Blocked
Blocked
Computing
Blocked
Mécanismes pour RPC
Un protocole qui cache les pièges du
réseau (perte de paquets et
réorganisation des messages)
 Un mécanisme pour empaqueter les
arguments du côté de l’appelant et pour
les dépaqueter du côté de l’appelé

RPC Run-Time Support
Kernel du SO local
résultats
empaquète
i résultats
Serveur
SERVEUR STUB
RPC Run-Time Support
Kernel dul SO local
dépaquète
Les résultats
CLIENT STUB
dépaquete
résultats
empaquète
parametres
CLIENT
Résultats
Appel
RPC
RPC
Serveur
procédure
programme Serveur
Serveurstub
Interface
Specifications
RPC
generateur
Header file
RPC
run-time support
Client stub
principale
programme Client
programme Client
Localisation du serveur
Méthode Statique. Câbler à l'intérieur du client
l'adresse (addresse IP) du serveur.
Méthode Dynamique. Le stub du client, pendant
qu'il empaquette les données, il envoie en
même temps un broadcast et demande
l'adresse d'un serveur apte à exécuter le RPC
désiré. Le support run-time des RPC de chaque
machine répond si le service recherché est
fourni par un serveur en exécution.
Localisation du serveur
Name Server. le client à la recherche d'un
serveur consulte une entité, nom serveur, qui
gère une liste d'associations serveur-services.
serveu
r
stub
client
stub
4
3
2
nom
serveur
1
Passage des Paramètres
Call by Reference – déconseillé
Call by Copy/Restore. Copie une variable
a, de la part du
stub du client, dans le paquet-données (comme si c’était une
valeur). La nouvelle valeur de a, rendue par le serveur dans les
modèles de retour du RPC, elle sera copiée, du stub du client, dans
la cellule de mémoire qu'il contient la variable a.
CLIENT SIDE
begin
…..
a=0;
doppioincr(a,a);
writeln (a); ...
end
SERVER SIDE
procedure doppioincr (var x,y: integer)
begin
…….
x:= x+2;
y:= y+3;
end
Le résultat: Call by ref, a=“5”
Call by copy/restore a= “2” o “3”
dépendant de l'implémentation du stub du client
Sémantique des RPC
“At least once”
 Time-out
stub du client
 Retransmission
“At most once”
 Time-out
stub du client
 Code de faute de retour
“Exactly once”
Middleware: Taxinomie
Remote Data Access (RDA).
premier exemple de middleware
RDA s'interpose entre un client et un serveur d'une
base des données
RDA se compose d'un protocole basé sur l'envoi de
commandes, sous forme de langage StructuredQuery-langage (SQL) aux bases de données distantes.
Accès direct aux données.
RDA a été adopté comme standard international par
l’ISO.
Middleware: Taxinomie
Basés sur Remote Procedure Call (RPCs).
 Simplicité
application

de distribution de la logique d'une
Middleware plus utilisé
 les
RPC manquent de la flexibilité demandé par des
structures dynamiques distribuées (comme les
entreprises) pour la gestion de son patrimoine de
données et pour le copartage de ses ressources.
Middleware: Taxinomie
Message-Oriented Middleware (MOM)


Échange des données entre entités distinctes de façon
asynchrone
Messagerie applicative genre email. l'activité du receiver
n’est pas demandée


Implémentation à travers la gestion des queues de messages


Sender wait-free


MOM est considéré, en général, un bon choix pour connecter
des applications distribuées sur réseau géographique.
Middleware: Taxinomie
Transaction processing (TP) monitor

milieu intégré et instruments pour gérer en ligne un flux
d'applications formé par des flux de transactions.


balancement de charge, gestion des queues de messages
associées aux transactions, sauvetage de secours et
recouvrement de panne.


TP écrans ne naissent pas comme middleware mais comme
systèmes orientés aux bases de données.
Middleware: Taxinomie
Distributed object technology (DOT)
 Les
objets d'une application peuvent
distribués sur un réseau hétérogène,
être

 DOT
combine quelques caractéristiques des MOM
unis à la technologie aux objets.

 DOT
ne spécifie pas les mécanismes utilisés pour
envoyer questions et recevoir réponses dans
l'architecture Client/Serveur. Il utilise des
abstractions pour trouver ressources distantes.
Structured Query Language/Remote
Data Access (SQL/RDA)


RDA (Remote Database Access) est un protocole
standard de communication pour l'accès aux bases
de données distantes adoptées par l'ISO.
Le standard est formé par deux parties:
1.
2.
Generic RDAANSI/ISO/IEC 9579-1:1993[ISO9579-1]. Il
spécifie le modèle générique, le service (basé sur
transactions) et le protocole pour la connexion aux bases de
données distantes.
SQL Specialization ANSI/ISO/IEC 95792:1993[ISO9579-2]. Il spécifie les caractéristiques
additionnelles que le protocole doit avoir pour accéder aux
données de manière conforme au langage SQL
Structured Query Language/Remote
Data Access (SQL/RDA)

L'objectif de RDA est celui de recevoir l'interconnexion
entre bases de données hétérogènes en cachant les
différents formats des données et des langages
d'interrogation natifs.
Structured Query Language/Remote
Data Access (SQL/RDA)

Database gateway. La requête envoyée par le client passe pour la
base des données gateway qui la transmet à la convenable base de
données distante. Un exemple d'usage de RDA en milieu hétérogène
est décrit dans l’illustration 4.3.
Structured Query Language/Remote
Data Access (SQL/RDA)



RDA utilise des primitives de communication synchrones pour échanger des
informations entre les différents membres du système basés sur TCP.
Ils n'existe aucune politique pour la gestion des pannes, pour la subdivision
de la charge entre différents serveurs et pour la sécurité. Dans ce dernier
cas tout est déféré au système de contrôle des accès de la base de
données.
L' interface de service de RDA consiste:






de services pour le contrôle de la connexion entre client et serveur,
de services pour le déplacement des opérations SQL sur les bases de données,
de services pour le déplacement des modèles entre client et serveur,
de services pour le déplacement des résultats du serveur au client et
de services pour le contrôle des transactions.
Les touches SQL sont transmises entre client et serveur comme caractères
ASCII. Le contrôle des transactions inclut les opérations de commit à une
et à deux phases.
Distributed Computing Environment
(DCE)




DCE a été proposé
Foundation (OSF)
par
l'Open
Software
OSF est né avec le but de fournir un milieu UNIX
ouvert, basé sur RPC et libre de l'influence de
SUN et AT&T.
DCE c'est une ambiance logiciel intégrée pour le
développement et l'exécution d'applications
distribuées au-dessus des systèmes opérationnels
existants.
IBM, Hewlett-Packard et des autres, ils unissent
leurs systèmes opérationnels UNIX propriétaires
avec le code de DCE en fournissant à l'utilisateur
un paquet unique.
Distributed Computing Environment
(DCE)
Threads
 RPC
 Time Service

Distributed Applications
S
E
C
U
R
I
T
Y
Distributed services,
concurrency control, group
management ecc.
Distributed File Service
Basic System Services
(time, name, process services
ecc.)
RPC and Group Communication
Processes and threads
M
A
N
A
G
E
M
E
N
T
Kernel and Transport Services
Local Operating System and transport system calls
DCE (threads)


augmenter le parallélisme à l'intérieur
d'un processus unique.
Les thread représentent dans une
machine UNIX un second niveau de
parallélisme après celui lié au
processus.



Les thread partagent le même code,
les portes de communication et les
fichiers ouverts (Process Contre
Block)
Un thread est caractérisé par un
program-counter un stack-pointer et
par un ensemble de registres (Thread
Control Block).
PCB
T
h
r
e
a
d
Single-thread
process
PCB
TCB
TCB
TCB
Thread
Thread
Thread
Multi-thread
process
DCE (threads)





problème de synchronisation entre les thread dans un même
processus (dirigé par le programmateur)
Les thread de DCE suivent le standard POSIX et le kernel
de DCE il met à disposition de l'utilisateur 54 primitives à
travers
des
librairies
(création,
destruction
et
synchronisation).
Le kernel de DCE gère en outre feux et variables de
condition. Les feux permettent la synchronisation entre
thread. Les feux et les variables de condition permettent la
synchronisation entre thread et ressources extérieures.
DCE (Time Service)


Synchronisation entre les clock du système.
Un clock a une erreur relative d'une partie sur un million, après une heure il peut
avoir commis une faute 3,6msec. Après un jour 86 msec etc. il est clair que si
nous voulons maintenir toutes les horloges des ordinateurs dans un écart de 6
msec, nous avons besoin de synchroniser les clock toutes les 2 heures.
Synchronisation avec le temps réel (UTC et GPS).
 UTC est fourni par une station radio par pays. Ces stations lancent des signaux de
synchronisation aux ondes courtes. Un récepteur peut à ce point resynchroniser
son propre horologe selon le signal capté. Cette procédure permet une précision
de 2msec théoriquement. En pratique on obtient que l'horloge locale peut se
déplacer respect à l'UTC d'environ 10msec.
 Global Position System, qui fournit des services de position et d'horaire (en phase
avec UTC), on a atteint une précision de microsecondes.
DCE (Time Service)







Il existe un intervalle d'incertitude dans lequel sont contenus des
événements sur lesquels il n'est pas possible d'établir une priorité
temporale certaine.
Le time service fourni par DCE associe à chaque événement (par exemple la
fermeture d'un fichier) un intervalle de temps dans lequel celui-ci puisse se
passer.
Si deux entractes de temps associés aux deux événements se superposent,
il n'est pas possible de définir lequel des deux événements il est arrivé
d'abord.
DCE met à disposition une librairie de fonctions, 33, pour obtenir l'entracte
de temps courant, pour manipuler entractes pour, comparer entractes etc,
DCE (Time Service)









Du point de vue implémentatif:
Chaque client doit recevoir un time clerk (démons)
Existence de Time Serveurs en contact indépendant avec l'UTC
En voulant atteindre un soin de 6msec, l'algorithme de resynchronisation
d'un client est le suivant:
Chaques deux heures un time clerk envoie une requête de resynchronisation aux time serveurs, chacun des time serveurs envoie son
entracte de temps courant.
Le time clerck élimine immédiatement les entractes qui ne se superposent
pas aux autres. Il calcule l'intersection entre les entractes restantes et il
assume qu'UTC soit au centre de cette intersection.
Comment changer l'horaire à l'intérieur de l'ordinateur.
Si l'échange d'horaire impose un retour en arrière, le clock local se bloque
jusqu'à ce qu'on ne récupère pas le gap.
Si l'échange d'horaire impose un saut en avant on commande directement la
nouvelle valeur du clock.
DCE (Directory Service)






Le Directory Service est de type hiérarchique.
Les ressources (fichiers, services, ordinateurs, imprimants
etc.) sont structurés en cellules et chaque cellule a son
propre Cell Directory Service (CDS) apte à localiser les
ressources sur la base d’un nom logique et vice versa.
Chaque ressource a un nom logique et une seule adresse
physique à l'intérieur de la cellule.
Pour localiser une ressource hors d’une cellule, le DCE
soutient deux mécanismes:
Le Global Directory Service (GDS) pour la localisation des
cellules en DCE
Domain Name System (DNS) pour la localisation d'une
ressource sur internet.
Message-Oriented Middleware


Classe spécifique de middleware qui soutient
l'échange de messages dans un milieu
d'applications distribuées qui sont messagedriven c'est-à-dire l'évolution de l'application
est scandée par la transmission et la
réception de messages.
Messagerie asynchrone (le serveur ne doit
pas être nécessairement en marche):
 Queues
de messages
 Publish/Subscribe
Queues de messages


Les messages envoyés par les clients à un
serveur restent emmagasiné dans une queue
jusqu'à ce que le serveur les prélève de la
queue même.
Cela facilite
 Implémentation
des politiques de priorité
 Balancement de la charge (+ serveurs prélèvent
messages de la même queue)
 Gestion d'applications tolérantes aux pannes
 Amélioration
des performances (client non
blocante)
Publish/Subscribe





bus architecture message
Sur le bus s'appuient deux entités: les publisher (ceux qui
envoient/publient les messages et les subscriber (ceux qui
reçoivent les messages).
Le publisher publie un message avec un certain sujet, ex. "/ football
/Italie/équipes/Milan", et ce message atteint tous les subscriber
qui sont abonnés à tel sujet.
Un publisher n'est pas obligé de connaître tous ses subscriber et
vice versa.
l'ensemble des publisher et des subscriber d'un certain sujet peut
changer dynamiquement
Publish/Subscribe






Un processus peut être publisher de différents sujets et
subscriber d'autres.
Le logiciel qui implémente ce paradigme de communication
doit tâcher de ne pas inonder le réseau avec des copies
du même message.
Les sujets forment un espace unique et hiérarchique des
noms (comme dans un file system)
Le bus message consent des différents niveaux de
gestion, de la remise avec certificat à la remise nonfiable.
Si un subscriber est actif à l'arrivée d'un message, un
upcall est activé.
Si il n’est pas actif, le message est emmagasiné à
l'intérieur d'un router qui va le livrer dès que le
subscriber sera actif
Mqseries (IBM)





MQseries se base sur un système de queues de
messages.
Mqseries est un middleware basé sur une série
d'objets. Queue managers, Queues, Namelists,
Distribution list.
L'élément clé en Mqseries est la queue manager
qui gère l'envoi, la réception et la queue des
messages de la part des applications à travers le
Message Queue Interface (MQI).
Les queues sont créées/enlevée par les
applications aux appels opportuns à la queue
manager.
Il y a deux types de queues, les locales (gérées par
la queue manager à laquelle l'application est
connexe) et les distantes
Mqseries (IBM)

À l'intérieur d'une queue manager les queues
peuvent être de deux types, temporaires et
persistantes.


Les noms des queues définies par les utilisateurs
sont gardés dans un dépôt nommé namelist qui
gère l'association nom logique - nom physique.


Donc, quand un utilisateur veut accéder à une
queue en connaissant son adresse logique,
l'adresse physique est découverte à travers la
namelist.


Une application peut envoyer le même message en
plusieures queues à travers le mécanisme de
distribution list. (émulation du multicast)
Tib/Rendezvous

Tib/Rendezvous
se
base sur un service
de
communication
publish/subscribe
très sophistiqué.
•Tib/Rendezvous met à disposition:
– un primitif request/reply (de type synchrone)
–un primitif broadcast request/reply où un message est
reçu par plusieurs serveurs, chacun desquels envoie
un reply (application repliquation active ou passive).
Tib/Rendezvous



Tib/rendezvous fournit deux niveaux de fiabilité
sur les remises des messages: remise fiable et
remise certifiée
La remise fiable notifie un rapport au publisher en
cas de perte d'un message (sans indiquer le
message)
Dans le cas de remise certifiée, le rapport révèle
le message perdu et les subscriber qui ne l'ont pas
reçu.


Les messages envoyés avec remise certifiée sont
emmagasinés dans la mémoire de masse du
publisher de façon à être successivement prélevé
en cas de pannes.
Tib/Rendezvous

L'architecture logiciel de TIB/rendezvous est formée
d’une série de composants:




Une librairie TIB/rendezvous qui permet à l'application
d'utiliser l'API de TIB/Rendezvous.
Un processus caché (démon) TIB/Rendezvous qui reçoit les
appels de la librairie et qui gère toutes les communications
entre les processus applicatifs (sois distants que résidents sur
la même machine) la fragmentation et le rassemblement des
paquets et le filtrage basé sur le subject des messages.
Un procédé achemineur caché des messages (TIB/Rendezvous
Deamon) qui permet de ne pas envoyer des messages en sous-
réseaux où il n‘y est aucun subscriber présent pour ce sujet
(autrement les différents sous-réseaux seraient bouchés de
messages!)
Les changements des tables des suscriber sont notifiés aux
différents TIB/Rendezvous Deamon à travers des périodiques
protocoles d'échange de messages.
Tib/Rendezvous

L'architecture logiciel de TIB/rendezvous est formé
d’une série de composants:

 Cache de Messages (Message Cache) stocke les messages qui
passent sur le réseau concernant un certain sujet. Quand un
processus exécute le subscribe pour un certain sujet, si le
message cache est actif pour ce sujet, il recevra tous les
messages présents dans le cache. Cela permet à un processus
de recevoir des messages même quand il n'est pas en exécution
et de gérer des politiques de tolérance aux pannes.

TIB/Rendezvous fault-tolerant serveur. En TIBCO il
est possible de définir un groupe de processus qui se
coordonnent pour offrir un certain service avec un
déterminé degré de tolérance aux pannes. Ce logiciel
est apte à gérer réplique passive et réplique active. Le
contrôle de la panne utilise la technique d'heartbeats.
SmartSocket (Talarian)
SmartSockets est un produit de middleware
réalisé par Talarian qui offre des communications
du
type
point-à-point,
publish/subscribe,
synchrones (RPC) et asynchrones pour la
coopération du type program-to-program.
Les messages sont débranchés à travers un réseau
de serveurs RT qui sont, en fait, des routers
gérants l'acheminement des messages selon le
chemin le plus bref.

Communications rapides grâce à:
 Priorité aux messages,
 Codification binaire des messages,
 Réseau de RT serveur.
SmartSocket (Talarian)


Communications fiables:
Au niveau de message. SmartSocket offre la possibilité
d'emmagasiner dans un fichier, pour un réemploi suivant, un
message en quatre moments distincts. Quand le message
laisse un programme, quand un message est remis à un
programme, quand un message arrive au RT serveur et quand
un message laisse un RT serveur.
Au niveau de programme. SmartSocket inclut des
instruments pour la gestion de la réplique passive de
processus. Donc il est possible d'insérer des redondances
sur les RT serveurs qui sont les éléments critiques de
l'architecture SmartSocket. Le relèvement des processus
détraqués se fait à l’aide de messages spéciaux nommés
heartbeats.
Au niveau de connexion. SmartSocket permet d'utiliser des
messages keep-alive sur les connexions de façon à en
vérifier la véritable capacité opérationnelle.
Corba (Common Object Request Broker
Architecture) Architecture de base



Middleware orienté aux objets
Un objet CORBA est une entité abstraite qui fournit
des services
CORBA introduit différents niveaux de transparence
 Transparence de langage
IDL
 Transparence de communication
ORB
IOR
 Transparence de location
OBJECT
Implementation
Client
1
4
2
IDL
Client
Stub
Object
Adapter
ORB
IDL
Static
skeleton
3
ORB – Object Request Broker


L'ORB est "logiquement"
un bus de communication
"Physiquement" chaque
processus CORBA a son
propre ORB


Chaque invocation CORBA
passe pour l'ORB
C'est l'ORB qui gère la
communication
Stub
Skeleton
reply
GIOP
ORB
request
ORB
GIOP
TCP
TCP
IP
IP
Accès
accès
au
au
réseau
réseau
Stub
Skeleton
ORB
ORB
GIOP
GIOP
IIOP
IIOP
TCP
TCP
IP
IP
Accés
au
rèseau
Accès
au
réseau
reply
request
IOR – Interoperable Object
Reference




À chaque objet serveur il est
associé un IOR.
L'IOR contient informations
d'adressage de l'objet.
Pour invoquer des opérations
sur un objet (serveur) le
client doit obtenir son IOR.
Au moment de l'invocation,
l'ORB lit les informations
dans l'IOR et il instaure la
connexion avec l'objet
Object Reference
Repository ID



Endpoint Info
Object Key
...
Repository ID: le type IDL de
l'objet représenté
Endpoint Info: le couple
host:porte
Object Key: identificateur de
l'objet