Post on 30-Jun-2015
description
transcript
Université Mohamed KHIDER, Biskra
Faculté des Science Exactes et des Sciences de la Nature et
de la Vie
Département d’Informatique
Support de Cours
Module : Sémantique des Systèmes Mobiles (SSM)
(Actualisé sous le titre : Vérification des Systèmes Mobiles (VSM))
Option : Génie Logiciel et Systèmes Distribués (GLSD)
Niveau : Master 2
Réalisé par :
Dr : Laid Kahloul
Année: 2014
Table des matières Dr : L. Kahloul
Tables des matières
Introduction Générale…………………………………………………………….……..2
Chapitre I : Mobilité en Informatique
1. Introduction ........................................................................................................................ 4 2. Définitions .......................................................................................................................... 4 3. Pourquoi la mobilité ? ........................................................................................................ 5
3.1. Motivations de la mobilité physique ............................................................................... 5
3.2. Motivation de la mobilité du code ................................................................................... 6
3.3. Motivation des agents mobiles ........................................................................................ 6 4. Origines de l’idée ............................................................................................................... 8
5. Architectures et mécanismes .............................................................................................. 8 5.1. Architecture ..................................................................................................................... 8 5.1. Mécanismes pour la mobilité ........................................................................................ 10
6. Langages de programmation ............................................................................................ 12
7. Paradigmes conceptuels ................................................................................................... 16 8. Applications ..................................................................................................................... 17
9. Problèmes inhérents à la mobilité .................................................................................... 18 9.1. Mobilité physique .......................................................................................................... 19 9.2. Agent mobiles ............................................................................................................... 19
10. Réalisations industrielles .................................................................................................. 20
11. Efforts de standardisation ................................................................................................. 23 12. Conclusion ........................................................................................................................ 23
Chapitre II : Formalismes pour les systèmes mobiles
1. Introduction ...................................................................................................................... 26 2. Algèbre de Processus ....................................................................................................... 26
2.1. C’est quoi un algèbre de processus ............................................................................... 26 2.2. Le CCS .......................................................................................................................... 26
2.3. Communication et action dans le CSS .......................................................................... 27
2.4. La syntaxe de CCS ........................................................................................................ 28
2.5. La sémantique du CSS .................................................................................................. 28 2.6. Exercices ....................................................................................................................... 29
3. Le pi-calcul : une première extension du CCS ................................................................. 33 3.1. Syntaxe du valued-CCS ................................................................................................ 33 3.2. Motivations du pi-calcul ................................................................................................ 33
3.3. Syntaxe du Pi-calcul ...................................................................................................... 34 3.5. La dérivation dans le pi-calcul ...................................................................................... 34 3.6. SOS du pi-calcul ............................................................................................................ 35 3.7. Exercices ....................................................................................................................... 36
4. Le Join-calcul : une autre extension du CCS ................................................................... 37
4.1. Le JC distribué .............................................................................................................. 37
4.2. La syntaxe du JC distribute (DJC) ................................................................................ 37
4.3. L’exécution des processus DJC ..................................................................................... 38 4.4. Exemples de spécification en DJC ................................................................................ 42
5. Logique de réécriture vers la mobilité : Mobile Maude ................................................... 43
Table des matières Dr : L. Kahloul
5.1. La logique de réécriture : LR ........................................................................................ 43 Algèbre Universel ............................................................................................................ 43 Règles d’une LR ............................................................................................................... 43
5.2. Maude ............................................................................................................................ 44
C’est quoi Maude? ........................................................................................................... 44 Functional modules .......................................................................................................... 45 System modules ............................................................................................................... 45 Object oriented module .................................................................................................... 46 Parameterized modules: ................................................................................................... 47
5.3. Mobile Maude ............................................................................................................... 47 C’est quoi ? ....................................................................................................................... 48 Principes ........................................................................................................................... 48
Communication entre objets: ........................................................................................... 49 Primitives de mobilité ...................................................................................................... 49 Exemple de règles ............................................................................................................ 49
6. Conclusion ........................................................................................................................ 50
Conclusion Générale…………………….………………………..………….…………52
Références ................................................................................................................................ 54
Figures
Figure 1.1 Architecture pour la mobilité. .................................................................................. 9 Figure 2.1. Représentation graphique des processus CCS ...................................................... 27
Figure 2.2. LTS pour un processus CCS ................................................................................. 29
Tableaux
Tableau 1.1. Mécanismes de gestion des liens, inspiré de [Alf+98] ....................................... 11
Tableau 1.3. Paradigmes conceptuels pour la mobilité [Alf+98] ............................................ 17
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 1
Introduction Générale
Introduction Générale Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 2
Introduction Générale
Les systèmes mobiles sont des systèmes où les entités, qui les composent, peuvent
changer de localité durant leurs existences. Ces systèmes sont apparus depuis longtemps, et
ont connu un grand développement avec l’évolution en informatique, électronique, et
mécanique. Les systèmes de robots mobiles, les réseaux mobiles cellulaires, et enfin les
logiciels ou agents mobiles sont les exemples les plus remarquable dans le domaine de la
mobilité.
L’étude des systèmes mobiles peut traiter différent niveau : leur analyse, leur
conception, leurs implémentations, et aussi leur test et validation. En tant qu’informaticien, on
s’intéresse plutôt aux aspects logiciels de ces systèmes, ainsi on s’intéresse plutôt au
développement des agents logiciels mobiles qui peuvent exister et s’exécuter sur des
composants eux même fixes ou mobiles.
L’objectif du module SSM (Sémantique des Systèmes Mobiles, Actualisé sous le titre :
Vérification des Systèmes Mobiles) est de traiter, en particulier, les aspects de test,
vérification et validation des systèmes mobiles. On s’intéresse, dans ce module, à présenter à
l’étudiant un ensemble d’outils formels permettant de spécifier, modéliser ensuite tester et
vérifier des systèmes mobiles. Ce module est proposé aux étudiants de 2ème
année GLSD
(Génie Logiciel et Systèmes Distribué), qui doivent déjà eu une formation initiale dans les
outils formels.
Je viens de mettre ce support de cours après plus de trois que j’enseigne ce module. Le
module était proposé en 2010 lors de l’ouverture de l’option Vérification et Diagnostic des
Systèmes Critiques (actuellement intitulé GLSD). J’ai enseigné ce module durant les années
universitaire : 2010-2011, 2011-2012, 2013-2013. Ce module est toujours proposé en 2ème
année GLSD.
Ce support de cours est organisé en deux grands chapitres:
1) Un premier chapitre qui présente de manière informelle les systèmes mobiles et
l’informatique mobile dans ses deux aspects : logiciel et matériel ;
2) Un deuxième chapitre qui présente les formalismes les plus exploités pour la
spécification et la vérification des systèmes mobiles.
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 3
Chapitre 1 :
Mobilité en Informatique
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 4
1. Introduction
Avec la naissance des premiers systèmes distribués, le développement des réseaux
informatiques sans fil, et la diffusion de dispositifs portables, on a vécu l’émergence de
l’informatique mobile. Dans ce contexte, la mobilité concerne le déplacement de dispositifs
matériels ou la migration d’applications logicielles.
L’objectif de ce rapport est de présenter un état de l’art sur la mobilité. On tente de
retracer le chemin dans lequel les idées ont évolué. Cependant, si on commence par un aspect
large de la mobilité, le rapport évolue pour concentrer de plus en plus sur un axe particulier :
les agents mobiles. Ces derniers sont des entités logicielles autonomes, accomplissant des
tâches aux profils de leurs propriétaires.
Dans la section (2), on commence à exposer un panorama de définitions des concepts
clés du domaine : calcul mobile, code mobile (ou mobilité du code) et agent mobile. Les
motivations de la mobilité avec ses deux versions matérielle et logicielle seront présentées
dans la troisième section. La quatrième section met l’accent sur la mobilité logicielle et
explore les premières origines de cette idée. En considérant le concept de système à code
mobile ou système à composants mobiles (Mobile Code System [Alf+98]) comme un concept
unificateur de différentes formes de la mobilité logicielle, la section (5) présente une vision
architecturale (adoptée dans plusieurs travaux courants [Bar 05], [Jin 04]) d’un tel système,
ainsi que les divergences et mécanismes dérivés au-dessous de cette vision.
La section (6) liste une variété de technologies existantes (langages de programmation
et plate-fomes). Ces technologies peuvent être utilisées pour l’implémentation des solutions à
base de codes mobiles. Cependant de telles solutions doivent être tout d’abord conçus, ainsi la
section 7 présente des paradigmes conceptuels dérivés de la vision architecturale présentée
dans la section 5. Ces paradigmes conceptuels peuvent être implémentés par différentes
solutions technologiques, même si certaines solutions seront plus convenables pour des
paradigmes particuliers.
La section (8) expose les champs d’applications potentiels des idées évoquées, ensuite
dans la section (9) on mentionne certains problèmes inhérents à la mobilité. Malgré ces
problèmes évoqués, des idées théoriques ont connu le passage vers des réalisations
industrielles et commerciales, achevées ou en cours de réalisation. C’est dans la section (10)
qu’on présente une variété de ces réalisations. Avant de conclure ce rapport, la section 11
mentionne des efforts de standardisations internationales. L’objectif de ces efforts est de
rapprocher les implémentations hétérogènes existantes et d’éviter les futures divergences.
2. Définitions
Dans le domaine de la mobilité, trois concepts sont répandus : mobile computing,
mobile code (ou code mobility) et mobile agent. On présente ci-dessous une variété de
définitions de ces trois notions.
Mobile computing :
―Paradigm in which users carrying portable devices have access to a shared
infrastructure independent of their physical location‖.[Geo+96]
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 5
Code Mobility:
“Code mobility can be defined as the capability to dynamically change the bindings
between code fragments and the location where they are executed” [Car+97].
“Mobile code are soft-ware that travels on a heterogeneous network, crossing
administrative domains, and is automatically executed upon arrival at the destination
…”[Tho 97]
Mobile agent :
“Mobile agents are programs that can move through a network under their own
control, migrating from host to host and interacting with other agents and resources on each”
[Gray+96]
“A mobile agent is not bound to the system where it begins execution. It has the unique
ability to transport itself from one system in a network to another. The ability to travel, allows
a mobile agent to move to a system that contains an object with which the agent wants to
interact, and then to take advantage of being in the same host or network as the object”. [Lan
98]
“Computations that are able to relocate themselves from one host to another “ [Nil+03]
“A piece of code and its associated data moving about executing autonomously on
behalf of its owner” [Joh 04]
“Mobile agents are software abstractions that can migrate across the network
representing users in various tasks… A mobile agent has the unique ability to transport itself
from one system in a network to another in the same network” [Bar 05].
On peut considérer que le premier concept mobile computing concerne la mobilité des
dispositifs matériels (on l’appelle dans la suite du rapport mobilité physique). Les deux autres
expriment la mobilité des applications (c’est la mobilité logicielle). La nouveauté dans le cas
des agents est que la mobilité est du à une volonté interne (autonomie de décision). Les agents
se déplacent à leur volonté, sans intervention externe. Les deux types de mobilité sont sont
nettement indépendante de la mobilité physique.
3. Pourquoi la mobilité ?
Les deux variantes de la mobilité ont des motivations importantes :
3.1. Motivations de la mobilité physique
Elle concerne le déplacement de dispositifs de calcul (ordinateurs portables, PDA :
personnal digital assistant, téléphone mobiles, …). Elle est motivée par :
La diffusion des réseaux informatique sans fils.
La diffusion des réseaux de télécommunication cellulaires. Les dispositifs
utilisés dans ces réseaux (principalement des téléphones portables) acquirent de
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 6
jours en jours des capacités de calcul et de traitement de l’information
importante.
Les utilisateurs mobiles.
Pour la mobilité logicielle, on distingue deux sortes de mobilités. La mobilité logicielle
d’ordre général (mobilité de code ou code mobility) et les agents mobiles.
3.2. Motivation de la mobilité du code
Déplacer ou faire migrer un code (un processus, un objet ou une procédure) peut avoir
différentes raisons. Selon [Jul+88], une telle migration peut assurer
Un équilibrage de charge entre processeurs.
Une performance dans la communication. En rassemblant les objets qui se
communiquent intensivement sur les même nœuds.
Une Disponibilité des objets requis chez les nœuds demandants ces objets.
Une obtention (par téléchargement) de services logiciels disponibles sur un certain
nœud.
En plus de ces raisons, les auteurs dans [Car+97] et [Alf+98] proposent d’autres raisons :
Besoins de scalabilité dans les réseaux larges : WAN.
Besoins de spécialisation de services pour un grand public (des réseaux WANs) :
Le nombre de clients croît rapidement ainsi que leurs besoins se différencient. Les
serveurs prédéfinis avec un minimum de services peuvent être spécialisés via leur
enrichissement par des composants (en les téléchargeant) assurant des services
spécifiques.
La nature dynamique des infrastructures de télécommunication : Ces
infrastructures se caractérisent, en plus, par un débit faible et une faible fiabilité
(déconnexions fréquentes).
Déploiement et maintenance de composants de systèmes distribués sur les réseaux
à grande échelle : Des composants, ayant un savoir-faire sur la maintenabilité et la
reconfiguration, se déplacent sur le réseau et visitent les différents nœuds pour faire le
nécessaire.
Réalisation d’applications autonomes : de telles applications se déplacent sur le
net, pour assurer des interactions locales complexes. Ces interactions sont irréalisables
avec des infrastructures à faible débit et à pannes fréquentes (déconnexions).
Gestion flexible de Données : les données véhiculent accompagnées par les codes
(know-how) nécessaires pour leurs traitements. Les nœuds d’un réseau reçoivent les
données ainsi que les protocoles de leurs traitements (encapsulation de protocoles).
Améliorer la tolérance aux fautes dans les applications distribuées : déplacer les
applications existantes sur un site, si ce dernier est susceptible d’une panne.
3.3. Motivation des agents mobiles
En considérant qu’un agent est un code autonome. Certaines caractéristiques de ces
agents favorisent leur exploitation en place d’autres paradigmes.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 7
[Gray+96] présente des caractéristiques des agents mobiles favorisant leur exploitation
dans les réseaux mobiles :
Ils peuvent migrer d’un dispositif de calcul mobile vers un réseau, pour collecter
des informations et utiliser des ressources. Il est plus efficace de se positionner dans le
réseau ( des ressources et informations) que d’envoyer des requêtes et attendre des
réponses. Durant son travail sur le réseau, l’agent est déconnecté de son nœud source.
Il peut retourner avec ses résultats, ultérieurement, lors de la connexion de son nœud.
Eviter de gérer les défauts du réseau (sauf lors de la migration).
Ils n’exigent pas la pré-installation d’applications particulières sur les hôtes.
Passe du modèle rigide client serveur vers le modèle peer to peer. Ce dernier plus
convenable où les besoins des programmes changent (passer d’un client vers un
serveur et vice versa).
Scalabilité des applications : Déplacer le travail vers le nœud le plus approprié.
L’expérience montre que c’est un paradigme plus facile à comprendre que les
autres.
Les auteurs dans [Lan+99], proposent de leur part sept bonnes raisons motivant
l’utilisation d’agents mobiles :
Ils réduisent la charge du réseau : déplacer le code vers le service, une fois pour
tout, les interactions ultérieures seront locales. Déplacer le code vers les données, si
ces dernières sont volumineuses à déplacer.
Ils surmontent la latence d’un réseau : dans les applications temps réel, la latence
devient significative et non acceptable avec les larges réseaux. Les agents mobiles
peuvent migrer vers les composants (robots) pour les contrôler localement.
Ils encapsulent les protocoles : les agents mobiles peuvent déplacer les protocoles
appropriés aux sites concernés, pour recevoir ou transmettre des formats de données
spécifiques. Ils permettent une mise à jours efficace des protocoles.
Ils s’exécutent de façon autonome et asynchrone : pour les dispositifs mobiles
avec des fréquentes déconnexions, les agents mobiles peuvent migrer en de hors de ces
dispositifs lors de la connexion, durant une déconnexion, ces agents s’exécutent sur le
réseau de manière asynchrone et autonome. En terminant leurs missions, ils reviennent
aux dispositifs initiaux lors des prochaines connexions.
Ils s’adaptent dynamiquement : ils sentent les propriétés de leur environnement
(les segments du réseau non fiables, les segment où le débit est faible, …) pour se
reconfigurer (se dispatcher) afin d’avoir une configuration optimale (équilibrer la
charge, …)
Ils sont hétérogènes de nature : ils sont indépendants des hôtes et de moyens de
transport. Ils dépendent seulement de leur environnement logiciel d’exécution (des
plate-formes spécifiques comme les machines abstraites ou virtuelles, cas du JVM).
Ils offrent un bon modèle pour les systèmes hétérogènes (matériel ou logiciel)
Ils sont robustes et tolérants aux pannes : si un hôte risque de tomber en panne, les
agents mobiles sur cet hôte peuvent migrer.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 8
4. Origines de l’idée
L’idée de déplacer le code d’une machine vers une autre machine n’est pas récente. Elle
date des années soixante dix-sept. Dans la littérature, on peut rencontrer plusieurs idées
innovatrices : ―Remote batch job submission‖ [Bog 73], La commande rsh d’Unix, Le langage
d’impression PostScript [Ado 85]. Pour imprimer sur une imprimante PostScript exige un
programme PostScript, décrivant toutes les propriétés de la page à imprimer, sera envoyé à
l’imprimante, où il sera exécuté. D’autre exemple sont le langage distributed smalltalk [Dou
87], Le réseau Apiary [Hew 80] des systèmes à base de connaissances, et la migration
transparente de processus et d’objets actifs [Nut 94] dans les systèmes distribués (exp. le
noyau Accent [Ras+81], le système Eden [Laz+81], DEMOS/MP [Pow+83], Emerlad [Jul +
88], Chorus [Roz + 88], Locus [But+84, Thi 91], V-ystem [The+85], et Cool [Lea + 93])
Selon [Alf+98], les différences que doivent considérer les développeurs par rapport à
ces idées d’origines sont les suivantes :
On s’intéresse au système à grande échelle de type Internet (WAN), et non plus aux
LANs des systèmes distribués classiques.
La mobilité est sous le contrôle du programmeur (Programming is location aware).
Elle est non transparente.
L’objectif de la mobilité n’est plus uniquement l’équilibrage de charge.
Les systèmes avec ces qualités sont qualifiés de Mobile Code Systems (MCSs).
5. Architectures et mécanismes
L’exécution d’un MCS exige la présence d’une architecture matérielle/logicielle de base
(une plate-forme). En considérant les différences entre les MCS et les systèmes de mobilité
classiques, [Alf+98] propose une architecture possible pour un environnement de d’exécution
d’un MCS.
5.1. Architecture
Les auteurs, dans [Alf+98], présentent deux alternatives d’architectures logiques
possibles pour assurer la mobilité du code (figure 1).
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 9
Figure 1.1 Architecture pour la mobilité.
Dans ces deux alternatives, l’architecture proposée est composée de cinq couches :
La couche 1 : « hardware », composée des hôtes (nœuds) et de l’infrastructure
du réseau de communication.
Couche 2 : « core operating system », le noyau du système d’exploitation de
pour chacune des hôtes. Cette couche doit assurer les fonctions de bases :
gestion de fichiers, de mémoire et de processus.
Couche 3 : « network oprtaing system », cette couche assure les fonctions de
gestion du réseau. Dans cette couche, les communications sont non
transparentes. Le service des sockets et l’un des exemples de service que doit
fournir cette couche.
Couche 4 : elle doit fournir le service de mobilité. Elle peut être soit un « true
distribuetd system », qui assure les fonctions d’un système distribué avec une
communication et une mobilité transparente ou bien un « computaional
environment » où les communications et la mobilité sont non transparentes.
Couche 5 : « component », cette couche englobe soit des ressources (logique
ou physique) et des calculs ( programmes, processus ou applications) nommés
« executing units : EUs ».
Chaque EU est composé de
Code segment : le code source. Partie statique de l’unité.
State : composé d’un data space (références aux ressources accessibles par l’EU.
Ces ressources peuvent être locales ou distantes) et d’un execution state
(composé des données privées, de la pile des appels, d’un pointeur d’instruction,
…)
Un MCS (non classique) doit être exécuté sur une architecture de type 2 (avec un
computational environment : la mobilité n’est pas transparente au niveau de la
programmation)
host host host
Core
operating
system
Core operating
system
Core operating
system
Network
operating
system
network operating
system
Network operating
system
True distibuted system
host host host
Core operating
system
Core
operating
system
Core
operating
system
Network operating
system
network
operating
system
Network
operating
system
Computational
environment Computational
environment
Computational
environment
component component component component component component
Alternative 1 Alternative 2
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 10
5.1. Mécanismes pour la mobilité
En considérant la vision précédente, la mobilité du code signifie le déplacement d’une
unité EU (toute entière ou certaines parties d’elle). [Alf+98] propose une classification
exhaustive des mécanismes possibles pour la mobilité. Cette classification est basée sur deux
critères :
(1) Les éléments de l’EU qui se déplacent.
(2) La méthode de gestion de liens entre EU est ses ressources après migration de l’EU
Critère 1 : les éléments de l’EU qui peuvent se déplacer : On trouve
1. Strong mobility : le déplacement du code segment ainsi que l’execution state.
Dans cette classe, on a deux mécanismes :
1.1. La migration : l’EU est tout d’abord suspendue, ensuite transférée vers le
CE cible enfin relancée. Cette migration peut être de deux genres :
Proactive : la destination et le moment de migration sont définis par
l’EU migrateur elle-même (c’est autonome).
réactive : la destination et le momentde migration sont définis par une
EU externe (par exemple un EU manager).
1.2. Remote clonning (clonnage à distance): créer une copie de l’EU dans le CE,
où cette EU veut se déplacer. Idem, ce mécanisme peut être proactif ou
réactif.
2. Weak mobility : seulement le code segment peut se déplacer, éventuellement avec
quelques données d’initialisation nécessaires pour le re-lancement. Dans cette
classe, on peut classifier les mécanismes selon quatre critères : (i)direction du
transfère, (ii) nature du code transféré, (iii) synchronisation entre le nœud CE
source et le CE destination et (iv) le temps du re-lancement du code après son
transfère. On trouve :
2.1. Shipping : Le CE source envoie le code vers un CE destination. Dans cette
classe, on peut trouver (idem pour 2.2):
2.1.1. stand-alone code (exécution à la volée) : Le code transféré crée sa
propre EU pour son exécution sur le CE destination. Dans ce cas : le CE
source est le CE destination peuvent être (idem pour 2.1.2) :
2.1.1.1. synchrones : le CE source est suspendu en attendant la
terminaison de l’exécution du code transféré dans le CE destination.
2.1.1.2. asynchrones : le CE source n’est pas suspendu. Dans ce cas,
le code transféré peut commencer son exécution sur le CE
destination :
2.1.1.2.1. immédiatement.
2.1.1.2.1. différemment : en attendant un événement ou une
condition, pour se lancer.
2.1.2. code fragment : l’exécution du code transféré se réalise dans le
contexte d’un EU existant sur le CE destination.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 11
2.2. Fetching : un CE (destination) télécharge un code chez lui.
Critère 2 : la manière de gestion des liens entre EU et ressources utilisées, après le
déplacement d’un EU : Avant son déplacement, l’EU utilise des ressources. Ces
ressources peuvent être locales (sur son CE) ou distantes (sur des EC distants). Ces
ressources peuvent être privées ou partagées avec d’autres EUs. Ces ressources peuvent
être transférables ou non transférables.
L’EU doit avoir des liens (références) vers de telles ressources. Ces références peuvent
être de trois niveaux :
Référence par identité : c’est le lien le plus fort. L’EU doit avoir toujours accès
à cette ressource pour qu’elle s’exécute.
Référence par valeur : l’EU porte intérêt au contenu de la ressource et non à la
ressource elle-même. S’il est possible d’avoir une copie du contenu de cette ressource,
l’EU sera satisfait.
Référence par type : ce qui est important est le type de la ressource. Une
ressource de même type peut satisfaire l’EU.
Soit CEd un CE destination, U une EU, R une ressource et B le lien entre U et R. Selon
ces différents niveaux de lien, et selon le type de ressource (transférable ou non), on dispose
de différents mécanismes de gestion des liens :
1. by move : transférer R avec U vers CEd, sans changer B.
2. by copy : créer sur CEd une copie R’, mettre à jour B.
3. network reference : R n’est pas transféré et B sera mise à jour pour assurer le lien
entre U et R.
4. rebinding : une ressource R’ de même type que R existe sur CEd. Après que U
passe à CEd, B est mis à jour pour assurer le lient entre U et R’.
Le tableau (Tableau 1) expose comment ces différents mécanismes seront exploités, en
fonction du type de la ressource et du type du lien entre l’EU et la ressource.
Type de ressource
Type de lien
transférable Non transférable
Par identité By move et
Network reference
Network reference
Par valeur By copy (ou by move ou
network reference)
Network reference
Par type Rebinding (ou l’un des
autres mécanismes)
Rebinding
(ou network reference)
Tableau 1.1. Mécanismes de gestion des liens, inspiré de [Alf+98]
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 12
6. Langages de programmation
Actuellement, il y a plusieurs langages de programmation et une variété de plate-formes
pour le développement des systèmes MCS. Certains de ces systèmes considèrent ces codes
comme étant des agents mobiles. L’objectif de cette section est de présenter une vingtaine de
ces plate-formes à titre démonstratif.
1. Emerlad [Jul+88] : un langage et un système orienté objet (supportant le concept de
type abstrait de données). Il supporte la migration des objets. Les objets migrateurs peuvent
être de simples objets (données) comme ils peuvent être des processus. Emerlad s’exécute sur
un LAN de 100 nœuds (au maximum) homogènes et trusts (crus). Il est possible de déplacer
même des arguments pour un appel distant. La mobilité est explicite avec des primitives mises
à la disposition du programmeur (exp : move object to node).
Granularité fine : Des objets (avec leurs opérations) sont distribués sur les nœuds du
réseau. Des objets actifs ( accompagné par des threads) peuvent faire des appels à des
opérations d’autres objets sur des nœuds distants. L’exécution du processus crée une pile (au-
dessous de cette pile, le processus, au-dessus de ce processus, on peut avoir les
enregistrements de ce processus où des opérations d’autres objets sont invoqués).
Un appel distant se fait comme suit :
Ou bien le processus appelant migre complètement vers le nœud de l’objet invoqué.
Ou bien seulement la partie appelante du processus migre vers le nœud de l’objet
invoqué. Sur ce dernier, une nouvelle pile sera créée, et donc un nouveau processus. (Une fine
granularité).
2. REV [Sta+90] : les systèmes d’évaluation à distance permettent d’évaluer une
procédure sur un serveur distant. Un client peut reloger une procédure P(x, y, z) sur un
serveur S avec une commande de type at S eval P(x, y, z). La procédure P et ses
arguments sont transmis vers le serveur S, où P sera exécuté. Sur S, P peut accéder à des
ressources (strong static typing).
3. Telescript [Whi 94a, Whi 94b]: de General Magic. Un langage orienté objet qui
fourni une forte mobilité. Ce n’est pas un langage de programmation général, mais il est dédié
à une des applications particulières (la communication). Le concept central dans telescript est
l’agent. Un agent se déplace de manière autonome dans un télésphère, pour effectuer des
affaires au profil de son client. Un télésphere est un ensemble de moteurs d’exécution (un
interpréteur telescript et une place). Les places sont des stations où les agents peuvent être
reçus. L’utilisateur peut créer de telles places.
Un agent telescript est un processus caractérisé par :
1. telename composé de deux composants : une autorité et une identité.
2. owner, le possesseur des nouveaux objets créés.
3. sponsor, le processus dont l’autorité sera attachée aux nouveaux objets créés.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 13
4. client, l’objet dont le code demande l’opération actuelle.
5. permit, spécifie les capabilities de ce processus.
6. Age : durée de vie maximale en seconde du processus.
7. Extent : taille maximale de la zone mémoire où le processus sera exécuté.
8. Priority : utilisé pour décider quand exécuter le processus.
9. canGo, canCreate, canGrant et canDeney : des booléens décidant si ce processus
peut migrer, créer, augmenter ou réduire permits d’un autre processus.
Telescript offre une primitive go qu’un agent exécute pour migrer vers un hôte. La
sécurité est assurée par les concepts de capabilities (permission) et d’authenfications. Les
capabilities définissent les droits qu’un agent en dispose, les autentification permettent à des
sites d’accepter seulement certains agents (ceux autentifiés). L’agent est exécuté sur une
machine virtuelle qui détecte toute instruction illégale ou violation. Le mécanisme
d’exception permet aux agents de couvrir certaines erreurs possibles.
Telecsript est le premier système commercialisé. Il a été utilisé [Gray+96] pour gestion
de réseau, active e-mail, e-commerce… Il supporte la mobilité des hôtes (mobilité matérielle).
Il était utilisé sur les PDA (personnal digital assistant) comme le cas de Sony Magic Link.
Possibilité de changer le code durant l’exécution : tel le cas de Telescript.
4. Obliq [Car94, Car95] : du centre de recherche sur les systèmes (DEC). C’est un
langage interprété, objet et non typé. Il supporte l’RMI et l’évaluation à distance de code
(REV). Il est basé sur les messages et donc offre uniquement une mobilité faible.
Obliq fait partie des langages dits prototype based languages. Dans un tel langage, il
n’y a pas de classes. Les objets sont créés par un mécanisme de clonage d’objets existants
(dits prototypes). En principe, Obliq permet la migration de closures. A base de ça, il serait
possible de programmer la migration d’objet.
On distingue entre deux types de ressources, celles simples transmises avec leur code et
celles disposant d’un état (ex. les tableaux) pour lesquelles seulement une référence est
transmise.
5. M0 [Tsc 94] : Implémenté à l’université de Geneva. Il implémente le concept de
messengers[Tsc 95]. Un agent est donc un messager (messenger). Un messager peut migrer
ou transmettre le code d’un autre messager. Les ressources nécessaires pou un agent sont
copiées et transmises avec son code. M0 offre une mobilité faible (type shipping) avec une
exécution à la volée asynchrone et immédiate (stand-alone excution).
6. Odyssey [Nob+95] : Un système (de General Magic). Ce système représente une
réimplémentation de Telescript en java. Il offre seulement une faible mobilité. Dans ce
système, des applications s’exécutant sur des hôtes mobiles peuvent demander certaines
informations (bandwidth, battery power, …) et à base de ces informations prennent des
décisions (exp. migrer vers d’autres hôtes).
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 14
7. TACOMA [Joh+95]: basé sur UNIX et TCP. Implémenté en C, il supporte les
agents écrits en C, Tcl/TK, Perl, Python et Sheme. Il offre une faible mobilité. L’objectif de
ce langage est le déploiement de composants dans les environnements distribués [Nil+03].
Des serveurs sont installés dans un réseau, avec un minimum de services. Ces services ne
répondent pas à l’ensemble des besoins des clients. Les clients intéressés peuvent programmer
leurs services spécifiques et déployer ses services sur les serveurs disponibles. Dans ce sens,
les serveurs sont extensibles dynamiquement.
8. Safe Tcl [Bor 94, Web 1]: Proposé par First Virtual Holdings comme une extension
de MIME (the internet multimedia mail standard). MIME définit un standard pour le mail
enrichi avec un contenu hyper-texte. Il traite seulement des scripts Tcl (un langage
procédural).
Safe tcl est donc un langage standard pour le contenu exécutable inséré dans les e-mails.
Safe Tcl assure l’exécution sécurisée de codes inconnus, sur des architectures qui peuvent être
hétérogènes. Pour des raisons de sécurité, Safe Tcl utilise deux interpréteurs : Les codes
légitimes sont exécutés sur un premier interpréteur. Les codes non crus sont exécutés sur un
autre interpréteur. Les deux interpréteurs partagent le même espace d’adressage. Cependant,
le deuxième limite les accès du code non cru (non trusted).
Safe tcl a été utilisé dans SurfIt web browser [Bal 96].
9. Extended Facile [Kna+95 ] : Basé sur le langage Facile [Gia+89, Tho+93]. Facile
est langage fonctionnel d’ordre supérieur, supportant la concurrence et la distribution.
Facile implémente les fonctions sous forme de closures. Une closure est une structure
particulière (un enregistrement) encapsulant une fonction (une chaîne de caractères
représentant le code de cette fonction). Cette closure permet à cette fonction de s’exécuter
dans un autre environnement qui peut être une autre partie du programme ou une autre
machine.
L’agent dans Facile est représenté sous forme d’une fonction. Facile permet la
migration de fonctions entre des hôtes. Son extension a considéré les problèmes :
d’hétérogénéité entre architectures des hôtes, d’accès aux ressources distantes, la compilation
séparée, ainsi que la performance. Les ressources utilisées par un agent sont transmises avec
cet agent.
La migration est réalisée avec la primitive send. send prend comme argument une
closure. L’agent copie toutes ses ressources (no callbaks) et à son arrivée l’agent est exécuté
automatiquement (stand-alone execution).
10. Agent Tcl [Gra 95, Gra 96, Gra+96] : migration transparente (l’état de l’agent est
collecté par le système : transparent au programmeur). Un agent peut migrer entre deux
machines mobiles, entre une machine mobile et une autre machine fixe, indépendamment du
temps de connexion de la machine mobile. Les agents (des scripts) peuvent être programmés
dans plusieurs langages (Agent Tcl : le Tcl « Tool Commande Language de 1987 » étendu
agent, le java en cours ).
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 15
Un système Agent Tcl est composé d’un ensemble de serveurs sur les hôtes d’un réseau.
Une seule instruction agent_jump capture l’état de l’agent, le crypte, le signe et l’envoie au
serveur sur l’hôte destination. Le serveur authentifie l’agent et lance un interpréteur Tcl pour
l’exécuter (une interprétation lente !). L’interpréteur Tcl restaure l’état de l’agent et relance
l’agent depuis l’instruction qui succède agent_jump. Agent Tcl n’est pas orienté objet,
ainsi ce qui migre effectivement sont des procédures.
La commande agent_meet adressé d’un agent et accepté par un autre, permet aux
deux de communiquer avec des primitives de bas niveau. Une communication de haut niveau
est possible par le mécanisme de ARPC (agent remote procedure call [Nog +96]).
Ce langage offre une sécurité dans les mondes incertain (cas de Internet). Il était utilisé
initialement pour la recherche d’information, ensuite pour le work-flow. Ce système utilise
Safe-Tcl.
11. Limbo [Luc 96] : c’est le langage de programmation des applications exécutables
sur le système Inferno. Inferno est un système d’exploitation dédié aux dispositifs portables
de faibles puissances (téléphones portables, PDA, …). Inferno peut être installé sur des
systèmes comme UNIX, Windows NT et Plan 9.
Limbo est inspiré du C, mais elle permet des déclarations de type Pascal : TAD,
modules, canaux. Limbo founrit une gestion automatique de la mémoire. Les canaux
permettent la communication inter-processus.
12. Java [Arn+96, Gos+96] : de Sun, un langage basé classe, orienté objet. Un langage
général, dont les objectifs étaient la portabilité et la sécurité. JavaSoft a crée le modèle de
l’applet (code mobile) téléchargé et exécuté automatiquement lors d’une visite d’une page
web.
13. Mole [Str+96] : développé à l’université de stuttgart. Mole est un API java
supportant la mobilité faible. Les agents Mole sont des objets threads java. Ces agents
s’exécutent sur des JVMs. Les agents mobiles sont exécutés à la volée (stand-alone shipping)
de manière asynchrone et immédiate. Les ressources de l’agent seront enlevées (removed) et
transmises avec son code.
14. Sumatra [Ach+97] : développé à l’université de Maryland. C’est une extension de
java. Il implémente une mobilité forte. L’interpréteur était mis à jour pour qu’il puisse
sauvegarder la pile d’exécution et le compteur de programme, pour les envoyer au nœud
destination.
15. Objective Caml [Ler 97] : de l’INRIA. Un langage fonctionnel pareil à ML,
enrichi avec le paradigme orienté objet. Ce langage était utilisé pour le développement du
navigateur web MMM [Rou 96a, Rou 96b] de l’INRIA. MMM permet de faire l’édition de
liens et l’exécution des applets de manière dynamique.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 16
16. Grasshopper : de IKV++, une plate-forme pour la mobilité faible. Elle est
conforme à la norme MASIF (présenté dans la section : efforts de standardisation),
développée en Java. Elle utilise les protocoles SSL et X.501 pour la sécurité.
17. Aglet [Lan+97b]: Proposé par IBM Tokyo research lab, un aglet (AGent-appLET)
est une amélioration des applets java. Aglet offre une mobilité faible. Les agents sont des
threads java. Il utilise la notion de référence distante (AgletProxy), le passage de messages
(multicast, broadcast) et le protocole ATP (Agent Transfert Protocol) [Lan +97a]. Il offre en
outre une certaine notion de sécurité en limitant les ressources allouées aux aglets (protocoles
SSL et X.501).
Deux primitives sont proposées : dispatch, qui transmet un agent (stand-alone
shipping) vers une destination passée en paramètre, et retract télécharge un aglet (fetching
stand-alone).
Un point fort d’Aglet est qu’il est conforme aux normes MASIF et FIPA.
18. Concordia [Web2] : de Mitsubishi, une plate-forme pour la mobilité forte, écrite
entièrement en java. Un système Concordia est composé d’un JVM, un serveur et un
ensemble d’agents. Pour la sécurité, il utilise SSL.
Concordia est un freeware pour le développement d’applications non commerciales.
19. Voyager [Web3] : de ObjectSpace, une plate-forme écrite en java. Elle permet aux
objets et aux agents de migrer. Voyager intègre entre autres les références distantes, le support
CORBA, et un ramasse miettes distribué. VOYAGER combine le bus de communication à
objets (ORB/CORBA et RMI) avec la technologie agent.
20. Ara [Pei 97] : de l’université de Kaiserslautern, basé sur Tcl. Une plate-forme
multi-langages (C, C++, Tcl) avec une forte mobilité. Elle doit supporter l’exécution sécurisée
des agents mobiles dans les réseaux hétérogènes.
21. java-to-go [Li+]: développé à l’université de Californie (Berkly). Basé sur java
(faible mobilité). Permet le prototypage rapide de systèmes d’agents mobiles java.
7. Paradigmes conceptuels
Dans un développement classique, la phase de conception s’intéresse à identifier
l’architecture (les composants et leurs interactions) du système. La conception exploite des
paradigmes conceptuels. De tels paradigmes sont indépendants de la technologie
d’implémentation (langage de programmation).
Selon [Alf+98], la conception d’un système à composants mobiles diffère par rapport à
la conception de système classique (composants statiques). Les positions (ou les sites) des
composants doivent êtres explicités durant la phase de conception du système. Dans ce sens,
trois paradigmes conceptuels sont proposés pour la conception des systèmes à composants
mobiles : remote evaluation (RE, évaluation à distance), code on demande (CoD, code sur
demande) et mobile agent (MA, agent mobile).
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 17
Pour montrer la différence entre ces trois paradigmes, [Alf+98] introduit trois concepts :
component, site et interaction. Component est l’ensemble du know-how (savoir-faire),
ressources et du computational component (l’interpréteur responsable de l’exécution du
know-how). Un site est un local où un component se trouve et peut s’exécuter. Une interaction
peut avoir lieu entre deux composants (components) sur le même site ou sur deux sites
distants.
Soit A, B deux composants se trouvant initialement sur deux sites SA et SB. Le
composant A a besoins d’un service. A peut disposer du know-how et des ressources
nécessaires à ce service, comme ces know-how et ces ressources peuvent (tous ou certains)
être détenus par B. les trois paradigmes se différèrent selon les positions de A (ici A signifie
intuitivement le computationnal compoennet), du know how et des ressources nécessaires
pour le service, et ceci avant et après l’achèvement du service. Le tableau 3 récapitule ces
différences :
avant après
paradigmes SA SB SA SB
Client-serveur A Know-how,
ressources, B
A Know-how,
ressources, B
Remote evaluation A+know-how Rssources, B A Know-how,
ressources, B
Code on demande A+Ressource Know-how, B A+know-
how+ressources
B
Mobile agent A+know-how ressources A+know-
how+ressources
Tableau 1.3. Paradigmes conceptuels pour la mobilité [Alf+98]
Le paradigme client-serveur n’est pas un paradigme pour la mobilité. Sa présence sur le
tableau est seulement à titre comparatif, par rapport aux trois autres paradigmes.
En plus de ces paradigmes, un autre paradigme a été proposé : Push pardigm [Fra+98],
[Jin02]. Son principe est opposé à ceux de RE et de CoD. L’idée est qu’un client envoie dès
le début un profil au serveur. Le serveur à base de ce profil décide quels sont les traitements et
quand seront-ils transmis au client. Au bon moment, le serveur transmet les traitements et les
actives sur le client. L’avantage de cette méthode est que le client sera déchargé de ce
téléchargement.
8. Applications
Différentes applications ont été envisagées pour les systèmes à composants mobiles
(MCS). Ces applications utilisent différents paradigmes de manière anarchique et ambiguë.
S’il est claire de décider qu’un applets java n’est pas une application du paradigme agent
mobile (pas d’autonomie, une seule direction de la mobilité), pour certaines application les
choses ne sont pas assez claires.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 18
Plusieurs auteurs signalent différentes applications possibles :
Les auteurs dans [Alf+98] citent :
1. Recherche d’informations distribuées [Gray+96], [Ghe+97].
2. Document actif : e-mail actifs, page web (hyper texte)
3. Services avancés de télécommunication : vidéo-conférences [Tho+95], utilisateurs
mobiles (avec les déconnexions potentielles),
4. Contrôle et configuration à distance de dispositifs : processus industriels, gestion de
réseaux,
5. Gestion et coopération dans le work-flow : le work-flow définit les activités, leurs
sites, leurs relations, le temps de leur réalisation, pour réaliser un produit industriel.
Les agents mobiles se chargent de véhiculer les informations entre les co-workers
dans un work-flow.
6. Réseaux actifs : réseaux flexibles et dynamiques selon les besoins des applications.
Deux approches :
Programmables switchs : étendre dynamiquement le réseau basé sur CoD
paradigm.
Capsule approche : attacher des codes aux paquets transférés. Le nœud qui
reçoit le paquet exécute le code associé, pour traiter les données paquet.
7. E-commerce : un agent cherche dans un marché des catalogues pour retourner vers
le portable d’un client avec les meilleures offres disponibles.
8. Déploiement d’applications et maintenance des composants dans les
environnements distribués [Nil+03].
En plus, Danny B.Lange [Lan 99] suggère :
Personnal assistant : un agent mobile se déplace dans le réseau pour dispatcher
une demande de meeting au profil de son client. Durant cette période, la machine
du client peut être déconnectée. Une fois cette dernière se connecte, l’agent
renvoie la réponse, la date, les invités, … au client.
Médiation sécurisée : lors de négociation inter-agents non crus, ces agents
peuvent migrer et se rencontrer sur un hôte sécurisé et agréé par l’ensemble. Cet
hôte ne doit favoriser aucun des agents.
Contrôle (monitoring) et notification : des agents sont dispatchés pour sentir des
événements, attendre la création d’une information, …
Dissémination d’information : les agents mobiles cherchent et importent les
dernières mises à jour de logiciels et les installent chez le client.
Traitement parallèle : les agents se dispatchent sur plusieurs unités de calcul
pour paralléliser certaines tâches.
9. Problèmes inhérents à la mobilité
Sur ses deux axes (physiques et logicielle), la mobilité souffre de plusieurs limites et
reçoit une variété de critiques. Ci-dessous, on expose certaines des carences que connaisse la
discipline.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 19
9.1. Mobilité physique
Selon [For+94], le développement des systèmes mobiles rencontre plusieurs
challenges :
Les communications sans fil sont susceptible de déconnexion, une faible bande
passante(1Mbps infra rouge, 2Mbps radio, 9-14 cellulaire, par contre 10Mbps
pour Ethernet, 100 Mbps pour FDDI et 155 Mbps pour ATM, non portable
wireless MOTOROLA 5.7 Mbps), …
Les utilisateurs mobiles souffrent de problèmes liés à des conditions de travail
variables ( zones non couvertes, encombrement variables des zones), problèmes
de réseaux hétérogènes, problème de sécurité (les réseaux sans fils sont plus
susceptibles aux intrusions ).
Les adresses réseaux, les configurations (paramètres : imprimantes disponibles,
adresse du serveur, horaire, ) changent dynamiquement selon l’emplacement,
Problème de portabilité des dispositifs : faible puissance, risque de perte de
données (endommage physique ), petite interface, stockage limité, …
9.2. Agent mobiles
Selon [Cab+98], [Kot+99] et [Joh 04], l’approche mobilité demeurent une approche
immature. Elle souffre de plusieurs carences :
1. Problème de sécurité : Les hôtes dans un réseau doivent être protégés (i.e. par
authentification) contre les codes (agents) visiteurs et malveillants (cas des virus,
pirates, … . Les agents doivent être eux aussi protégés (être cryptés ) envers les sites
inconnus.
2. Problème de standardisation : Absence d’un standard sur le paradigme agent mobile.
Ainsi que l’absence d’une infrastructure standard et acceptée par tout le monde.
3. Coordination entre les agents : l’agencement de leurs actions dans le temps et dans
l’espace. La mobilité rend l’existence spatiale et temporelle de l’agent deux aspects
incontrôlables (non prédictibles).
4. Beaucoup de technologies (en général des langages de programmation) ont été
proposées (plus de 100). Mais ces langages qui émergent chaque jour n’apportent
aucune contribution aux problèmes cruciaux : sécurité, tolérance aux fautes, …
5. Performance limitée par rapport aux solutions traditionnelles. Le temps important
nécessaire pour l’interprétation des agents et leur migration.
En plus de ces problèmes techniques, les auteurs dans [Kot+99] suggèrent que les
agents mobiles souffrent de problèmes non techniques :
1. No killer application : tout ce qui est réalisable par agents mobiles peut être réalisé
par techniques traditionnelles. Le bon argument des agents mobiles est que ces
derniers doivent présenter une solution entière et efficace pour un certain, pendant
que les autres techniques traitent des aspects partiels du problème.
2. Problème de l’absence d’un chemin de passage des technologies actuelles (client
serveur, applets, servlets) vers les systèmes à agents mobiles. Ce passage doit être
incrémentale et justifié par une motivation des clients.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 20
3. Problèmes de revenus financiers des sites publicitaires : Ces sites vont perdre
l’avantage, si des agents mobiles peuvent parcourir le net en découvrant
directement, les services offerts par des fournisseurs.
Dernièrement, [Vig 04] a signalé dix raisons d’échec pour les agents mobiles :
1. Coûteux et non performant par rapport aux solutions classiques (exp. REV).
2. Leur conception est difficile : comment identifier les composants interactifs et
comment modéliser ces interactions.
3. Difficiles à implémenter : technologies actuelles en phase de prototypage. Les
environnements où les agents seront exécutés sont imprédictibles.
4. Difficiles à tester et à déboguer : à cause de la distribution et de la mobilité.
5. Difficile à authentifier et à contrôler : il n’est pas claire qu’elle identité doit être
authentifiée et comment le mécanisme de contrôle d’accès doit considérer cette
information.
6. Peuvent être victimes d’attaques de sites malveillants. Un hôte peut modifier le code
d’un agent. Une telle modification peut le rendre un agent malveillant.
7. Ne peuvent pas garder des secrets : absence d’aucune application pratique des
mécanismes de cryptographie proposés.
8. Manquent d’une infrastructure Omniprésente : Les infrastructures existantes ont
montré qu’elles seraient vulnérables d’attaques.
9. Manquent d’une ontologie commune : les interactions et les données échangées
doivent respecter des formats particuliers. Malgré les propositions, aucune d’elle n’a
connu une large admission.
10. Similaires aux worms : leur mécanisme de propagation est pareil à celui des
internet-worms. Les infrastructures dédiées aux agents mobiles seront victimes
d’attaques des worms.
10. Réalisations industrielles
Malgré les carences et les doutes que connaissent l’approche mobilité (et surtout agents
mobiles), [Bar 05] a pu recenser quatorze projets universitaires et industriels. La plus part de
ces projets exploitent le paradigme agent mobile. Certains de ces projets sont achevés avec
succès, d’autres sont encore ouverts.
1. ActComm (USA): 1997-2002, utilise la plate-forme D’Agents. Il est réalisé par
AFOOFR (Air Force Office Of Scientific Research). Ce projet accentue sur les
réseaux sans fil et les applications (modernes) de contrôle.
2. AMASE (Almagne): Un projet industriel (Deutsche Telekom), ouvert depuis 1998. Il
utilise une plate-forme privée. Son objectif est de réaliser des plate-formes supportant
des agents mobiles pour les environnements de communication sans fils (ex. Accès
aux informations multimédias).
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 21
3. CoABS (USA): ouvert depuis 1998, utilise Java Jini. Réalisé par AFRL-DARPA (Air
Force Research Laboratory). Son objectif est de développer différentes stratégies pour
accomplir le maximum de gain des systèmes multi-agents. Il propose et évalue des
stratégies de contrôle permettant aux commandants militaires d’automatiser des
commandes importantes, prise de décision, contrôle de fonctions (recherche, filtrage
d’informations, planification de missions, …)
4. CogVis (Almagne): « Cognitive Vision », ouvert depuis 2001. Il utilise la plate-forme
Mobile Agent Software. C’est un projet industriel (Information Society Technologie).
L’objectif de ce projet est de développer des agents mobiles avec des capacités de
vision.
5. DIAMOnDS (Pakistan) : ― Distributed Agents for Mobile and Dynamic Services‖, un
projet universitaire (University Of Islamabad), 2002-2003. Il utilise la plate-forme
Jini 1.1. Dans ce système, Les agents sont des services mobiles. Ces agents
accomplissent des tâches (communications, data-mining) aux profils des utilisateurs
(sur Internet) ou au profil d’autres services.
6. Dilema (IST European Commission) : ‖Digital Design and Life-cycle Management for
Distributed Information Supply Services in Innovation Exploitation and Technology
Transfer‖, un projet industriel, 2000-2002. Il utilise la plate-forme LANA. Les
agents sont des médiateurs. L’objectif de ce projet est le transfert de technologies et
d’innovations entre entreprises européennes, organisations de recherche, experts,
public, …
7. HAWK(Almagne) : ‖Harvesting the Widely Distributed Knowledge‖, un projet
universitaire (Stuttgart), 1998-2000. Il utilise JAVA. L’objectif de ce projet est la
recherche efficace (optimisée) d’informations sur Internet.
8. LEAP(France) : ‖Lightweight Extensible Agent Platform‖, un projet industriel
(Motorola), 2000-2002. Il utilise la plate-forme JADE. L’objectif est de proposer une
plate-forme standard. Cette plate-forme est exécutable sur des dispositifs mobiles
(PDA), ainsi qu’il est extensible pour recevoir d’autres fonctionnalités.
9. MadKit (France) : un projet de l’université MontPellier (a free ware), ouvert depuis
2002. Il est basé sur le modèle organisationnel (Agent/ Groupe/ Rôle). Les agents
peuvent être programmés par les langages Java, Sheme et Jess. Cette plate-forme
permet une hétérogénéité dans les architectures des agents et les langages de
communication.
10. MANTRIP (IST European Commission) : ‖MANagement Testing and Reconfiguration of
IP based networks using mobile software agents‖, un projet industriel (Solinet Germany),
2000-2002. Il utilise la plate-forme MAT (). L’objectif de ce projet est la conception,
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 22
le développement, le test, la validation d’applications basée sur la Technologie Agent
Mobile (MAT), pour la gestion des réseaux IP.
11. MAP (Almagne) : ” Mobile Adaptive Procedure” , un projet industriel (Siemens),
1989-2002. Il utilise la plate-forme SeMoA. L’objectif de ce système est le e-
assistance. Des agents domestiques interagissent avec des citoyens. Des agents
logiciels experts écoutent ces interactions, les comprennent et cherchent et préparent
les informations pertinentes pouvant assister les domestiques dans leurs interactions.
12. MOJAVE (USA) : ” MObile Jini Agent enVironmEnt” , un projet industriel
(Motorola) 2001-2004. Il utilise la plate-forme Jini. L’objectif de ce projet est de
développer les services malléables. Ces derniers doivent persister dans des
environnements dynamiques. Des exemples d’applications sont : la gestion de réseaux
et les systèmes tolérants aux intrusions.
13. SysteMATech (Almagne) : ‖System Management based on Mobile Agent Technology‖,
un projet industriel (iVS1, DFS
2 et accisGMBH
3), ouvert depuis 1999. Il utilise la
plate-forme Mobile Agent Software. L’objectif est la gestion distribuée (par agents
mobiles) des réseaux.
14. TeleCare (IST European Commission) : un projet industriel (UNINOVA du Portugal,
Synchronix Skill, Camara de l’Espagne et Roundrose Associated de la Grande
Bretagne), 2001-2004. Il utilise une plate-forme privée. L’objectif de ce projet est de
développer des solutions technologiques pour la télé-supervision, la télé-assistance, …
et ainsi d’améliorer les conditions de vie, de soins pour les âgés et leurs familles. Cette
plate-forme doit fournir une communauté virtuelle d'Aide pour âgés.
1 : http://www.ivs.tu-berlin.de/
2 : http://www.dfs.de
3 : http://www.accis.de
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 23
11. Efforts de standardisation
Une variété de systèmes d’agents mobiles (plate-formes et langages de programmations)
ont été proposés. Ils sont implémentés avec différentes technologies et offrent des langages
spécifiques pour la programmation des agents. Ces facteurs favorisent leur incompatibilité et
limitent leur interopérabilité. Des efforts de standardisations sont mis en place. Les deux
standards les plus important sont FIPA et MASIF.
FIPA : foundation for intelligent and physical agents, créé en 1996. Son objectif est de
standardiser les interfaces entre agents hétérogènes. FIPA concentre sur les aspects
intelligence et la coopération.
MASIF : Crystaliz, General Magic, GMD Fokus, IBM, et Open Group ont proposé la
norme MASIF [Mil+98] (Mobile Agent System Interoperability Facility). En 1998, MASIF
était accepté comme une norme OMG.
La norme MASIF met l’accent sur les interfaces entre les systèmes écrits dans le même
langage de programmation, mais fournis par différents fournisseurs. Elle ne traite pas les
interfaces entre les applications agent et ces systèmes d’agents. MASIF ne traite pas la
standardisation des opérations de bas niveau : Interprétation des agents, leurs sérialisation ou
leur exécution.
MASIF traite les problèmes suivant :
Gestion des agents : Rendre standard les opérations de : Création des agents, leur
suspension, leur restauration, leur terminaison.
Migration d’agent des agents : offrire une infrastructure commune pour assurer
le transfère d’agent entre des systèmes d’agents de différents types.
Gestion des noms des agents et des systèmes d’agents : Pour faciliter
l’identification des agents et des systèmes d’agents par les applications, MASIF
standardise la syntaxe et la sémantique des noms des agents et des systèmes
d’agents et des locaux des ressources.
12. Conclusion
Avec ses différentes formes, la mobilité en informatique représente un axe porteur de
plusieurs innovations. Depuis les premières tentatives de faire migrer des processus pour
équilibrer la charge dans les systèmes distribués, l’idée n’a cessé d’évoluer. Durant des
décennies de recherche sur ce thème, des paradigmes ont été proposés et des dizaines de
technologies ont été implémentées.
La fin des années 90 était caractérisée par d’intéressants travaux pour l’élaboration de
paradigmes conceptuels. Les paradigmes de REV (Remote Evaluation), COD (Cod On
Demand) et MA (Agent Mobile) représentent l’une des concrétisations les plus admises dans
la communauté.
Sur le stade technologique, et depuis même les années 80, plusieurs langages de
programmation et plate-formes de développement et d’exécution ont été réalisés. Ces
technologies ont permis à plusieurs industriels et universitaires de mettre en place des
systèmes commerciaux ou expérimentaux à base de composants mobiles.
Chapitre 1 : Mobilité en informatique Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 24
Malgré l’élégance de l’idée et la popularité du domaine, plusieurs pensent que
l’approche souffre de plusieurs lacunes. Certains suggèrent que ce n’est qu’un vrai échec. Les
défendeurs de cette opinion argumentent par le manque de performance, l’incompatibilité et le
problème crucial de la sécurité.
Pour couvrir ces carences, les défendeurs de l’idée proposent que des efforts doivent
être entrepris dans les tentatives de standardisation et les politiques et stratégies de sécurité.
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 25
Chapitre 2 :
Formalismes pour les Systèmes
Mobiles
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 26
1. Introduction
Dans le chapitre précédent, nous avions présenté la mobilité informatique avec ses deux
version: physique et logicielle et nous avions concentré sur le deuxième type de mobilité.
Plusieurs aspects, de ce genre de mobilité informatique, ont été discutés: Architectures et
plateformes, langages de programmation, projets industriels, … Quand on veut développer un
système informatique mobile, la spécification est l’une des phases importantes dans le
processus de développement. Dans ce cours, nous nous intéressons, en particulier, à la
spécification formelle offrant les moyens de vérification et de validation des systèmes. La
réalisation d’une spécification formelle exige la mise en place d’un formalisme dédié à la
mobilité. De nos jours, il existe une variété de formalismes qui peuvent être utilisés pour
spécifier les systèmes mobiles et de vérifier leurs propriétés.
L’objectif de ce chapitre est de présenter quelques formalismes proposés pour la
spécification est la vérification des aspects mobiles en informatique. Nous allons traiter tout
d’abord l’algèbre de processus avec sa version de base CCS (où, il n y a pas de mobilité) et
son extension pi-calcul qui a introduit la mobilité des liens de communication entre processus,
ensuite son extension dite join-calcul considérée comme plus convenable à la spécification de
processus mobiles. Enfin, nous présentons l’extension introduite à la logique de réécriture
avec le langage Mobile Maude pour prendre en considération la mobilité. Ce chapitre se
termine par une conclusion.
2. Algèbre de Processus
Cette section de ce chapitre va répondre aux questions suivantes :
C’est quoi un Algèbre de Processus?
Quelles sont les caractéristiques de l’algèbre CCS et pour quel système est proposé?
C’est quoi un processus CCS ? quels sont les types d’algèbre CSS ?
Syntaxe et Sémantique CCS.
2.1. C’est quoi un algèbre de processus
Un algèbre est un système constitué d’un ensemble: de termes, d’opérateurs et
d’axiomes. Ce système sera utilisé pour écrire et manipuler des expressions algébriques.
Un algèbre de processus est un langage de spécification qui comprend la possibilité
d’exprimer des interactions, des évolutions et des opérateurs pour assembler des sous-
systèmes en des systèmes. Ce langage dispose d’une sémantique (opérationnelle) formelle
basée sur des interactions atomiques syst./envt, et d’une notion de raffinement
comportemental.
2.2. Le CCS
Il existe plusieurs types d’algèbre de processus (on trouve: CCS, CSP, SCCS, TCSP,
ACP, LOTOS,...). Le CCS (Calculus for Communicating Systems) est l’algèbre de processus
développé par Milner (Turing Award) fin des année 70 et début des année 80. Le CCS est
caractérisé par :
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 27
• Un processus CCS est construit à partir d’actions atomiques et d’opérateurs de
composition.
• Le mécanisme d’interaction interprocessus est celui des rendez-vous
(synchronisation binaire a/ā);
Le CCS est proposé en particulier pour la spécification des systèmes réactifs. Un
système réactif est un système dont le comportement le plus important est la communication
avec d’autres systèmes où des réactions aux stimulus de leurs environnements. Un système
d’exploitation, système de contrôle, système de téléphones mobiles, … sont des exemples de
systèmes réactifs.
Processus CCS:
Un processus CCS est vu abstraitement comme une boite noire avec une interface (des
ports de communication) pour interagir avec son environnement. La figure 1 montre des
représentations graphiques de quelques processus CCS.
Figure 2.1. Représentation graphique des processus CCS
Types de CSS:
On trouve:
• Le CCS pur: pas de valeurs échangées entre processus;
• Le CCS avec passage de valeurs dans les communications.
Dans ce cours, on s’intéresse au CCS pur.
2.3. Communication et action dans le CSS
Dans la version de base «CCS pur», la communication est réduite à une
synchronisation sur des ports (canaux). Les processus ne se communiquent pas de
l’information via ces ports. Deux processus qui ont les mêmes noms de ports se
synchronisent et les communications sont bloquantes. Un processus CCS peut exécuter un
ensemble d’actions Act=AĀ{} tel que:
1) A = {a, b, c, d, …} est un ensemble de canaux d’entrée (appelés: actions d’entrée ou
de réception) ;
2) Ā= {ā, …} est un ensemble de canaux de sortie (appelés: actions de sortie ou
d’émissions) ;
3) : représente une action silencieuse (inobservable par les autres processus).
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 28
2.4. La syntaxe de CCS
• Un terme CCS peut être processus ou une action ;
• Il existe cinq opérateurs en CCS:
. (Opérateur de suffixe)
+ (opérateur de choix)
| (Opérateur de parallélisme)
\ (opérateur de restriction)
[f] (opérateur de re-nommage, où f est une fonction)
• Une expression CCS E (un processus) doit respecter la syntaxe suivante:
E::=0 (processus inerte, inactif, )
| α.E (a est une action, a.E : exécute a ensuite exécute le
comportement E)
| E1 + E2 (choix exclusif indéterministe entre E1 ou E2)
| E1|E2 (exécution concurrent de E1 et de E2)
|E1[f] (se comporter selon E1 avec un renommage selon f)
|E\L ( L: un ensemble de noms (de ports, d’action), les ports de L sont
restreints dans E, et donc ne sont plus visibles aux autres processus, on
note ça qq fois: (υL)P)
| P=E’ (déclaration du processus P comme étant ayant l’expression E)
|P (invocation du processus P)
Exemples :
• Le comportement d’une horloge : tik, tik, tik, tik, tik, tik, …On peut représenter ça
comme un processus CCS : Horloge=tik.tik.tik… ou encore Horlog=tik.Horloge
• Un distributeur de café reçoit une pièce de monnaie, il sert du café, il reçoit une pièce
de monnaie, il sert du café, …Ce système peut être spécifié comme suit :
DC=m.c.DC
• Un programmeur peut exécuter les actions suivantes: produire un programme, mettre
la monnaie, avoir du café, …
-Proposer une expression (processus) CCS pour ce comportement;
-Proposer une expression pour la communication entre le programmeur et le distributeur
2.5. La sémantique du CSS
Le CSS est un langage formelle est donc il dispose d’une sémantique opérationnelle
formelle. Cette formelle est basée sur des interactions atomiques système/environnement. La
sémantique opérationnelle de CCS définit les pas d’exécution des processus CCS. Cette
sémantique sera aussi à la base de l’étude des équivalences comportementales
(bisimulation).
La description de la sémantique du CCS est faite à l’aide des LTS (Labelled Transitions
Systems). Une sémantique Structurelle (SOS), les pas détaillés de l’exécution. Cette
sémantique est définie par un ensemble de règles. Un LTS est un triplet (Proc, Act, T), tel
que:
1) Proc: les états du LTS (des expressions CCS),
2) Act: les actions étiquetant les transitions (les actions en CCS), Act=AĀ{},
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 29
3) T: la relation de transition, elle sera définie par des règles de la sémantique
opérationnelle du CCS (voir la Figure 2).
Figure 2. Règles de la sémantique opérationnelle du CCS
Exemple : le LTS du processus a.Nil||ā.Nil est représenté dans la figure ci-dessous. Ce LTS
est généré en appliquant les règles présentées dans la figure 2. :
Figure 2.2. LTS pour un processus CCS
2.6. Exercices
Exercice 1 :
Un distributeur de boissons peut servir du thé ou du café après l’introduction d’une pièce de
monnaie et selon le choix du client.
Proposer une description CCS de ce distributeur.
Exercice 2 : Soit les figures ci-dessous :
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 30
Figure 1
Figure 2
Proposer une description CCS des différents processus présents dans les deux
schémas.
Dans la figure 2, on veut exclure le processus CS’ de l’usage des ports du processus
CM, proposer une spécification CCS qui assure ceci.
Exercice 3 : On dispose de trois machines qui permettent de distribuer respectivement : du chocolat,
des gâteaux, lait. Chaque distributeur exige la présence d’une pièce de monnaie.
Proposer une spécification CCS pour chacun de ces distributeurs.
Proposer un processus CCS générique qui modélise tous ces distributeurs. Un
distributeur de chocolat est donc une instance du processus CCS, décrire ça avec
le langage CCS.
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 31
Exercice 4 :
Dire si les expressions CCS suivantes sont syntaxiquement correctes ou non.
Exercice 5 : Soit le TLS de la figure 1 :
1) Décrire ce système sous forme (Proc, Act, Trans)
2) Proposer un processus CCS, pour ce LTS
Exercice 6:
Soient A = a.Nil+b.Nil et
B = ā.B+b.B.
Soient P= A||B et
Q= (A||B)\{a}.
1. Donnez toutes les transitions de la forme : →x avec x {a, b, ā, } de P (resp. Q) en les
justifiant par la sémantique SOS de CCS.
2. Dessinez un LTS pour P (resp. Q).
3. P (resp. Q) peut-il bloquer ?
4. Mêmes questions en remplaçant B par B’=ā.b.B’
Exercice 7 :
On considère le processus CCS S défini par les équations :
Dessiner le LTS de ce système
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 32
Exercice 8 : Soit les figures ci-dessous :
1) Pour chacun de ces LTS, trouver un programme CCS.
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 33
3. Le pi-calcul : une première extension du CCS
Le langage du pi-calcul est basé sur la version « CCS avec échange de valeurs » ou
« Valued-CCS». Cette version de CCS est une extension du CCS de base où il est possible de
faire un échange d’informations entre les processus durant leur communication. Ces
informations dites « valeurs » peuvent être échangées via les ports de communication des
différents processus CCS. Ces valeurs peuvent être scalaires ou des vecteurs.
3.1. Syntaxe du valued-CCS
Dans le valued-CCS, on a deux ensembles disjoints: A pour les noms des ports et X
pour les noms des valeurs. Pour la syntaxe du valued-CCS c’est la même syntaxe présentée,
déjà, dans la section précédente avec une nouvelle règle pour les préfixes dans les
expressions. Un préfixe a une syntaxe plus étendue:
Tel que :
- : signifie l’envoi de la valeur x via le port a
- a(x) : signifie la réception de la valeur x sur le port a
Exemple de processus dans le langage valued-CCS :
1)
2)
3)
4)
3.2. Motivations du pi-calcul
Le pi-calcul est une extension du CCS proposée pour la spécification des systèmes
dynamiques. En particulier, le pi-calcul permet de spécifier pour les systèmes où les liens de
communications sont dynamiques. Par conséquent, les noms des ports de communications
peuvent changer durant le déroulement du système. Les processus (dits agents) peuvent
échanger leurs ports de communication, comme ils échangent des valeurs entre eux.
L’idée de base en pi-calcul est de considérer que les noms des valeurs et les noms des
ports appartiennent à un même ensemble de noms qu’on appelle N (pour Names):
N = A X, où A et les noms des ports et X et les noms des valeurs.
Exemple de processus dans le langage pi-calcul:
:: ( )| ( )|a x a x
( )a x
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 34
3.3. Syntaxe du Pi-calcul
La syntaxe du langage pi-calcul est donnée selon la grammaire suivante :
3.5. La dérivation dans le pi-calcul
La dérivation est l’opération qui permet de représenter l’exécution des processus en pi-
calcul. Cette dérivation utilise la substitution pour transformer des termes vers d’autres
termes. La substitution concerne les occurrences liées des variables par des valeurs. On
présente ci-dessous la notion d’occurrences libres et liées, ensuite on présentera la notion de
substitution et de -conversion nécessaire lors des dérivations:
• Noms libres et noms liés
Pour un nom x il est lié ssi
- Soit il est sous la porté d’un préfixe d’entrée
Exemple : dans a(x), x est lié
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 35
- Soit il est sous la porte d’une restriction
Exemple : dans v(x), x est lié
Sinon, il est libre
• Substitution et -conversion
1) Lors d’une substitution dans un terme, on ne peut que substituer les noms non liés,
2) Pour éviter que des noms libres soient capturés par des lieurs il faut effectuer un re-
nomage des noms liés,
3) Ce re-nomage des noms liés est dit une -conversion.
3.6. SOS du pi-calcul
La sémantique opérationnelle structurelle du pi-calcul est la suivante :
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 36
3.7. Exercices
Exercice 1: Calculer les dérivations suivantes :
Exercice 2:
Soit les trois processus pi-calcul suivants :
1) Soit le processus composite Q|P|R. Calculer toutes les transitions possibles.
2) On veut que le processus P soit il envoie les deux valeurs u et v à Q soit à R. Proposer
les modifications nécessaires sur la spécification présenté ci-dessous pour assurer ceci
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 37
4. Le Join-calcul : une autre extension du CCS
Le Join-Calculus (JC) est une autre extension du CCS. Il est l’un des premiers langages de
spécification proposés pour la mobilité de code. Ce langage introduit, en particulier, la notion
de localité (chose non spécifié en pi-calcul) de façon explicite. Il existe deux variantes: le
calcul de base et le calcul distribué.
4.1. Le JC distribué
Le JC de base « Core Join Calculus » [6] est un langage pour la modélisation de la
programmation distribuée et mobile. Il caractérisé par une notion de localité explicite, une
synchronisation local, et il englobe langage de programmation ML [7]. Le JC est utilisé
comme fondement pour certains langages de programmation comme le cas de «JoCaml» [8]
et de «functional nets» [9]. Dans le JC, la distribution des ressources était implicite, alors que
dans le DJC [5] permet d’exprimer de manière explicite le mouvement des agents entre sites
physiques. Dans le DJC, une « localité » réside sur un site physique et elle contient un groupe
de processus et de définitions. Une localité peut se déplacer d’un site physique vers un autre.
Les agents mobiles sont, donc, représentés par des localités. Dans ce contexte, les agents
« localités » peuvent contenir d’autres agents « sous localités ». Les agents peuvent se
déplacer en emportant leurs sous agents, donc la structure des localités peut être vu comme un
arbre dynamique. Les noms des localités (ou des agents mobiles) sont des valeurs de premiers
classes avec une portée lexicale, et c’est le même cas pour les noms des canaux de
communication. La portée des noms peut même changer due à la mobilité des agents. Les
agents mobiles contrôlent leur mobilité de manière autonome et peuvent migrer à un site en
donnant le nom de ce site. Dans cette section, nous allons présenter tout d’abord la syntaxe
ensuite nous passons à traiter quelques exemples.
4.2. La syntaxe du JC distribute (DJC)
Un système spécifié en DJC est vu comme un ensemble de configurations. Ces
configurations évoluent dans le temps et peuvent interagir. Une spécification dans le DJC est
composée, d’un autre côté, d’un ensemble de termes. Un terme peut être soit un processus,
soit une définition, ou une configuration.
La grammaire des processus DJC est la suivante :
P::=
0 // le processus inert
| P|P’ // composition parallèle de deux processus P et P’
| x<ŷ> // émission asynchrone d’un message ŷ sur le canal x
| Def D in P // une définition D dans un processus P, voir la grammaire des définitions
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 38
| go a; P // une demande de migration de la localité actuelle vers une localité a,
ensuite de s’exécuter comme P
La grammaire des définitions dans DJC est comme suit:
D::=
T // la définition vide
| D, D’ // Composition de deux définitions D et D’
| JP // une règle de réaction: cette règle attend l’arrivée d’un ensemble de messages qui
correspondent aux messages définis dans le schéma « join pattern » J, ensuite le processus P
s’exécute.
| a[D:P] // déclare une nouvelle localité a. contenant : une définition D et un processus P.
La grammaire d’un schéma J est comme suit :
J::=
x<ŷ> // attente d’un message ŷ sur le canal x. le schéma J est dit satisfait à l’arrivée du
message.
| J|J’ // Synchronisation de deux schémas J et J’. Le schéma J|J’ est satisfait quand J et
J’ sont satisfaits.
Enfin, la grammaire d’une configuration DJC est comme suit :
S::=
//la configuration vide.
| S||S’ // Composition de deux configurations.
| D├ P //où est une séquence de localité représentant un chemin.
4.3. L’exécution des processus DJC
L’exécution dans le DJC est réalisé selon le modèle DCHAM (Distributed CHemical
Abstract Machine). Un système spécifié selon le modèle CHAM [10] est vu comme un
ensemble de molécules qui évoluent au sein d’une solution. Dans une solution, les molécules
peuvent évoluer quand certaines conditions de réaction sont satisfaites. Formellement, une
solution est écrite sous la forme: R├ M, où M est l’ensemble de molécules et R est l’ensemble
de règles de réaction. En DJC, les molécules de M représentent les processus s’exécutant en
parallèle, et R représente les règles de réduction courantes « join calculus definitions ». Quand
une réaction est faite, les molécules M se transforment vers M’. Cette réaction est modélisée
sous forme d’une étape de réduction écrite comme suit:
(R├ M)(R├ M’)
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 39
Dans le DJC, une configuration est considérée comme une solution. La seule règle de
réaction est le schéma : JP. Cette règle va changer le processus P en instanciant les
paramètres formels dans P qui correspondent aux valeurs reçues dans les messages
asynchrones définis dans J.
Comme exemple, considérant La configuration suivante:
├ ready(laser), job(1), job(2)
Dans cette solution, nous avons une imprimante nommée laser qui est prête à imprimer
(ready(laser) est un molécule), et nous avons deux travaux à imprimer: 1 and 2 ( job(1),
job(2) sont deux molécules aussi). Dans cette configuration, trois émissions asynchrones sur
deux ports: ready et job. Dans cette solution, il n’y a pas de règle de réaction. Cette solution
peut être aussi comme suit:
├ ready(laser)| job(1), job(2)
On peut ajouter, à la solution précédente, la règle de réaction suivante:
D= ready(printer)|job(file) printer (file)
Cette règle de réaction signifie que si on dispose d’une imprimante (printer) libre (ready)
et d’un certain travail (job) dont le nom est file, donc on peut envoyer ce travail « file » à cette
imprimante libre. Quand on ajoute cette règle à la solution précédente, on va obtenir une
nouvelle solution :
D├ ready(laser)| job(1), job(2)
On voit que ( ready(laser)|job(1) ) dans l’ensemble de molécules correspond à ( ready(printer)|job(file) ) dans la définition D, les identificateurs formels printer et file dans
la définition D peuvent être remplacés par les paramètre effectifs: laser, et 1, et le « join
pattern » : (ready(printer)|job(file) printer (file)) est donc rendu satisfait. Dans ce cas, la
solution évolue. Une étape de reduction peut être appliqué pour envoyer le travail: ―1” à
l’imprimante noméee : laser.
ready(printer)|job(file) printer (file)├ ready(laser)| job(1), job(2)
ready(printer)|job(file) printer (file)├ laser(1), job(2
Formellement, nous avions appliqué une règle dite: ―join reduction‖ ou (Reaction-rule),
qui est la suivante:
Reaction-rule: (JP├ Jrv,… ) (JP├ Prv,…)
où rv est une substitution sur les variables reçues (paramètres formels du message reçu
dans la jointure). Ces variables sont: printer et file qui seront subsitituées par: laser et 1.
Donc, nous avons les substitutions:
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 40
Jrv = (ready(printer)|job(file))rv = ready(laser)| job(1)
et
Prv = (printer (file))rv = laser(1)
En plus de la correspondance dans les schémas de jointure : ―join pattern matching‖, deux
autres règles structurelles sont aussi définies:
(├ Def D in P) (D├P)
(D├P) (├ Def D in P)
Ces deux règles montrent la réflexivité dans le CHAM. Ces deux règles peuvent être
combinées en une seule règle :
str-def-rule: (├ Def D in P) ↔(D├P)
Cette règle strucutelle nous indique qu’à partir d’une solution contenant un seul processus:
(Def D in P) sans aucune règle de réaction, on peut obtenir une solution où les jointures
définies dans D seront des règles de réaction dans la solution contenant P.
Dans une DCHAM (Distributed CHAM), on dispose d’un ensemble de solutions.
L’opérateur || est utilisé pour la composition de solutions. Les solutions peuvent évoluer
séparément ou interagir. Les solutions interagissent en utilisant les règles de réduction :
(COMM-rule):
COMM-rule: ((├ x<ŷ>)||(D├)) (D├ x<ŷ>)
Dans cette règle, x est le nom d’un port défini dans D. Cette règle signifie que le message
émis d’une solution via un port, défini dans une autre solution, peut être envoyé à cette
dernière solution.
Pour introduire les localités, les solutions sont étiquetées par les noms des localités où ells
resident. Par exemple, la solution D├P est étiquetée par le chemin de localités. Ce chemin
de localités peut être une seule localité ou une séquence de localités imbriquées. Par
exemple, dans un système d’impression on distingue entre trios sous systems: une machine de
l’utilisateur u d’où la requête d’impressions est lancée :
├u
job<1>
Une machine serveur s qui héberge le spooler d’impression :
D=ready(printer)|job(file) printer (file)
D├s
Et enfin, une imprimante laser p enregistrée comme étant ready, au niveau du serveur qui
contient le code d’impression P :
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 41
laser(f) P├p ready<laser>
Le système global est comme suit donc:
├u
job<1> || ready(printer)|job(file) printer (file)├s
|| laser(f) P├p ready<laser>
La règle introduite précédemment peut être généralisée pour considérer les localités:
COMM-rule: ((├ x<ŷ>)||(D├
)) ((├
)||( (D├
x<ŷ>)
Maintenant, on peut appliquer les deux règles COMM-rule et Reaction-rule pour faire une
execution dans ce système, comme suit:
├u
job<1> || D├s
|| laser(f) P├p ready<laser>
COMM-Rule between u and s
├u
|| D├s
job<1> || laser(f) P├p
ready<laser>
COMM-Rule between p and s
├u
|| D├ s
job<1>, ready<laser>|| laser(f) P├p
Reaction-Rule in s
├u
|| D├s laser(1)
|| laser(f) P├
p
COMM-Rule between s and p
├u
|| D├s
|| laser(f) P├p laser(1)
Dans cette exécution, la première étape envoie job 1 de la machine machine u vers le
serveur s, et la deuxième étape envoie le nom de l’imprimante libre laser vers s. La première
étape est réalisée sur le serveur et doit affecter job 1 à l’imprimante laser. L’étape finale ré-
envoie job 1 à l’imprimante laser qui va l’imprimer.
La définition: a[D:P] définie une nouvelle localité a, où une définition D est déclarée et
un processus P s’exécute, correspond à la solution solution D├a
P, où est le chemin des
définitions locales dans D. deux règles structurelles sont définies qui représentent le pliage et
le dépliage des chemins de localités :
LOC-rules: a[D:P]├ D├
a P
D├a
P a[D:P]├
Ces deux règles peuvent être combines dans la règles réflexive suivante: a[D:P]├ ↔
D├a
P
Enfin, la migration de processus est réalisée via l’instruction ―go a; P” qui va transférer la
localité courante vers une localité nommée a, où P sera exécuté. L’exécution de la migration
est faite via la règle de réaction suivante:
GO-rules: ├b
go a; P || ├a
├b
|| ├a
P
Cette règle montre la migration du processus P de la solution été étiquetées b à la solution
étiquetées a.
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 42
4.4. Exemples de spécification en DJC
Dans le DJC, la localité est contrôlée explicitement; cette localité peut être changée par la
migration. Dans l’implémentation JoCaml [8], les programmes s’exécutant sur différentes
machines ne peuvent pas partager, initialement, les noms de canaux. En effet, ces programmes
ne sont pas capable de s’interagir. Pour arriver à s’interagir, il est nécessaire d’échanger
quelques noms via une librairie : « name server (NS) ». Les noms dans NS peuvent être
utilisés par la suite pour communiquer d’autres et donc construire des schémas de
communication plus compliqués. L’interface de la librairie NS consiste en deux fonctions :
« register » et « lookup ». Le premier exemple montre l’usage d’une fonction à distance (cos),
via un appel à distance. Dans le deuxième exemple, un agent migre vers la localité où cette
fonction est définie pour avoir son exécution et retourne avec des résultants.
Example 1:
Dans le premier exemple, la machine 1 contient un processus qui définit un nom local cos
ensuite l’enregistre dans NS. Sur la machine 2, un autre processus obtient le nom cos depuis
le NS est fait un appel à distance à ce nom. Ici, il n’y a aucune migration mais tout
simplement il s’agit d’un RPC (Remote Procedure Call).
Example 2:
Dans le deuxième exemple, et sur machine 1, un processus crée explicitement une localité :
cos00 qui contient la (cos). Dans ce cas, le processus enregistre aussi le nom de la localité
avec la clé : ―here‖. De l’autre coté, et sur la machine 2, on définit une fonction f avec un
paramètre formel machine. Cette fonction définie aussi une localité: agent. Cette localité
nommée: agent migre vers la localité machine (première instruction dans son code: go machine).
Sur la localité machine, l’agent exécute un programme « sum » qui doit utiliser la fonction
def
cos(x) = 1 − x2/2
in
NS.register(‖cos‖, cos)
def
cos = NS.lookup(―cos‖)
in
print(cos(0.1));
Machine 1 Machine 2
Def here[
cos(x) = 1 − x2/2 :
NS.register(―cos00, cos); . . .
]
in
NS.register(―here‖, here); . . .
Machine 1
Def f(machine)
agent [
go machine;
def cos = NS.lookup(‖cos‖) in
def sum(s, n) = if n = 0 then s else
sum(s + cos(n), n − 1) in
return sum(0, 10)
]
print(f(NS.lookup(‖here‖))); . . .
Machine 2
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 43
cos définie dans la localité « machine ». En effet, l’exécution démarre par l’instruction:
print(f(NS.lookup(‖here‖))) qui doit instancier le paramètre formel machine par le nom: here.
5. Logique de réécriture vers la mobilité : Mobile Maude
Dans cette section, nous présentons la logique de réécriture : LR. Cette logique proposée par
Meseguer [MAR+93] représente un formalisme universel qui doit englober tous les
formalismes dédiés à la concurrence. Cette section est divisée en trois sous section :
présentation de la logique de réécriture, présentation de Maude comme langage implémentant
la LR, et enfin présentation de Mobile Maude comme une extension de Maude proposé pour
les systèmes mobiles.
5.1. La logique de réécriture : LR
La présentation de la LR exige tout d’abord de présenter ce que nous appelons Algèbre
Universel [Mar+93].
Algèbre Universel
Soit :
={n | nN} un alphabet rangé. Les éléments de sont des symboles de fonctions. Et
donc, n contient tous les symboles fonctions avec n-arité.
Définition 1 (-algèbre):
Soit A un ensemble et fA : AnA une fonction. Un -algèbre est l’ensemble A avec la fonction
fA pour chaque f dans n, où nN.
Nous notons par T un -algèbre à raison des -termes et par T(X) un -algèbre avec
-termes contiennent uniquement des variables dans l’ensemble X.
Si E est un ensemble de -équations alors: nous notons par T,E un -algèbre des
termes équivalent à raison de -termes modulo E ; et par T,E(X) un -algèbre des
termes équivalents à raison de -termes modulo E, avec des variables dans l’ensemble
X.
Si t est un terme: [t]E ou [t] : dénote the la classe E-équivalence de t.
Si t est terme ( tT({x1, …, xn}) ) et u1, …, un sont aussi des termes: l’expression :
t(u1/x1, …, un/xn) ou t(ū/) dénote le terme t après la substitution de u1, …, un dans les
variables x1, …, xn.
Règles d’une LR
Définition 2 (Signature d’une LR): une signature est un pair (, E). Où: est alphabet range
et E est un ensemble de -équations.
Définition 3 (phrase dans une LR) :
Soit t, t’ deux termes dans -termes. Une phrase dans une LR est un séquent de la forme
[t]E[t’]E .
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 44
Définition 4 (Théorie de réécriture : TR) :
Une TR R est un 4-uplet (, E, L, R), où:
: a alphabet rangé,
E: un ensemble de -équations,
L: un ensemble d’étiquètes, et
R L x T,E(X)2, où X={x1, …, xn, …}, est un ensemble de règles de réécriture
étiquetées.
Un élément de R est un pair (r,([t]E,[t’]E)) où la première partie est un étiquète et la
deuxième partie est une règle de réécriture. (r,([t]E,[t’]E)) est notée: r : [t]E[t’]E ou
r : [t(x1, …, xn)]E[t’(x1, …, xn)]E
La règle : r : [t]E[t’]E. est dite inconditionnelle.
Définition 5 (Preuve) : Soit R une TR. R prouve le séquent [t][t’] ssi il existe une
deduction finie contenant: [t][t’] à partir de R.
Les règles de déduction: pour chaque [t], [t’]T,E(X), fn
1) Réflexivité:
2) Congruence:
3) Remplacement: pour chaque règle: [t][t’] on a:
4) Transitivité:
Notation:
R├r dénote que R prouve la règle r.
Remarque:
La logique équationnelle est obtenue en ajoutant la règle de symétrie:
On écrit ceci sous la forme [t] [t’], appelé règle bi-directionelle ou tout
simplement : équation.
Definition 6 (concurrent R -rewrite): Soit R une TR, [t][t’] un séquent. [t][t’] est dit
concurrent R –rewrite ssi on peut obtenir R├[t][t’] par une application finie des règles 1-4.
5.2. Maude
C’est quoi Maude?
Un langage de spécification,
Basée sur LR,
[t][t’]
[t1][t1’] … [tn][tn’]
f(t1, …, tn) f(t1, …, t’n)
[w1][w1’] … [wn][wn’]
t(w1/x1, …, wn/xn) t’(w1’/x1, …, wn’/xn)
[t][t’], [t’][t’’]
[t][t’’]
[t][t’]
[t’][t]
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 45
Permet la spécification, la simulation et la vérification de propriétés des systèmes
distribués.
Une spécification Maude est une théorie (signature + axiomes). Cette théorie est dite
module.
Il existe plusieurs versions de maude: core Maude, full Maude, mobile Maude. Dans
Core Maude, on peut définir uniquement deux types de modules : Functional module
et System modules. Dans Full Maude, on peut avoir : Functional module, System
module, et Object module. Ces modules peuvent être paramétrés par des théories:
functional theories, systems theories et object theories.
Functional modules
Signature:
Un ensemble de sortes (no junk no confusion are added: voir les types abstraits de
données),
Un ensemble de sous sortes,
Des opérateurs avec des profiles et des attributs (commutatif, associatif, … ),
Surcharge des opérateurs,
Axiomes:
Equations dans la logique équationnelle avec adhésion (une extension de la logique
avec l’opérateur d’appartenance),
Ces équations doivent assurer: terminaison et la propriété de Church-Rosser.
Example: fmod BINARY-NAT is
protecting NAT .
sorts Bit Bits .
subsort Bit < Bits .
ops 0 1 :-> Bit .
op __ : Bits Bits -> Bits [assoc] .
op |_| : Bits -> Nat .
op not_ : Bits -> Bits .
vars S T : Bits .
*** Not
eq not (S T) = (not S) (not T) .
eq not 0 = 1 .
eq not 1 = 0 .
endfm
Dans l’interpréteur de commandes on peut faire des réductions de termes :
Example : red not 0
result 1
System modules
Ils correspondent aux théories RL.
Signature:
Pareil aux functional modules.
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 46
Axiomes:
Equations, axiomes : Pareil aux functional modules.
Des règles de réécriture doivent assurer: terminaison et la propriété de Church-Rosser.
Les RR représentent des transitions locales que le système doit franchir pour transiter
d’un état vers un autre. Un tel comportement peut être infini.
Exemple :
mod petri_net is
sorts place marking .
subsort place < marking .
op _ _ : marking marking marquing [assoc comm] .
ops $ q a c : place .
rl [buy-c] : $ => c.
rl [buy-a] : $ => a q .
rl [change] : q q q q => $ .
endm
On peut simuler l’exécution de ce système depuis un état initial par une commande
rewrite. Puisque l’exécution peut être infinite, on peut fixer un nombre max de
réécritures à ne pas dépasser
Exemple :
rewrite [1] q q q q .
result : $
rewrite [2] q q q q .
result : a q
Quelques modules systèmes prédéfinis : TRUTH-VALUE, TRUTH, BOOL, MACHINE-
INT, QID, QID-LIST.
Object oriented module
Similaire aux system modules.
Specifient les systèmes OO comme une configuration: multi-ensemble d’objet et de
messages.
Il définit la sorte: Oid (object identifier) et Cid (class identifier)
Il définit un constructeu pour les objets: <Oid:Cid| a1: v1, a2: v2, …>
Tous les modules objets importent implicitement le module de base :
CONFIGURATION,
Exemple:
(omod ACCNT is
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 47
…
class Accnt | bal : MachineInt .
…
msg credit debit : Oid MachineInt Msg
…
vars A B : Oid .
…
rl [credit] : credit(A, M) <A:Accnt | bal : N> => <A :Accnt |bal : (N+M)>
…
endom)
Parameterized modules:
Les théories sont utilisées pour déclarer des modules d’interface.
Les vues sont utilisées pour instancier les paramètres formels par ceux effectifs.
Exemple:
Soit la théorie :
(fth TRIV is
sort Elt .
endft)
un module paramétré par la théorie TRIV s’écrit comme suit :
(fmod SIPMLE-SET [X::TRIV] is
….
sort Elt.X . ****** the sort Elt defined in theory X
….
var E : Elt.X .
eq E E = E .
endfm)
a view
(view MachineInt from TRIV to MACHINE-INT is
sort Elt to MachineInt .
endv)
an instantiation can be :
(red-in SIPMLE-SET[MachineInt]: E E .)
5.3. Mobile Maude
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 48
C’est quoi ?
Une extension de Maude,
Deux nouveaux concepts: processus et objet mobile :
Processus: localités où les objets resident et s’exécutent
Objet Mobile: peut migrer d’un processus vers un autre, peut échanger des
messages asynchrones.
Des mécanismes de sécurité :
Authentication,
Secure message passing,
Secure object mobility.
Principes
Deux classes prédéfinies: P et MO.
Utilise deux sortes: Pid et Mid.
Pid : noms des processus,
Mid : noms des objets mobiles, chaque nom est un pair o(PI, N), où PI P denote le
parent et N est le nombre d’occurrence de o.
class P | cnt : MachineInt,
cf : Configuration,
guests : Set[Mid],
forward : PFun[MachineInt, Tuple[Pid, MachineInt]] .
cnt : counter for children mobile objects, used to give name to new created object,
cf : configuration (a set of mobile objects and messages) inside the process,
guests : information about currently objects inside the process,
forward : a partial function modeled as a table that stores information about mobile
object children. It maps each child number to a pair : currently process name
and number of hops the child has taken so far. Every time a mobile object hops
to another process, it informs its parent process.
class MO | mod : Module,
s : Term,
p,hops : MachineInt,
gas : MachineInt,
mode: Mode .
mod : oriented object module (a rewrite theory the code), a meta-representation of the code,
s : a pair of configurations C & C’: (a meta-representation of the state)
C: unprocessed incoming messages and inner object (the same identity of the object
containing it).
C’: outgoing messages,
p: currently location process,
hops : number of hops,
gas : bound of resources consumption ,
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 49
mode: active if the object is inside a process, and idle when it is moving.
Communication entre objets:
Objets dedans le même objet mobile,
Objets dedans des objets mobiles différents: transparente pour les objets mobiles. On
utilise la syntaxe: to_:_ : addresse de l’object contenu,
Primitives de mobilité
Pour se déplacer vers un autre processus, un object met dans un message de sortie :
go(PI), tel que PI est le nom du processus de destination.
Pour créer un objet mobile, un objet met newo dans un message. newo prend
comme argument: module et configuration initiale .
Exemple de règles
Mobilité d’objets:
rl [message-out-move] :
< M : M0 | s : ’_&_[T, ’go[T’]], mode : active > =>
go(downPid(T’), <M : M0| s: ’_&_[T,{’none}’MsgSet], mode:
idle>)
rl [go-proc]:
<PI: P | cf: C go(PI’, <M:M0|>), guests: M . SM0>
=> if PI=/=PI’
then <PI: P| cf: C, guests: M0> go (PI’, <M:MO|>)
else <PI: P| cf: C <M: M0| p: PI, mode: active>>
fi .
rl [arrive-proc]:
go(PI, <o(PI’, N):M0| hops: N’>)<PI: P| cf: C, guests: SM0,
forward: F>
=>if PI==PI’
then <PI: P|cf: C<o(PI’, N): M0| p: PI, hops: N’+1, mode:
active>, guests: o(PI’, N) . SM0, forward: F [N->(PI,
N’+1)]>
else <PI: P| cf: C<o(PI’, N):M0| p: PI, hops: N’+1, mode:
active>, guests: o(PI’, N). SM0>
to PI’@ (PI, N’+1){N}
fi .
Exécution d’objet:
crl [do-something]:
Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 50
<M: M0| mod: MOD, s: T, gas: N, mode: active>
=> <M: M0|s: meta-rewrite(MOD, refill(T,N), 1), gas: N-1>
if (N>0) and (refill(T,N)=/=meta-rewrite(MOD, refill(T,N), 1))
.
6. Conclusion
Dans ce chapitre, nous avons examiné quelques formalismes proposés pour la mobilité. Les
formalismes présentés sont : L’algèbre de processus, Le pi-calcul, le join-calulus, et enfin la
logique de réécriture. Pour chaque formalisme, nous avions présenté le fondement théorique
ainsi que des exemples montrant l’usage de chacun des ces formalismes ont été montré.
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 51
Conclusion Générale
Conclusion générale Dr : L. Kahloul
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 52
Conclusion Générale
Dans ce support de cours, nous avons les éléments les plus pertinents du cours SSM
(Sémantique des Systèmes Mobiles), destiné aux étudiants de M2, option GLSD (Génie
Logiciel et Systèmes Distribués).
Ce support de cours était organisé en deux chapitres:
1) Un premier chapitre qui présente de manière informelle les systèmes mobiles et
l’informatique mobile dans ses deux aspects : logiciel et matériel ;
2) Un deuxième chapitre qui présente les formalismes les plus exploités pour la
spécification et la vérification des systèmes mobiles.
Ces deux chapitres étaient suivis par une annexe qui englobe quelques séries d’exercices
traitées, déjà, dans ce module.
Support du cours du module SSM (GLSD : l’ancienne option VDSC) 53
Références
Références……………………………………………………………………………… Dr : L. Kahloul
54
Références
1. [Ado 85] : Adobe Systems Inc., PostScript Language Reference Manual. Addison-
Wesley, 1985.
2. [Adl+96]: A. Adl-Tabtabai, G Langdale, S.Lucco and Robert Wahbe. ―Efficient and
language-independent mobile programs‖. In Proceeding of the SIGPLAN’96
Conference on programming language design and implementation, 1996.
3. [Alf+98]: Alfonso Fuggetta, Gian Pietro Picco and Giovanni Vigna, ―Understanding
Code Mobility‖.IEEE transactions on software engineering, vol. 24, no. 5, may 1998.
4. [Ach+97]: A. Acharya, M. Ranganathan, J. Saltz, ―Sumatra: a Language for Resource
Aware Mobile Programs‖, Mobile Object Systems, Lecture Notes in Computer
Science, No. 1222, Springer Verlag (D), pp. 111-130, February 1997.
5. [Arn+96]: K.Arnold and J. Gosling. ―The java specification language‖. Sun Micro
System, 1996.
6. [Bar 05]: Andrea Barbu, ― developing mobile agents through a formal‖, Thesis prepared in french-german co-tutelle, Verteidigt am 12 September 2005 vor der Pr ufungskommission.
7. [Bor 94]: Nathaniel S. Borenstein. ―Email with a mind of its own: The Safe-Tcl
language for enabled mail‖. In Proceedings of the 1994 IFIP WG6.5 Conference on
Upper Layer Protocols, Architectures, and Applications, Barcelona, May 1994. North-
Holland.
8. [But+84] : David A. Butterfield and Gerald J.Popek ; ―Network tasking in the Locus
distributed Unix systems‖, In USENIX Summer 1984 Conference Proceeding, pages
62-71, 1984.
9. [Car 94]: Luca Cardelli. ― Obliq: A Language with Distributed Scope”. DEC Systems
Research Center, May 1994.
10. [Car 95]: L. Cardelli, ―A Language with Distributed Scope,‖ Computing Systems, vol.
8, no. 1, pp. 27–59, 1995.
11. [Car+ 97]: A. Carzaniga, G.P. Picco, and G. Vigna, ―Designing Distributed
Applications with Mobile Code Paradigms,‖ Proc. 19th Conf. Software Eng.
(ICSE’97), R. Taylor, ed., pp. 22–32, ACM Press, 1997.
12. [Che+95]: David Chess, Benjamin Grosof, Colin Harrison, David Leine, Colin Parris
and Gene Tsudik. ―Itinirant agents for mobile computing‖. Technical Report RC
20010, IBM T.J. Watson Research Center, March 1995, Revised October 17, 1995.
13. [Col 95]: ―Omniware technical Overview‖. Colusa Software White Paper. 1995.
Available from http://www.colusa.com
Références……………………………………………………………………………… Dr : L. Kahloul
55
14. [Cos+96]:J. Cosling, B. Joy, and G. Steele. ―The java specification language‖. Sun
Micro System, 1996.
15. [Dou 87] : Fred Douglis. « Process migration in the Sprite operating system ».
Technical Report UCB/CSD 87/343, Computer Science Division, University of
California, Berkeley, February 1987.
16. [For+94]: George H.Forman, John Zahorjan, ―The Challenges of Mobile Computing‖.
UW CSE Tech Report #93-11-03 from ftp.cs.washington.edu. An edited version
accepted in IEEE Computer.
17. [Fra+98] : Franklin, M. and S. Zdonik, ―Data In Your Face: Push Technology in
Perspective.‖ ACM SIGMOD International Conference on Management of Data, pp.
516-519. 1998
18. [Geo+96]: George H.Forman and John Zahorjan, ― The Challenge of Mobile
Computing‖, Computer science & engineering, university of washignton. March 9,
1996. accepted in IEEE.
19. [Ghe+97]: C. Ghezzi and G. Vigna, ―Mobile Code Paradigms and Technologies: A
Case Study,‖ Rothermel and Popescu-Zeletin [72], pp. 39–49.
20. [Gia+89]: Alessandro Giacalone, Prateek Mishra, and Sanjiva Prasad. ―Facile: A
symmetric integration of concurrent and functional programming. International
Journal of Parallel Programming”, 18(2):121–160, April 1989.
21. [Gra+96] : Robert Gray, David Kotz, Saurab Nog, Daniela Rus, George Cybenko, ―
Mobile agents for mobile computing,‖ Technical Report PCS-TR96-285, 1996,
ftp://ftp.cs.dartmouth.edu/TR/TR96-285.pdf
22. [Hew 80] : Carl Hewitt. « The Apiary network architecture for Knowledgeable
systems ». In Conference Record of the 1980 Lisp Conference, page 107-118, Palo
Alto, California, August 1980. Stanford University.
23. [Jin 04] : Li Jingyue , « Code Mobility Overview » (Essay for DIF 8914). Department
of computer and information science, Norwegian University of Science and
Technology, 2004.
24. [Joh+95]: D. Johansen, R. van Renesse, and F.B. Schneider, ―An Introduction to the
TACOMA Distributed System—Version 1.0,‖ Technical Report 95-23, Dept. of
Computer Science, Univ. of Troms ّand Cornell Univ., Troms,ّ Norway, June 1995.
25. [Joh 04]: Dag johansen, ―Mobile Agents: Right Concept, Wrong Approach‖,
Proceedings of the 2004 IEEE International Conference on Mobile Data Management
(MDM’04)
26. [Joh 94]: D. Johansen & G.Hatvigsen, « Architectural issues in StormCast system‖,
Proceedings of Dagstuhl Seminar on Distribuetd Systems. Number 983, in lecture
notes on computer science, page 1, 16, Dagstuhl, Germany, 1994. Springer Verlag.
Références……………………………………………………………………………… Dr : L. Kahloul
56
27. [Jul + 88]: E. Jul, H. Levy, N. Hutchinson, and A. Black, ―Fine-Grained Mobility in
the Emerald System,‖ ACM Trans. Computer Systems, vol. 6, no. 2, pp. 109–133, Feb.
1988.
28. [Han 90]: W.J.Hansen.‖ Enhancing Documents with embede programs: How Ness
extedns insets in the Andrew tollkit‖. In Proceeding if IEEE 1990 International
Cnference on Computer Languages, pages 23-32, New Orleans, March 1990. IEEE
Computer society Press (Ls Alatimos, CA)
29. [Kna 95]: Frederick C. Knabe. ―Language Support for Mobile Agents”. PhD thesis,
School of Computer Science, Carnegie Mellon University, Pittsburgh, Pennsylvania
15213, December 1995. Technical report CMU-CS-95-223.
30. [Kot+99] : David Kotz and Robert S. Gray, ― Mobile Agents and the Future of the
Internet‖. Department of Computer Science/ Thayer School of Engineering Dartmouth
College. In ACM Operating Systems Review, August 1999, pp. 7-13.
31. [Lan 98]: Danny B. Lange. ―Mobile Objects and Mobile Agents: The Future of
Distributed Computing?‖. E. Jul (Ed.): ECOOP’98, LNCS 1445, pp.1 -12, 1998.
Springer-Verlag Berlin Heidelberg 1998. This paper is based on a chapter of a book by
Lange and Oshima entitled Programming and Deploying Java™ Mobile Agents with
Aglets™, Addison-Wesley, 1998. (ISBN: 0-201-32582-9).
32. [Lan+ 97a] : Danny B. Lange and Yariv Aridor. ―Agent Transfer Protocol – ATP/0.1‖.
IBM Corporation, 19 mars 1997.
33. [Lan+ 97b]: Danny B. Lange and Mitsuru Oshima. ―Programming Mobile Agent in
Java, With the Java Aglet API ‖. IBM Research, 1997. (Alpha5) Draft. IBM
Corporation, 10 septembre 1997.
34. [Lea + 93]: R. Lea, C. Jacquemont, and E. Pillevesse, ―COOL: System Support for
Distributed Object-Oriented Programming,‖ Comm. ACM, vol. 36, no. 9, pp. 37–46,
Nov. 1993.
35. [Ler 97]: X. Leroy. Objective Caml. http://pauillac.inria.fr/caml/, 1997
36. [Laz+81] :Edward D.Lazowska, Henry M.levy, Guy T. Almes, Michael J.Fisher,
Robert J.Flower, and Stepher C.Vestal. « The architecture of Eden Syetm » In
Proceeding of the 8th
Symposium on Operating Systems Principles, pages 148-159,
December 1981.
37. [Lan +99]: Danny B. Lange and Mitsuru Oshima. ―Seven good reasons for
mobile agents―. Communications of the ACM, 42(3): 88-89, March 1999.
38. [Li+]: W.Li, D.G.Messerschmitt, ―Itinerative Computing Using Java‖,
http://ptolemy.eecs.berkeley.edu/dgm/javatools/java-to-go.
39. [Luc 96] : Lucent technolies. The inferno home page : http://inferno.bell-
labs.com/inferno/index.html, 1996.
Références……………………………………………………………………………… Dr : L. Kahloul
57
40. [Mil+98] : D. Milojicic, M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman, K.
Kosaka, D. Lange, K. Ono, M. Os-hima, C. Tham, S. Virdhagriswaran, and J. White.
« MASIF: The OMG Mobile Agent System Interoperability Facility‖. In Proceedings
of the Second International Workshop on Mobile Agents, volume 1477 of Lecture
Notes in Computer Science, pages 50{67, Stuttgart, Germany, September 1998.
Springer-Verlag.
41. [Nil+ 03] : Nils P.Sudmann & Dag Johansen, « softawre deployment using mobile
agents », may 6th
2003.???
42. [Nob +95]: Brian B.Noble, Morgan Price, and M.Satyanarayanan.‖Aprogramming
interface for application-aware adaptation in mobile computing‖. Computing Systems,
8(4):345-363, Fall 1995.
43. [Nog +96]: Saurab Nog, Sumit Chawla, and David Kotz.‖An RPC mechanism for
transportable agent‖. Technical Report PCS-TR96-280, Dept. of Computer Science,
Dartmouth College, March 1996.
44. [Nut 94] : M. Nuttall, ―Survey of Systems Providing Process or Object Migration,‖
Technical Report Doc 94/10, Dept. of Computing, Imperial College, May 1994.
45. [Pei 97]: H. Peine and T. Stolpmann, ―The Architecture of the Ara Platform for
Mobile Agents,‖ Rothermel and Popescu-Zeletin [72], pp. 50–61. First International
Workshop on Mobile Agents, MA’97, April 7-8th 1997, Berlin, Germany. Lecture
Notes in Computer Science Nr. 1219, Springer Verlag 1997. ISBN: 3-540-62803-7
46. [Pow+83] : Michael L.Powell and Barion P.Miller. « process migration in
DEMOS/MP ». In Proceeding of the Ninth ACM Symposium on Operating Systems
Principles, pages 110-119, ACM/SIGOPS, October 1983.
47. [Ras+81]: Richard F.Rashid and George G.Roberison. « Accent : A communication
oriented network operating system kernel ». In Proceeding of th 8 Symposium on
Operating System Principles, pages 64-75, December 1981.
48. [Roz + 88]: M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont,
F. Herrmann, C. Kaiser, P. Leonard, S. Langlois, and W. Neuhauser, ―Chorus
Distributed Operating Systems,‖ Computing Systems, vol. 1, pp. 305–379, Oct. 1988.
49. [Sta+90]: James W. Stamos and David K. Gifford. ―Remote evaluation‖. ACM
Transactions on Programming Languages and Systems, 12(4):537–565, October
1990.
50. [Str+96]: M. Straβer, J. Baumann, and F. Hohl, ―Mole—A Java Based Mobile Agent
System,‖ Special issue Object-Oriented Programming: Workshop Reader of the 10th
European Conf. Object-Oriented Programming ECOOP’96, M. Mühlaüser, ed., pp.
327–334, July 1996, dpunkt.
51. [The+85] : Marvin M.Theimer, Keith A.Lantz and David R.Cheriton. « Preemptable
remote execution facilities for V-system ». In proceedings of the 10th
ACM
Références……………………………………………………………………………… Dr : L. Kahloul
58
Symposium on Operating Systems Principles, pages 2-12.ACM/SIGOPS, December
1985.
52. [Thi 91]: G. Thiel, ―Locus Operating System, A Transparent System‖, Computer
Comm., vol. 14, no. 6, pp. 336–346, 1991.
53. [Tho 97]: Tommy Thorn, ―Programming languages for mobile code” , This is a
revised and reduced version of a paper published in the ACM Computing Surveys, 29(3):213{239, Sept., 1997.
54. [Tho+95]: Bent Thomsen, Lone Leth, Frederick Knabe, and Pierre-Yves Chevalier.‖
Mobile Agents‖. ECRC external report, European Computer-Industry Research
Center, 1995.
55. [Tsc 94]: C. F. Tschuden. ―An introduction to the M0 Messenger language―.
University of Geneva, Switzerland, 1994.
56. [Tsc 95] : C. Tschudin, ―OO-Agents and Messengers‖, ECOOP’95 Workshop W10 on
Objects and Agents, Aug. 1995.
57. [Vig+04]: G. Vigna. ― Mobile agents: Ten reasons for failure‖. In Proceedings of
MDM Berkeley, CA, pages 298–299, January 2004.
58. [Web 1] : available at : ftp://ftp.fv.com/pub/code/other/safe-tcl.tar.Z.
59. [Web 2] : available at : http://www.meitca.com/hsl/projects/concordia/.
60. [Web 3]: available at : http://www.objectspace.com/voyager/.
61. [Whi 94a]: J.E.White, ―Telescript technology: the foundation for the electronic
market-place‖, General magic Inc, Mountain View, CA, 1994.
62. [Whi 94b]: J.E.White. ―Mobile Agent Make a Network an Open Platform for Third-
Party Devlopers‖. IEEE Coputer, 27(11): 89-90, November 1994.