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 noeuds.
 Une Disponibilité des objets requis chez les noeuds demandants ces objets.
 Une obtention (par téléchargement) de services logiciels disponibles sur un certain noeud.
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 noeuds 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 noeuds 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 noeud source. Il peut retourner avec ses résultats, ultérieurement, lors de la connexion de son noeud.
 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 noeud 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 (noeuds) 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
Network operating system
network operating system
True distibuted system
host
host
host
network operating system
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 noeud 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 noeuds (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 noeuds du réseau. Des objets actifs ( accompagné par des threads) peuvent faire des appels à des opérations d’autres objets sur des noeuds 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 noeud de l’objet invoqué.
 Ou bien seulement la partie appelante du processus migre vers le noeud 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 noeud 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
Remote evaluation
A+know-how
Rssources, B
A
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 noeud 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, DFS2 et accisGMBH3), 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

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) |EL ( 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’ | JP // 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 : JP. 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: (JP├ Jrv,… )  (JP├ Prv,…) 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:

Jrv = (ready(printer)|job(file))rv = ready(laser)| job(1) et Prv = (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 || ├aP 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 | nN} 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 : AnA une fonction. Un -algèbre est l’ensemble A avec la fonction fA pour chaque f dans n, où nN.
 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 ( tT({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 .

Support ssm vsm_vers_finale

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Support ssm vsm_vers_finale

Ähnlich wie Support ssm vsm_vers_finale (20)

Support ssm vsm_vers_finale