Technologie des

applications client-serveur
UE RSX 102

Support de cours Tome 1

G. Florin, E. Gressier, S. Natkin

-1-

BIBLIOGRAPHIE
Les RFC UNIX/INTERNET
Les serveurs WEB ...
Coulouris , Dollimore "Distributed systems concepts and
design" Addison Wesley 2000"
S. Natkin, "Les protocoles de scurit de l'Internet" Dunod
2002.
Ed. Krol, The whole Internet, OReilly, 1992
R Orfali, D Harkey, J. Edwards, "The essential Client
Server Survival Guide" Wiley 1995
En francais "Client-Serveur Guide de survie".
G Gardarin, O Gardarin, "Le client-serveur"
1996 Eyrolles

-2-

Introduction
Notions gnrales

-3-

Introduction
Situation actuelle

Mutation permanente des concepts, des

techniques et des organisations associes
aux applications informatiques.
Source principale un effort de recherche et
de production industrielle sans prcdent
au niveau mondial qui permet:
- l'apparition de composants de rapidit
et de complexit en croissance continue.
- la possibilit de dveloppement de
solutions logicielles et organisationnelles
irralistes quelques annes auparavant.

-4-

Systmes disponibles
On dispose prix accessible pour les
entreprises et le grand public de calculateurs
puissants munis :
- de systmes d'exploitation volus
- d'interfaces graphiques volues
- de capacits de stockage normes
- de moyens d'interconnexion "rseaux
locaux" trs performants
- dans un futur prvisible de moyens
d'interconnexion "longue distance" bas
prix et de bande passante importante.

-5-

Informatique "cooprative"
Applications coopratives
("Cooperative work")
Un ensemble d'entits logicielles
cooprant au moyen d'un rseau la
ralisation d'une tche informatique.
Algorithmique rpartie
("Distributed Computing")
Les applications systmes et rseaux
indispensables au fonctionnement des
machines en rseau.
IAD Intelligence artificielle distribue,
Multi-agent
("Distributed Artificial Intelligence")
Application cooprative mettant en
relation des agents qui fonctionnent selon
des approches drives de l'intelligence
artificielle.

-6-

Informatique "cooprative" (suite)

Le calcul massivement parallle
("Grid Computing")
Application de calcul scientifique ralis
par le travail en parallle et en coopration
d'un nombre lev de processeurs.
Les systmes rpartis de contrle
commande de procds industriels
Application de contrle en temps rel de
procds tenant compte des contraintes de
sret de fonctionnement.
Le client/serveur
Principal objet du cours

-7-

Le client serveur
Dfinir des modles de rpartition
des donnes
et des traitements
dans une architecture rseau.
Selon une approche dissymtrique:
- un client met des requtes,
- le serveur rend le service demand.
Applicable de nombreux problmes de
coopration,
en informatique de gestion
galement aux autres domaines
algorithmique rpartie,
informatique industrielle, ...
Dans son acception la plus complte:
possibilit de dfinir n'importe quelle
architecture de communication.
- Chaque entit communicante est la fois
client et serveur
- Chaque entit met et traite des requtes
-8-

Communications et approche clientserveur

Client serveur en mode message
. Le client envoie dans un premier
message une requte dexcution dun
traitement un serveur.
. Le serveur effectue le travail et fournit
dans un second message la rponse.
On peut utiliser la communication par
messages de donnes en mode asynchrone
offerte par les protocoles de transport.
Requte
X-data-req

X-data-ind
Rponse

X-data-ind

X-data-req

SERVEUR

CLIENT

Client serveur en appel de procdure

distante
Prsentation syntaxique et smantique
du mcanisme prcdent en terme d'appel
de procdure distante.
-9-

Architecture gnrale
Fonctionnement le plus frquent en clientserveur: mode requte rponse pour une
population de clients et de serveurs.
Poste client
Rponse
Requte

Poste client

Architecture Rponse
de communication

Requte

Rseau

Requte

"Middleware"

Rponse

Poste serveur

IPA Interface de programmation d'application

API ("Application Programming Interface")
Programme
client
Interprteur de
requtes

SGBD
Serveur de
requtes

IPA API

IPA API

Communications

Communications
- 10 -

Systmes d'informations d'entreprise

Applications types.
Transactionnel
OLTP "On Line Transaction Processing"
Les applications comportent:
- des oprations d'accs en lecture
criture des bases de donnes,
- des traitements
- des affichages en mode graphique sur
des postes de travail.
Aide la dcision
EIS/DS "Executive Information
System/Decision Support")
Les applications comportent:
des accs complexes bases de donnes,
des traitements de synthse/valorisation
des affichages (tableaux, histogrammes etc)

- 11 -

Le client-serveur en informatique de
gestion
Les six versions du client serveur selon
l'implantation des fonctions
(Classification du Gartner Group)
Les trois versions de base
Gestion des
donnes

Gestion des
donnes

Programme
d'application

Programme
d'application

Gestion des
donnes

S
e
r
v
e
u
r

Programme
d'application

C
l
i
e
n
t

Interface Homme
Machine
Cot serveur

Les services rseaux

Interface Homme
Machine
Cot client

Version IHM
distribue
avec
rhabillage
("revamping")

Interface Homme
Machine
Cot client

Version IHM
distribue
classique avec
multi-fentres
("Xwindows")

- 12 -

Interface Homme
Machine
Cot client

Version accs
aux donnes
distantes

Les trois versions avances

Gestion des
donnes

Gestion des
donnes

Programme
d'application
cot serveur

Gestion des
donnes
Programme
d'application

Les services rseaux

Programme
d'application
cot client
Interface Homme
Machine
Cot client

Version
traitements
distribus

Gestion des
donnes

Gestion des
donnes

Programme
d'application

Programme
d'application

Interface Homme
Machine
Cot client

Interface Homme
Machine
Cot client

Version
"Base de
donnes
rpartie"

Version
applications et
donnes
distribues

- 13 -

S
e
r
v
e
u
r
C
l
i
e
n
t

Les services rseaux orients donnes

("Middleware de donnes")
Assurer les changes de donnes entre un
client et un serveur en masquant les
diffrents problmes potentiels lis :
- la rpartition des donnes et traitements
(accs distant, baisse de performance)
- l'htrognit des matriels et des
logiciels en opration.
Exemple de travail le plus frquent en
client/serveur: envoyer des requtes d'accs
des donnes (type SQL) d'un client vers un
serveur et recevoir les rsultats.
- Ouvrir une connexion entre entits
- Envoi de requtes SQL vers le serveur
- Conversion des formats de requtes
- Excution des requtes
- Envoi des rsultats
- Conversion des rsultats
- (Gestion des erreurs)
- Fermeture de connexion.

- 14 -

Problmes rsoudre
Qui ralise les fonctions classiques des
systmes centraliss que l'on rencontre
maintenant en univers rparti.
Quelques exemples
- Accs et partage des ressources
- Intgrit et cohrence des donnes
- Scurit du systme
- Gestion des performances
- Administration de l'ensemble
Fonctions qui regroupent des
aspects multiples
- Contrle d'excution
- Contrle de l'accs aux donnes
- Contrle des communications
( considrer simultanment).
- 15 -

Traites par des outils diffrents

- Systme d'exploitation local.
- Architecture de communication.
- Base de donne (locale ou distribue)
- Moniteur transactionnel
- Protocoles additionnels spcifiques

Un domaine considrable en cours

d'tablissement avec une terminologie
considrable et trs opaque
(concepts, standards, produits)

- 16 -

Quelques exemples d'outils

- Les SGBD relationnels centraliss utiliss
en accs distant au moyen du rseau par des
stations (EDA-SQL + liaison APILINK).
- Les SGBD rpartis (SGBD distribus accs
distance) (ORACLE).
- Les architectures de rseaux
(Internet avec l'application WEB + java).
- Les micro noyaux de systmes (windows
NT) rpartis (Chorus).
- Les systmes d'objets distribus
(OMG-CORBA, OLE COM).

Besoin d'une classification

- 17 -

La classification des rseaux

Diffrentes propositions de structuration des
logiciels rseaux:
Solution hirarchique (en couche).
Solution "objet".
Normalisation / Systme propritaire
Exprimentation / Solution confirme
Les piles de protocole
Une solution encore ncessaire pour
comprendre les fonctions raliser:
- Choix du dcoupage des fonctions
raliser entre diffrentes couches de
logiciels.
- Choix de dfinition des fonctions
raliser par les diffrents niveaux.
- Implantation des niveaux.
Exemple d'architecture importante:
INTERNET
- 18 -

INTERNET
Applications pile
SUN/OS

Applications TCP/IP
directes
EXEMPLES

NFS: "Network
File System"

7. Application

6. Prsentation

SMTP "Simple
Mail Transfer
Protocol"

FTP: "File
Transfer
Protocol"

RPC:"Remote
Procedure Call"

5. Session

4. Transport

XDR:"External
Data
Representation"

TCP: Transmission Control Protocol (connect)

UDP: User Datagram Protocol (non connect)

3. Rseau

IP: Internet Protocol

Encapsulation IP (sur LAN ou liaisons SLIP,PPP)

2. Liaison

1. Physique

Pratiquement tout support de transmission

Rseaux
Publics

Lignes
spcialises
Point Point

- 19 -

Rseaux
Locaux

Rseau
tlphonique
RNIS, ATM

NIVEAU TRANSPORT (rappel)

. Le premier des niveaux utilisable par

l'utilisateur pour dvelopper des applications.
. Il ralise un service de transmission
fiable entre processus (transmission de bout
en bout, "end to end").
. Selon les options de conception il assure:
- Gestion des connexions.
. protocoles en mode connect
. protocoles en mode non connect.
- Ngociation de qualit de service.
- Multiplexage/clatement
- Contrle d'erreur.
- Contrle de flux.
- Contrle de squence.
- Segmentation.
Exemples de transports: Internet
TCP "Transmission Control Protocol".
UDP "User Datagram Protocol".
Novell
SPX "Sequenced Packet eXchange"
En fait XEROX XNS: SPProtocol
- 20 -

NIVEAU SESSION

Dans sa dfinition de base (OSI) le niveau

session structure et synchronise les dialogues
point point en mode message.
L'approche OSI.
. Le transport offre une voie logique de
communication ("un tube").
. Le mode de communication utilis est
le mode message asynchrone.
. La session structure les changes pour
y ajouter de la tolrance aux pannes et de
la synchronisation :
- Activits (travail important)
- Dialogue (partie d'un travail)
- Notion de point de synchronisation
pour dlimiter des parties d'un change en
vue de la reprise.
Difficult majeure de l'approche OSI
Manque de fonctions de synchronisation.
Normes CCITT X215 ISO 8026 Service
X225, 8027 Protocole de session
- 21 -

APD Appel de Procdure Distante

"RPC Remote Procedure Call"
. Le mode de communication du transport
tant le mode message asynchrone, la
session est dfinie pour offrir l'usager un
mode de dialogue de type synchrone.
=> Permettre un usager d'excuter une
procdure ou une fonction sur un autre site:
. Problme dlicat : Assurer en
environnement rparti une smantique pour
l'appel de procdure distante voisine de celle
connue en univers centralis.
- Exemples : Rpc traditionnels
SUN-OS : Internet Protocole RPC
OSF-DCE : "Distributed Computing
Environment"
- Exemples : Systmes d'objets rpartis
JAVA RMI :"Remote Method Invocation"
CORBA :"Common Object Request
Broker Architecture"
WS-SOAP :"Web Services - Simple Object
Access Protocol"
- 22 -

NIVEAU PRSENTATION

Traite du codage des donnes changes:

diffrents sites ayant des reprsentations
diffrentes peuvent utiliser les donnes.
Les conversions
. Ncessaire pour tous les types de donnes
Types caractres, numriques, construits.
Syntaxe abstraite : Permet la dfinition
d'une grande varit de structures de donnes
(analogue de la syntaxe de dfinition de
types dans un langage volu).
Syntaxe de transfert : Reprsentation
unique dans le rseau des valeurs changes
pour transfrer les donnes.

- 23 -

Exemples de standards de conversion

- Rseaux publics
Syntaxe abstraite ASN1: X208
Syntaxe de transfert :X209
- SUN-OS/ Internet
XDR : "eXternal Data Representation".
- Systmes d'objets rpartis CORBA
IDL : "Interface Definition Language".
CDR : Common Data representation.
- Web services
WSDL : "Web Services Definition
Language".
RPC/Encoded : "Syntaxe de transfert
XML"

- 24 -

Les protocoles de scurit

Objectif
Echanger des informations de faon
scuritaire en rsolvant des problmes de:
- confidentialit
- intgrit
- authentification
Problme central du dveloppement des
applications rseau par exemple de
commerce lectronique.
Exemples
Utilisation de techniques de cryptographie
DES, RSA, ...
Dfinition de protocoles de scurit
Au niveau session SSL (Secure Socket
Layer)
Aux autres niveaux (L2TP, IPSEC, SHTTP,
Kerberos .)
- 25 -

NIVEAU APPLICATION

Le niveau application est dfini pour fournir

l'utilisateur des fonctions dont il a besoin
couramment.
- En termes d'un cadre de dveloppement
d'une application informatique rpartie
(Exemple: structuration objet).
- En termes de protocoles
fonctions rseaux pr dfinies qui
dchargent l'utilisateur de travaux rptitifs
de programmation d'applications souvent
utilises.
On distingue aussi les applications qui
concernent des changes automatiss entre
calculateurs de celles qui concernent le
travail des personnels.
- Travail Collectif,"Groupware"
change de documents multimdia
Planification des activits ("Workflow")
Courrier lectronique, Tl confrence
Gestion des agendas
- 26 -

Protocoles d'application
Le transfert de fichiers
Objectif
Dplacer des fichiers d'un site un autre
(plats en gnral).
Trs nombreux protocoles proposs
Exemples
Internet FTP "File Transfer Protocol"
OSI/IEC FTAM "File Transfer Access and
Management"
L'accs aux fichiers distants
Objectif
Accs unifi en univers rparti diffrents
fichiers (ralisation des requtes d'accs).
Exemples
SUN-OS NFS "Network File System"
OSI/IEC FTAM "File Transfer Access and
Management"

- 27 -

La gestion transactionnelle rpartie

Objectif
La cohrence,
La persistance des donnes,
L'optimisation des performances.
Assurer le maintien cohrent d'un ensemble
de donnes rparties en prsence de
nombreuses transactions concurrentes et de
pannes.
Exemples
En univers Ouvert
Normes OSI/IEC TP et XOPEN/XA
"Transaction Processing"
Produits propritaire:
Moniteurs IBM CICS, TUXEDO

- 28 -

L'accs aux bases de donnes distantes

Objectif
Permettre un client d'accder une base de
donnes distante (le plus souvent au moyen
de requtes SQL)
Exemples
Normalisation de facto Microsoft
ODBC
"Open Data Base Connectivity"
Proposition du groupe SAG "SQL Access
Group" d'un ensemble de requtes CLI
"Call level Interface".
Autre proposition
Consortium Borland, IBM, Novell.
IDAPI : "Integrated Database Application
Programming Interface"
Produits propritaires
EDA-SQL de Information Builders Inc
Interface de communication API/SQL
connectant de trs nombreuses bases de
donnes sur des plates formes clientes.
- 29 -

La dsignation
Objectif
Grer des annuaires permettant un
utilisateur de retrouver des attributs d'un
nom symbolique (principalement l'adresse
rseau).
Exemples
Internet DNS "Domain Name System"
OSI/IEC DS "Directory Services"
Annuaire LDAP "Lightweight Directory
Access Protocol'
La messagerie
Objectif
Permettre d'changer du courrier
lectronique entre usagers
Exemples
Internet SMTP
"Simple Mail Transfer Protocol"
OSI MHS "Message Handling System"

- 30 -

L'change de donnes informatises

Objectif
Permettre d'changer des documents
administratifs standards sur des rseaux de
transmission de donnes (commandes,
factures, ....) entre agents conomiques.
Exemple
Normes EDI "Electronic Data Interchange"
L'change de documents lectroniques
Objectif
Dfinir et changer des documents gnraux
structurs de types particuliers (page, lettre,
journal, livre, catalogue).
Exemples
HTML "HyperText Markup Language"
XML "eXtended Markup Language"
Trs nombreuses propositions de formats.

- 31 -

L'accs aux informations distantes

WWW "World Wide Web"
Objectif
Permettre l'accs des donnes distantes
pour des personnes.
- Systmes de dsignation URL
("Uniform Resource Locator"),
- Protocole de communication HTTP
(Hyper Text Transfer Protocol"),
- Initialement format HTML + format
MIME Extension format XML
Extension : permettre les communications
entre programmes : notion de services web
(SOAP Simple Object Access Protocol,
WSDL Web Services Definition
language UDDI 'Universal Description
Discovery and Integration' ).

- 32 -

L'administration de rseaux
Objectif
Permettre l'accs des variables gres par
des agents d'administration:
- Lecture de l'tat d'un appareil, de
statistiques de fonctionnement.
- Positionnement de variables.
Internet SNMP : 'Simple Network
Management Protocol'.
WBEM: 'Web Based Enterprise
Management'

- 33 -

Conclusion
Les rseaux et systmes rpartis
Un problme extrmement complexe au
centre de l'informatique actuelle et venir.
Une volution permanente des concepts des
outils et des diffrentes propositions
commerciales.
Un march trs concurrentiel qui induit une
comptition souvent inutile dans l'offre, une
opacit importante dans les fonctions
offertes par les produits.

- 34 -

Premier Chapitre
L'INGNIERIE DES PROTOCOLES
DE COMMUNICATION

- 35 -

Plan du cours

Premire partie
I.1 Le mode message asynchrone.
I.2 L'interface socket

Seconde partie

II.1 Le mode appel de procdure distante.,

II.2 Exemple: CORBA

- 36 -

INTRODUCTION
- Le contrle rparti cest lensemble des
moyens offerts un programmeur pour
dvelopper des applications dans un
univers rparti (rseau, systme rparti,..)

Application utilisateur
Interface de Programmation
d'Applications (IPA - API)
Mcanisme d'excution
Mcanisme de communication
Mcanisme de mmorisation
Dmarche descendante du
dveloppement logiciel
- La conception de l'application.
- Les tapes de raffinement.
- La programmation : l'adaptation finale aux
outils disponibles (syntaxe et smantique de
l'IPA)
- 37 -

I Les moyens de dveloppement

disponibles
Introduction Aux IPA - Distribues
"DAPI Distributed Application Programming Interface"

Syntaxe et smantique des moyens de

programmation utilisables pour
l'expression d'un comportement rparti
Comportant donc ncessairement des
fonctionnalits de communication et de
synchronisation.
=> La description des interfaces de
programmation d'application distribues
devrait comprendre:
. Les comportements en mode normal de
fonctionnement.
. Les comportements en prsence de
pannes.
. Le comportement temporel.
- 38 -

Styles de description des interfaces

Approches services systmes/rseaux
Les plus rpandues:
Smantiques plus simples
Accessible de tous les langages
Mais contrles limits
Problmes de dsignation.
Exemples. Interface socket (TCP Internet).
Approches langages
Trs nombreuses propositions
Vrifications de cohrence
Dsignation plus facilement rsolue
(pour une application compltement dfinie)
Syntaxes/Smantiques complexes
- 39 -

LA COMMUNICATION DANS L'INTERFACE DE

PROGRAMMATION

- La communication par messages : l'outil

de base (Systme RC4000 [Brinch Hansen 1970])
Dveloppement
d'interfaces
de
programmation d'applications rparties
de complexit croissante:
En termes de richesse du schma de
communication/synchronisation offert.
Impliquant un nombre de messages
changs de plus en plus lev.
. Le mode message asynchrone.
. Le mode rendez-vous.
. Le mode appel de procdure distante.
. Le mode mmoire partage rpartie
=> Modes de communication encore le plus souvent
dfinis en point point.
=> Evolution en cours vers des interactions de groupes.
- 40 -

Critres de comparaison des outils

Facilit d'utilisation
Syntaxe des primitives de service
Comprhension de la smantique
Simplicit de la dsignation.
Facilit d'extension l'univers rparti
d'applications existantes
Efficacit (performances)
Richesse des mcanismes
de synchronisation (des proprits d'ordre)
Interoprabilit (normalisation relle)

- 41 -

Comparaison des interfaces

Chaque mode prsente des avantages et des
inconvnients.
Possde des dfenseurs et des dtracteurs
L'tude comparative des diffrents modes
est trs dlicate.
La situation est trs volutive.
=> Pas d'inutiles dbats.
=> Faire des essais.
=> Disposer de plusieurs modes.
Utilisation de modes diffrents.
Problmes rsoudre :
Pour une utilisation simultane de plusieurs
modes de communication.
=> Dveloppement de mthodologies de
spcification, conception, programmation
supportant plusieurs smantiques.

- 42 -

I.1
LE MODE MESSAGE ASYNCHRONE

- 43 -

INTRODUCTION
- Bas directement sur le mode de
communication par message (un message).
- Un service comprenant essentiellement
deux primitives pour communiquer et se
synchroniser.
TYPE COM_MESSAGE_ASYNCHRONE;
METHOD envoyer (id_metteur, id_rcepteur,
message, complments) ;
METHOD recevoir (id_metteur, id_rcepteur,
message);
METHOD ...;
END COM_MESSAGE_ASYNCHRONE.

identificateurs : ports de communication

messages : zones de donnes (types).
complments : selon les smantiques
multiples dfinissant les qualits de services

- 44 -

Nombreuses variantes smantiques du

mode message asynchrone

- Proprits d'ordre.
- Proprits de tolrance aux pannes.
- Proprits temporelles
- Autres qualits de service.
- Problme abord ici: la synchronisation
et l'utilisation des primitives.

- 45 -

Aspect principal pour la communication

et la synchronisation: l'asynchronisme
entre l'metteur et le rcepteur
Envoyer(M1)

M1

Actif

M2

Recevoir(M)
(M=M1)

Actif
Envoyer(M2)

Actif
Actif
Envoyer(M3)

M3
Recevoir(M)
M=M3

Actif

Actif

Recevoir(M)
(M=M2)
Rcepteur

Emetteur

- Le

mode message asynchrone ralise un

"producteur-consommateur" rparti
entre un metteur et un rcepteur.
- Complet paralllisme autoris entre
l'metteur et le rcepteur.
Rien n'empche aussi l'une des entits
(l'metteur) de suspendre son excution.
- 46 -

Dtails du comportement
L'metteur
. Ayant demand une mission, reprend la
main et continue son excution
"immdiatement" aprs la prise en compte
de sa demande.
. Le message est transmis (au rythme du
transport d'informations par le rseau de
communication) donc de faon asynchrone
avec le comportement metteur.
Le rcepteur
Ayant dcid de prendre en compte un
nouveau message il acquiert un message (le
premier) en instance.
-celui qui se prsente aprs le recevoir
-un message qui se trouve dans une file
d'attente de rception.
- 47 -

Utilisation du mode message asynchrone

Aspect d'activation distance

- Les messages sont le plus souvent typs:

Ils sont une demande de traitement
distant associ au typage
Utilisant les donnes du message pour
paramtrer l'excution distante.
- La nature du traitement dclench
dpend du contexte dans lequel le message
est pris en compte.
Smantique de l'activation
a) De type activation en parallle
("fork") puisque en mode normal l'metteur
et le rcepteur continuent.
b) Interprtable galement comme un
branchement inconditionnel ("goto")
distance
si
l'metteur
se
suspend
dfinitivement aprs l'mission.
- 48 -

Aspect d'change de donnes

- Le mode message permet une opration
d'affectation de variable distance:
envoyer (M=crire(v) , id_dest)
recevoir (M'=lire(v) , id-emet)
. Avec possibilit de gestion de cohrence
des types des variables v.
. Avec une smantique de consistance des
donnes entre l'metteur et le rcepteur
trs faible.
Repose sur les proprits d'ordre,
temporelles, de tolrance aux pannes
spcifies par la qualit de service.
Proprit minimale de cohrence des
communications point point: la
causalit
envoyer (M=crire) -> recevoir (M'=lire)

t1 : metteur.crire (v,t1)
=> t2>t1 : recepteur.lire (v, t2)
Proprits supplmentaires: rendez-vous, mmoire
rpartie.
- 49 -

Spcification des applications utilisant le

mode message asynchrone

- 50 -

Principes Gnraux
Solution Des Automates Synchroniss
Comportement squentiel des processus:
=> Ensemble de processus (entits rseaux)
squentiels communicants (trs souvent en
mode point point deux entits seulement).
=> Les mthodes de spcification de chaque
processus utilisent des automates d'tat fini
Interaction entre processus par change de
message
=>
Les
processus
communicants
synchronisent par messages asynchrones.

- 51 -

se

Reprsentation graphique des applications:

automates
tats
Il est dfini par un ensemble significatif de
variables locales de chaque processus.
Chaque tat doit tre interprtable aisment
en terme d'volution locale de l'application
rpartie.
Choix des tats:
tape prliminaire
spcification

importante

de

la

. Pas un niveau de dtail trop fin (trop grand

nombre d'tats) mais suffisamment pour
reprsenter l'volution au niveau de dtail
souhait.

- 52 -

Transitions.
Elles comportent deux mentions:
les conditions, et les actions.
Elles sont reprsentes par les arcs du graphe.
Condition
Les transitions sont franchissables lorsqu'une
condition boolenne ou garde est satisfaite:
. condition boolenne portant sur les
variables locales.
. condition boolenne portant sur les
changes (requte de service, message entrant).
. condition boolenne portant sur les signaux
internes (horloge).
Action
- C'est l'opration ralise lors du
franchissement de la transition: les traitements
raliser lors du passage l'tat suivant
(manipulation de variable, envoi de message).
- Le dtail des actions ne doit pas tre
important sinon le modle
est illisible
(renvoyer des textes).
- 53 -

Les commandes d'changes

- Reprsentation des oprations sur les
diagrammes (conditions et actions)
condition
action

recevoir(M)

?M

envoyer(M)

!M

- Dsignation
- La commande d'mission (d'une entit P1)
doit dsigner un destinataire (P2).
Ex :Dans le processus P1 :P2!M1
- La commande de rception (excute par un
processus P2) doit voquer une source P1.
Ex :Dans le processus P2 :P1?M1

- 54 -

Typage
Il doit y avoir correspondance de type entre la
variable de rception et la valeur mise
(possibilit de variable article).
Type[message_mis] =
Type [message_reu]
Exemple

Pret

? data_req(infos)
! I (infos)
! armer(dlai)
! cpt := 0 Trans
en
cours

? retombe(dlai)
! cpt := cpt + 1

- 55 -

? I (infos)

Smantique de l'alternative constitue par

l'existence de plusieurs transitions en un
tat
valuation des gardes
(conditions boolennes)
. Une garde est franchissable si elle est
constitue par une expression boolenne
portant sur des variables locales valeur vrai.
. Une garde est franchissable s'il s'agit d'une
commande d'change satisfaite : en fait une
rception dont le processus source fait
parvenir un message du type attendu qui se
trouve en tte de la file d'attente.
. Une garde combinaison des deux cas
prcdents.

- 56 -

Alternative en un tat

P3?M3

P1?M1
P2?M2

Indterminisme de l'valuation
- On choisit l'une quelconque des transitions
ayant sa condition boolenne satisfaite (sa
garde ouverte). Une garde franchissable
quelconque est slectionne
=> La liste des commandes associe la
garde est excute.
- Aucune garde n'est franchissable mais il existe
des gardes avec condition de rception pouvant
tre satisfaite par une mission
=> Attente que l'une d'elles soit
satisfaite.
- Aucune garde n'est franchissable:
. elles sont toutes boolennes
. aucun message ne sera envoy qui
corresponde une rception attendue
=> Erreur d'excution.
- 57 -

Diffrents automates
Automate du service
. tablissement de la liste des units de
service (primitives, SDU) de service
changeables entre le niveau n et le niveau n+1.
. Dfinition des enchanements autoriss
de primitives sous la forme d'un automate d'tat.
=> Toutes les successions lgales qu'un
observateur de l'interface n n+1 peut observer.

- 58 -

Exemple de comportements autoriss du

service de connexion de session OSI.

hors
connexion
?S_Connect_request
!S_Connect_
confirmation
(rejette)

!S_Connect_
indication
connexion
demi
ouverte
distante

?S_Connect_
response
(rejette)

connexion
demi
ouverte
locale

?S_Connect_
response
(accepte)

connexion
ouverte

- 59 -

!S_Connect_
confirmation
(accepte)

Automate du protocole
. tablissement de la liste des units de
protocole (messages, PDU) changs entre deux
niveaux n.
. Dfinition de tous les enchanements de
PDU qu'un observateur de la voie de
communication peut observer).
Ex: Une partie du protocole d'ouverture de
connexion de session

- 60 -

CN: Demande d'ouverture

de connexion de session
RF: Refus d'ouverture
de connexion de session
AC: Acceptation
d'ouverture

hors
connexion
?CN
!RF

!CN

connexion
demi
ouverte
distante

?RF

connexion
demi
ouverte
locale

?AC
!AC
connexion
ouverte

- 61 -

Automate complet
. Runion des deux automates de service et
de protocole

hors
connexion
?CN

!S_Connect_
indication
connexion
demi
ouverte
distante

?S_Connect_request

!RF

!S_Connect_
confirmation !CN

?S_Connect_
response -

?RF

?S_Connect_
response +

connexion
demi
ouverte
locale
?AC

!S_Connect_
confirmation +

!AC
connexion
ouverte

- 62 -

Validation des spcifications

Problmes de constructions
Rceptions non spcifies
Dans un tat un message peut se prsenter dont
le cas n'a pas t prvu
Interblocages
Dans un tat un message (ou une configuration)
est attendu qui ne peut jamais se prsenter.
Plus gnralement
Dfinition d'assertions de bon fonctionnement
sur le modle automates communicants.
- assertions portant sur des variables d'tat
(boolennes)
- assertions portant sur des trajectoires
(logique temporelle)

- 63 -

Mthodes de validation systmatiques

employes
Simulation comportementale
Excution en simulation du comportement
dcrit par les automates: une partie seulement
des comportements sont couverts.
Dtection d'erreurs et correction (technique
s'apparentant au test du modle).
Difficult majeure : On ne connat pas la
couverture du test (le taux d'erreurs rsiduelles
aprs le test).

- 64 -

Analyse exhaustive.
- L'application se prsente comme un ensemble
d'automates communicants
- Ralisation du produit des automates (produit
"synchronis"
tenant
compte
des
communications).
P1

P2

Ei
?cond1
P2!x
!action1

Ej

Ei+1

Ei * Ej

?cond2et P2?x
?cond1et cond2
!action2

!action1
!action2

Ej+1

Ei+1*Ej+1
Automates communicants

- Obtention du graphe d'accessibilit du systme

complet
- Vrification d'assertions sur le graphe
complet.
Difficult majeure
Explosion combinatoire de la taille des espaces
d'tat.

- 65 -

Exemples d'IPA distribues en mode

message asynchrone
Presque toutes les IPA des architectures
"ouvertes" de rseaux
- Internet, OSI, SNA
Presque toutes les IPA des systmes rpartis
classiques,
- Chorus , Mach, Amoeba
De nombreux langages de programmations
- Langages de spcifications de
protocoles (Estelle, ...)
- Langages "acteurs" de l'intelligence
artificielle distribue (Act1, ...)
Z; Font exception : les propositions rcentes
qui abandonnent le mode message:
Les interfaces orientes RPC (orientes
objets), orientes transactionnel (partage
de mmoire).

- 66 -

Conclusion : mode message asynchrone

- C'est le mode le plus basique
Comparable l'assembleur (affectation,
branchement).
- Le moins contraignant il permet aux
utilisateurs par des changes successifs, la
construction de tout type de protocole.
- L'utilisateur n'a pas en gnral envie d'tre
oblig de construire ses propres outils d'o:
L'enrichissement du mode message en termes
de qualit de service par les couches
successives des protocoles rseau.
Le besoin d'autres schmas prdfinis plus
complexes.
- Le mode message asynchrone est encore le
mode privilgi des interfaces
On
peut
prvoir

terme
son
"enfouissement" dans les couches internes.

- 67 -