Support ssm vsm_vers_finale

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


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.


Chapitre 1 :

Mobilité en Informatique

Chapitre 1 : Mobilité en informatique Dr : L. Kahloul


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]



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



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.



[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.



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).



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



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.



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]



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.



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).



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 ).



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.



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).



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.



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.



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.



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).



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,



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

http://www.ivs.tu-berlin.de/

http://www.dfs.de/

http://www.accis.de/



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.



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é.


Chapitre 2 :

Formalismes pour les Systèmes

Mobiles

Chapitre 2: Formalismes pour les systèmes mobiles Dr : L. Kahloul


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 :



• 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).



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Ā{},



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 :



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.



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



Exercice 8 : Soit les figures ci-dessous :

1) Pour chacun de ces LTS, trouver un programme CCS.



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



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é



- 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 :



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



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



| 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’)



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:



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 :



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.



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



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 .



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]



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.



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



…

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



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 ,



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]:



<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é.


Conclusion Générale

Conclusion générale Dr : L. Kahloul


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.


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

http://www.colusa.com/


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.

ftp://ftp.cs.washington.edu/

ftp://ftp.cs.dartmouth.edu/TR/TR96-285.pdf


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.

http://pauillac.inria.fr/caml/

http://inferno.bell-labs.com/inferno/index.html

http://inferno.bell-labs.com/inferno/index.html


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


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.

ftp://ftp.fv.com/pub/code/other/safe-tcl.tar.Z

http://www.meitca.com/hsl/projects/concordia/

http://www.objectspace.com/voyager/