Middleware et informatique mobile - Julien MATHEVET

DEA RACOR
UTT
RB03
Middleware et informatique mobile
Alexandre BOISSY
Julien MATHEVET
Sommaire
INTRODUCTION
3
1.
4
LES TECHNOLOGIES SANS FIL ACTUELLEMENT DISPONIBLES
1.1.
1.2.
1.2.1.
1.2.2.
1.3.
1.3.1.
1.3.2.
1.4.
1.4.1.
1.4.2.
1.4.3.
2.
INTERET DES SANS FIL :
PRESENTATION TECHNIQUE
SUPPORTS PHYSIQUES DES RESEAUX SANS FIL
LIAISONS RADIO : TECHNOLOGIES DSSS ET FHSS
IES ARCHITECTURES
LE MODE CELLULE
LE MODE AD HOC
LES TECHNOLOGIES DE RESEAUX SANS-FIL
HIPERLAN 2
IEEE 802.11
LES AUTRES AXES DE RECHERCHES
PROBLEMATIQUE
4
5
5
6
7
7
7
8
8
9
9
10
2.1. DIFFERENCES PHYSIQUES :
2.2. LES SYSTEMES DISTRIBUES
2.2.1. LES SYSTEMES DISTRIBUES FIXES :
2.2.2. SYSTEMES MOBILES:
10
10
10
11
3.
13
LES BESOINS DES MIDDLEWARES :
3.1.1.
3.1.2.
4.
LES MIDDLEWARES POUR LES RESEAUX FIXES :
4.1.
4.2.
4.3.
5.
LES FIXES :
LES MOBILES :
13
14
14
LES MIDDLEWARES ORIENTES OBJETS ET COMPOSANTS :
LES MIDDLEWARES ORIENTES MESSAGES :
LES MIDDLEWARES ORIENTES TRANSACTIONS :
14
14
15
VERS DES MIDDLEWARES ADAPTES AUX MOBILES
15
5.1.
5.1.1.
5.1.2.
5.1.3.
5.2.
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.3.
5.4.
5.4.1.
5.4.2.
5.4.3.
REFLECTIVE MIDDLEWARE SOLUTIONS :
OPENCORBA :
NEXT GENERATION MIDDLEWARE :
GLOBE
TUPLE-SPACE BASED SYSTEMS
LIME
TSPACES
JAVASPACES
LIMITATIONS DES MIDDLEWARE A BASE D’ESPACE DE TUPLES
CONTEXT AWARE MIDDLEWARE
LES AUTRE SOLUTIONS INTERESSANTS
CODA ET ODYSSEY
BAYOU
JINI
15
15
15
16
16
16
17
17
17
18
19
19
19
20
CONCLUSION
21
BIBLIOGRAPHIE
22
Introduction
Les solutions sans fils, tel que les ordinateurs portables, les téléphones mobiles et autres PDA
sont de plus en plus performantes et compactes. L’offre dans ce domaine est florissante et l’on
peut prédire que le volume des ventes suivra car les appareils mobiles permettent aux
utilisateurs d’accéder à l’information à tout moment et en tout lieu bénéficiant d’un accès
réseau. Cependant les terminaux mobiles apportent un lot de nouvelles problématiques aux
développeurs d’applications et de services car les ressources dont disposent ces appareils sont
souvent bien plus restreintes que celles offertes par un poste fixe (mémoire, puissance de
calcul, bande passante, …).
Les middleware ont fait leurs preuves dans le domaine des postes fixes en offrant une couche
d’abstraction entre les architectures matérielles et les applications. Cette abstraction est à plus
forte raison nécessaire dans un contexte mobile où l’hétérogénéité des terminaux est encore
plus marquée. Mais les middlewares actuels sont-ils adaptés aux mobiles ? Sont-ils
adaptables ? Doit-on créer une nouvelle génération de middleware ? Si oui, quelles
caractéristiques indispensables doit-elle comporter ? Nous tenterons de répondre à toutes ces
questions au fil de ce document qui se veut la synthèse d’un ensemble d’articles sur le sujet.
Dans un premier temps, nous effectuerons un bref tour d’horizon des technologies sans fil
actuellement disponibles sur le marché puis nous verrons en détail quelles sont les
problématiques liées à la mobilité. Nous terminerons sur la présentation les différents types de
middlewares existants et comment certaines de leur fonctionnalités peuvent être appliquées
dans le cas de l’informatique mobile.
1. Les technologies sans fil actuellement disponibles
Les technologies sans fil, qui sont relativement récentes, sont devenues maintenant
performantes grâce aux avancées technologiques, notamment en électronique et en traitement
du signal. Les principales technologies sans fil, qui existent sur le marché actuellement sont :
•
•
Les WPAN (Wireless Personal Area Network) : Bluetooth (Ericson), HomeRF.
Les WLAN (Wireless Local Area Networks) : IEEE 802.11 (US) et Hiperlan
(Europe).
Les technologies cellulaires (GSM, GPRS, UMTS).
Les technologies Satellite (Vsat qui est bidirectionnel, mais aussi DVB pour la
diffusion Vidéo)
•
•
Au niveau des opérateurs, le premier réseau commercial analogique sans fil a vu le jour en
1982 à Chicago. En 1986, France Télécom lance Radiocom 2000 en France. Les premiers
réseaux GSM (numériques) apparaissent en France en 1992 et remportent aujourd’hui le
succès que nous connaissons. Que ce soit au niveau des opérateurs (GSM, GPRS, UMTS), au
niveau local (WLAN) ou au niveau domestique (WPAN), de nombreuses applications
intéressantes sont envisagées.
Les réseaux sans fil se développent très rapidement et devraient représenter un marché
énorme en ce début de XXIème siècle. Les prix jusque là inaccessible deviennent de plus en
plus abordables, les performances et les débits augmentent, les réseaux domestiques et la
population de travailleurs mobiles également. Le marché des réseaux sans fil est donc en plein
essor et certaines analyses estiment ce marché à 2 milliards de dollars pour 2002. Ericsson a
avancé le chiffre de 100 millions d’équipements électroniques dotés de la puce Bluetooth d’ici
à 2003. Les réseaux sans fil représentent donc un enjeu important, surtout au niveau financier
: ils permettent d’éviter d’investir dans un câblage coûteux et qui peut s’avérer rapidement
obsolète ou inutile en cas de déménagement de locaux.
1.1.
Intérêt des sans fil :
Les réseaux sans fil peuvent exister en extrémité d’un réseau filaire classique comme Internet
et doivent donc pouvoir communiquer avec des machines fixes d’un réseau filaire.
L’intérêt est d’assurer une connexion au réseau tout en permettant la mobilité de l’utilisateur.
On peut envisager que les terminaux supporterons l’ensemble des protocoles. Ils pourront
passer de l'
un à l'
autre sans rupture de la connexion en fonction de là où on se trouve : GPRS,
UMTS, WLAN, BlueTooth. Par exemple lorsque l'
on arrive dans un lieu public pour une
conférence, on passe sur un WLAN plus rapide que l'
UMTS. Demain, un WLAN permettra
de bénéficier du réseau à l'
intérieur du TGV. Le software gérera le choix du protocole à un
moment donné : plus de 80% de la R&D dans l'
Internet se fait sur le logiciel et non le
matériel, selon Gilles Kahn, directeur scientifique de l'
INRIA.
De plus, le câblage n’est plus nécessaire, ce qui représente un avantage certain dans de
nombreux cas :
-
Mise en place d’un réseau dans un bâtiment classé « monument historique »
-
Mise en place d’un réseau de courte durée (chantiers, expositions, locaux loués,
formations)
-
Confort d’utilisation : tous les participants d’une réunion sont automatiquement
interconnectés
-
Gain en coût pour la mise en place d’un réseau dans tout bâtiment non préalablement
câblé.
De nombreuses autres applications sont envisagées. Dans les hôpitaux, les transmissions sans
fil sont déjà utilisées pour accéder aux informations enregistrées sur chaque patient pendant
les visites. Des besoins similaires ont été mis en avant par le personnel des aéroports, des
chantiers de constructions et autres.
Selon les constructeurs, ces technologies devraient s'
étendre dans les prochaines années pour
équiper tous les objets de notre vie quotidienne : téléviseurs, chaînes hi-fi, réfrigérateurs,
voitures, etc. Les voitures ouvriront leurs portes à la seule approche de leur propriétaire ou
communiqueront directement avec la pompe de la station-service, le réfrigérateur fera luimême sa commande par Internet, les PDA se synchroniseront automatiquement avec les PC et
s’échangeront fichiers et e-mails. En arrivant chez vous, la porte d’entrée se déverrouillera
automatiquement, le système d’alarme se mettra en veille et les lumières s'
allumeront.
Le majeur problème est la compatibilité entre ces différents protocoles. Cela est du aux
différents organismes de normalisation et les différents constructeurs, qui tentent chacun
d’imposer leur technique. Les débits de transmission vont de 1 à 54 Mbps.
1.2.
Présentation technique
1.2.1.
Supports physiques des réseaux sans fil
Les liaisons infrarouges
Les liaisons infrarouges sont très
utilisées pour les communications
courtes distances où les éléments
sont en vue directe. Mais les
infrarouges sont très sensibles aux
perturbations. Si les faisceaux
sont directifs, le débit peut être
élevé mais rien ne doit passer
entre les deux éléments qui
communiquent. Les faisceaux
diffusants, eux supportent mieux
les interférences mais les portées
et les débits sont moins élevés.
L’association IrDA (Infrared Data
Association), créé en 1994, gère
les standards relatifs à la technologie infrarouge. La couche physique (Physical IrDA Sata
Signaling) définit typiquement les distances entre les éléments à 2 mètres. Des débits de 4
Mbps peuvent être atteints. Des versions courte distance permettent d’économiser l’énergie et
de dialoguer à 30 cm de distance, ce qui est suffisant dans le cas de périphériques de PC.
Comme pour tout protocole de communication, le niveau 2 est également défini avec l’IrDA
Link Access Protocol (IrLAP) qui gère les connexions entre équipements. L’IrDA Link
Management Protocol (IrLMP) gère le multiplexage des informations sur plusieurs canaux et
offre un certain nombre de services.
1.2.2.
Liaisons radio : Technologies DSSS et FHSS
Les réseaux sans fil utilisent les technologies DSSS et FHSS. La technologie DSSS envoie en
simultanée l’information sur plusieurs canaux parallèles, ce qui donne un taux d’erreur plus
faible (donc un débit plus élevé) et une immunité aux perturbations en bande étroite. La
technologie FHSS, elle, est basée sur le saut de fréquence, ce qui permet d’économiser de la
bande passante.
Mais il existe un cadre réglementaire des fréquences. Le choix des fréquences utilisées posent
un problème de compatibilité entre les différents pays. En effet, selon le pays, ces fréquences
peuvent être réservées pour des utilisations militaires ou des services de secours (SAMU,
pompiers) qui ne peuvent souffrir d’interférences.
Une norme a été élaborée au niveau européen pour des équipements fonctionnant dans la
bande de fréquences 2,4 GHz : l'
ETS 300 328. Cette norme d'
application volontaire (chaque
Etat peut décider ou non de la transposer, pour tout ou partie, dans son droit national)
constitue la base d'
une recommandation des administrations européennes des postes et
télécommunications (CEPT), tendant à harmoniser le régime d'
autorisation des équipements
concernés afin de favoriser leur développement en Europe.
En France, la bande de fréquences concernée (plus précisément la bande de fréquences 2446,5
MHz - 2483,5 MHz), est utilisée par le Ministère de la défense, qui a déployé récemment de
nouveaux équipements, ce qui ne permet pas d'
ouvrir la totalité de la bande de fréquences aux
équipements sans fils.
1.3.
Ies architectures
Les WLAN peuvent fonctionner de deux façon différentes : en mode cellule ou en mode adhoc.
1.3.1.
Le mode cellule
Le mode infrastructure fait appel a des
bornes de concentration appelées, Points
d’Accès, qui gèrent l’ensemble des
communications dans une même zone
géographique, comme dans les réseaux
GSM. Les bornes sont connectées entre
elles par une liaison ou un réseau filaire
ou hertzien.
Les terminaux peuvent se déplacer au
sein de la cellule et garder une liaison
directe avec le point d’accès, ou changer
de cellule, ce qui s’appelle le roaming.
1.3.2.
Le mode ad hoc
Un réseau Ad Hoc est un réseau où il n'
y a pas d'
infrastructure fixe. Le signal est transmis par
l'
intermédiaire des mobiles présents et routé dynamiquement.
L’étude des réseaux ad hoc constitue un axe de recherche important. Un réseau ad hoc est un
réseau sans fil auto-configurable. Lorsque deux machines mobiles ou plus se retrouvent dans
le même secteur géographique, elles doivent se reconnaître pour pouvoir s’échanger des
données. Le réseau doit se configurer automatiquement pour faire la liaison entre ces
machines. Chaque nœud du réseau peut potentiellement échanger des informations avec
chaque autre nœud.
Dans le mode de fonctionnement le plus simple, et généralement le seul implémenté dans les
protocoles actuels, on considère que les nœuds peuvent échanger des données uniquement
lorsqu’elles sont à portée de réception l’une par rapport à l’autre. Dans un mode de
fonctionnement idéal, lorsque deux machines ne peuvent se joindre directement, chaque nœud
du réseau peut servir de routeur. Les réseaux ad-hoc posent alors implicitement des problèmes
de routage entre les machines :
Dans un premier temps, la machine B est dans le rayon de diffusion de la machine A. La
machine A et la machine B veulent échanger des informations. La machine B est mobile. Il
faut, lorsque la machine B sort du rayon de diffusion de A, que la machine C serve de routeur
pour conserver la liaison entre A et B.
Le routage se fait donc directement entre les différents mobiles sans nécessiter un ensemble
de bases fixes. Lorsque l'
on veut envoyer des paquets d'
un point à un autre, on "inonde" de
proche en proche les différents mobiles jusqu'
à identifier une route, puis on utilise le chemin
ainsi crée pour "router" les données de proche en proche (en fait on définit une route de la
destination à la source et on utilise la route inverse)
Bluetooth ne peut pas facilement devenir un réseau Ad-Hoc (sans base blueTooth) car il
utilise une technique de modulation par saut de fréquence (contrairement aux WLAN qui
utilisent l'
étalement de spectre) et une base centralisée à laquelle se relient tous les appareils
plutôt qu'
un routage interne
1.4.
Les technologies de réseaux sans-fil
Plusieurs produits sont déjà commercialisés mais ils sont incompatibles entre eux par un
manque de normalisation. Deux grandes orientations se détachent dans le domaine :
HiperLAN et IEEE 802.11.
1.4.1.
HiperLAN 2
Le nom est l’abréviation de High performance radio LAN 2. Il est soutenu par l’H2GF
(Hyperlan 2 Global Forum) fondé en 1999 par Bosch, Dell, Ericsson, Nokia, Telia et Texas
Instrument. Ils ont été rejoints un an après par d’autres industriels, tels Canon, Motorola ou
encore Samsung.
L’hyperLAN 2 accepte le mode cellule, et ad hoc (dans une version simple) avec une
communication radio. Les vitesses de transfert théoriques sont de 54 Mbps. Ceci grâce à la
modulation OFDM : Orthogonal Frequency Digital Multiplexing. Il est orienté connexion
entre les MT (terminaux mobiles) et l’AP (point d’accès). Les communications point à point
sont bidirectionnelles et les communications point à multipoint sont unidirectionnelles. Un
canal de broadcast permet de joindre tous les MT en même temps. Du fait que les
communications sont en mode connectés, la qualité de service est facilement implémentable.
Les canaux radio utilisés sont automatiquement choisis par le point d’accès en fonction des
interférences dans l’environnement et des fréquences utilisées par les autres cellules radio qui
l’entourent. Le MT reçoit ces données du point d’accès le mieux situé, c’est-à-dire dont le
signal radio est le plus intelligible. Le changement de cellule (roaming) se fait
automatiquement.
1.4.2.
IEEE 802.11
Ce standard de WLAN a été défini dans sa version 1 par le comité RES-10 du projet BRAN
(Broadband Radio Access Networks) de l’ETSI le 16 juillet 1998.
Les communications peuvent se faire soit de station à station, soit par une borne de
concentration. Une station ne peut par contre pas relayer les paquets vers une autre station
terminale. Les débits sont de 1 ou 2 Mbps selon qu’on utilise le codage FHSS (Frequency
Hopping Spread Spectrum) qui utilise un saut de fréquence ou le codage DSSS (Direct
Sequence Sequence Spread Spectrum) qui code de façon continue. L’utilisation de
l’infrarouge est également possible.
La technique d’accès est plus compliquée, il s’agit du CSMA/CA (Collision Avoidance).
Pour éviter les collisions, plusieurs temporisateurs propres à chaque station sont attribués ce
qui limite la probabilité d’avoir deux stations émettant simultanément.
1.4.3.
Les autres axes de recherches
Il y a les petits groupes comme SWAP ou WAP, qui ont connu un échec en france. Cela
changera peut-être avec l’arrivée de l’UMTS.
Pour Internet, Mobile IP a été développé pour permettre de délivrer les paquets pendant que le
mobile n’est pas sur sa base. La prochaine génération du protocole IP (IPv6) offrira un
meilleur support pour délivrer de façon transparente les paquets vers un mobile qui n’est pas
sur son propre réseau. Ces efforts ont été faits notamment pour répondre aux besoins des
réseaux ad hoc dont la topologie est très dynamique ce qui rend inutilisables les stratégies de
routages classiques comme le vecteur de distance ou l’état de la ligne. Les services multi-casts
reçoivent aussi beaucoup d’attention.
2. Problématique
2.1.
Différences physiques :
Pour comprendre les différences entre fixes et mobiles, nous avons utilisé trois concepts de
distinction. : le type d’appareil, la connectivité réseau et le contexte d’exécution.
Concernant le type d’appareil, on en recense deux : fixe ou mobile. Les appareils fixes vont
du PC aux Calculateurs. Ils disposent d’importantes capacités de mémoire et de puissance de
calcul contrairement aux mobiles, qui sont en plus limités par la faible autonomie de leurs
batteries et la taille de leurs écrans. De plus, les appareils mobiles de part la diversité et la
grande vitesse d’évolution de leurs caractéristiques renforcent la problématique de
l’hétérogénéité des terminaux.
Les appareils fixes bénéficient souvent d’une connectivité réseau permanente avec un débit
moyen élevé et un niveau de fiabilité important. Les déconnexions sont rares et durent
généralement peu longtemps. Dans un contexte mobile, ces déconnexions sont non seulement
fréquentes mais elles sont surtout imprévisibles. De plus, la qualité de service offerte par les
différentes technologies sans fil est très variable. Ainsi, Les Wave LAN fournissent une
bande passante raisonnable à condition que le mobile soit à une centaine de mètre de la station
de base (serveur) et que la zone couverte soit peu chargée. La bande passante est partagée
entre les émetteurs (mobiles). Par contre, le GSM a une large couverture mais il fournit une
faible bande passante avec un débit maximum théorique de 9,6 Kbps contre 10 Mbs pour
WLAN.
2.2.
Les systèmes distribués
Nous venons de voir les problèmes liés au terminal, mais que ce passe-t-il au niveau de leurs
réseaux. Nous allons donc présenter les grandes fonctionnalités qu’offre un système fixe. Puis
les comparer aux deux grands types d’infrastructure.
2.2.1.
Les systèmes distribués fixes :
Ces systèmes ont un ensemble de postes fixes, Il sont donc connectés continuellement au
réseau avec une large bande passante et des liens stables. On peut considérer que leur
environnement est statique.
Les fonctionnalités qu’ils permettent d’assurer sont:
•
Echelonnage. C’est la capacité à s’adapter à la charge du réseau. Cette charge peut être
mesurée avec le nombre maximum d’utilisateurs concurrents, le nombre de transaction
exécuté dans un temps donné, le volume de donnée, etc.
•
Ouverture. C’est la possibilité d’étendre et de modifier facilement le système tout en
préservant les précédents investissements.
•
Hétérogénéité : les composants peuvent être écrits dans plusieurs langage, s’exécuter
sur plusieurs Os et sur différent support physique.
•
Tolérance aux fautes. C’est la capacité à résoudre les erreurs sans arrêter l’exécution
de l’ensemble du système.
•
Partage des ressources (matérielles et logicielles). Il est effectué avec un contrôle
d’accès pour l’ensemble des utilisateurs.
2.2.2.
Systèmes Mobiles:
Les ondes radios sont très sensibles aux différentes perturbations, ce qui entraîne des liens de
qualité variable et complexifie l’échelonnage. Pour les réseaux de cellules, on peut se reposer
sur une infrastructure fixe chargée de connecter tous les mobiles présents dans sa zone. La
gestion de la qualité de service se fait en fonction du nombre de personnes connectées. Pour
les réseaux ad-hoc, ces problèmes sont résolus par les techniques d’accès au canal (cf.
présentation technique) qui prennent en compte la qualité des transmissions.
La communication est asymétrique car le rayon (la puissance) d’émission peut varier d’un
mobile à l’autre. Ce phénomène est renforcé par les problèmes de batterie (l’émission d’un
signal à une forte consommation d’énergie).
Il existe différents systèmes pour les mobiles, comme nous l’avons vu (GSM, WLAN, etc), ce
qui pose des problèmes d’hétérogénéité. En effet, si un mobile quitte une cellule (il n’est plus
à la portée d’un émetteur) et qu’il ne trouve pas une cellule du même type de réseau, il ne plus
se connecter. La solution actuelle est de fournir plusieurs types de connexion au mobile et de
choisir la plus appropriée à l’environnement. Mais cette solution est peu utilisée car on doit
connaître à l’avance les différents types de réseau que l’on va traverser. De plus on
augmenterait la taille du mobile.
La tolérance aux fautes est limitée par l’environnement (nombre important de déconnexions
possibles et la faible qualité des liens) et une faible implémentation de détection de collision.
En effet, dans Ethernet, la détection des collisions se fait par l’écoute du support lorsque la
station transmet. Ce type de fonctionnement n’est pas possible dans un environnement sans
fils pour 2 raisons :
-
Implémenter un mécanisme de détection de collision demanderait l’implémentation
d’une liaison radio full duplex.
-
Toutes les stations ne s’entendent pas forcement entre elles car chaque station à une
portée d’écoute limitée, et le fait que la station voulant transmettre teste si le support
est libre, ne veut pas forcément dire que le support est libre autour du récepteur.
Ainsi, le problème revient à savoir s’il existe des interférences dans la zone du récepteur.
C’est le problème de la « station cachée ».
Exemple : La station A veut transmettre des données à la
station B. Si la station C écoute le support, elle n’entend pas
A car il est hors de portée de C : elle peut conclure faussement
qu’aucune transmission n’est en cours dans son entourage. Si
C commence à transmettre, les interférences avec les trames de A auront lieu dans l’entourage
de B.
Le partage des ressources constitue aussi un problème étant donné que l’on peut se connecter
partout. La sécurité est un point important à ne pas négliger, surtout pour les réseaux sans fil.
En effet, ils offrent de nouvelles failles aux pirates. De part la nature immatérielle du support
physique, l’écoute clandestine sur un réseau sans fil est facile. Il faut donc protéger l’accès
aux ressources sans fil et aux informations qui circulent dans les trames.
Les systèmes mobiles sont généralement équipés de processeurs moins puissants que les
machines fixes, et ne peuvent se permettre d’effectuer de longs calculs demandés par les
systèmes de cryptographie. Les systèmes sans fil sont sensibles à deux attaques principales
supplémentaires par rapport aux réseaux classiques. Ces attaques portent atteinte à la
disponibilité du réseau et des nœuds :
-
Le blocage radio : pour rendre le réseau inutilisable, le pirate peut bloquer les
fréquences radio utilisées par le système.
-
Epuisement de la batterie : l’attaquant peut interagir avec le nœud dans le seul but de
lui faire consommer de la batterie. Les applications doivent donc restreindre leur accès
pour éviter ce genre d’attaque.
3. Les besoins des middlewares :
La mobilité nécessite de développer de nouveaux algorithmes et de nouveaux middlewares
pour fournir les fonctionnalités des systèmes distribués dans un environnement mobile.
Ils permettent notamment aux développeurs de développer une architecture logicielle tout en
gardant un haut niveau d’abstraction vis à vis des couches matérielles. Les couches protocoles
réseaux (1-4) sont donc cachées pour le programmeur, ils n’ont plus à s’en soucier. Ainsi Il
évite les problèmes dus à la distribution et au réseau. Cela permet aussi d’augmenter la
rapidité de réalisation des applications, de la maintenances, de l’ajout de nouvelles
fonctionnalités et de nouveaux matériels.
En considérant les problèmes induits par les mobiles peut on continuer à ignorer les couches
inférieures ? Nous allons essayer de le découvrir.
Pour comprendre les différences que cela impliquent, nous allons classifier les middlewares,
et les comparer. Nous restreindrons notre études à la mobilité physique, qui est déjà un vaste
problème.
Pour classifier les middlewares, nous retiendrons les critères suivants :
•
la charge induite par le middleware :
o Lourde : elle nécessitera beaucoup de puissance de calcul et de mémoire.
o Légère : le middleware pourra s’exécuter sur des terminaux disposant de peu
de ressources.
•
le paradigme de communication :
o Synchrone : Cela suppose que les entités ne pourront communiquer entre elles
que si elles sont simultanément connectées au réseau.
o Asynchrone : Dans ce cas, il faudra mettre en place des mécanismes de
synchronisation pour assurer la consistance des données.
• la représentation du contexte :
Le contexte inclut les ressources internes et externes (bande passante, qualité de la
connexion, la localisation) et conditionnement la performance de l’application.
o Transparence : Les middlewares classiques prennent des décisions à la place
de l’application.
o Conscient. Dans un contexte mobile, il peut être intéressant de faire remonter
une partie des informations des couches basses jusqu’à l’application pour
signaler toute modification du contexte d’exécution pour que l’application
puisse s’y adapter.
3.1.1.
Les fixes :
Les postes fixes disposant de meilleure ressources, ils peuvent supporter des traitements plus
lourds. Cela permet d’obtenir un confort important au niveau de l’application au prix d’un
surcoût de charge. En effet, la tolérance aux fautes et la sécurité sont des opérations
gourmandes en ressources.
La communication est synchrone car les liens sont permanents, stables et disposent d’une
large bande passante.
Le contexte est quasi statique, le middleware peut donc fournir aux applications une
représentation transparente. Cela lui permet d’avoir l’ensemble des connaissances et des
besoins, grâce auxquels il peut appliquer des stratégies ou politiques pour fournir la meilleure
qualité de service. Les applications n’ont pas besoins de se soucier des problèmes dus à
l’environnement, comme la tolérance aux fautes, la sécurité, etc.
3.1.2.
Les mobiles :
Les mobiles disposent de ressources peu performantes (faible mémoire, lenteur du processeur,
limitation de la batterie), Ils ne peuvent donc pas exécuter des services qui induisent une
lourde charge. Il faut trouver l’équilibre entre une charge faible et la nécessité d’avoir des
fonctionnalités de bases (ex : la tolérance aux fautes).
Les mobiles se connectent au réseau pour une courte durée (volontaire ou non), on ne peut
donc pas envisager des communications synchrones. Il est probable qu’un mobile demande un
service et se déconnecte. Lors de sa reconnexion, il demandera les résultats de sa précédente
requête. Il peut être intéressant de faire la différence entre déconnexion intentionnelle et non
intentionnelle. Dans le premier cas, on peut s’assurer que le système conserve sa consistance
avant la déconnexion.
Le contexte mobile étant très dynamique, le middleware doit interagir avec l’application pour
l’informer et lui permettre de s’adapter à ces modifications. Le but des middleware en
environnement mobile est de cacher les détails du contexte non pertinents pour alléger le
système mais il doit conserver la possibilité d’informer l’application sur les fluctuations de la
qualité de service.
4. Les middlewares pour les réseaux fixes :
4.1.
Les middlewares orientés objets et composants :
Les objets distribués peuvent communiquer entre eux et appeler une méthode d’un serveur
d’objet qui réside sur un autre poste. Ce type de middleware s’est développé à partir des
Remote Procédure Call. Les produits de cette catégorie comprennent les implémentations de
CORBA, Microsoft COM, Java/RMI et Entreprise Java Beans. En dépit de leurs grands
succès, ils ne peuvent pas être appliqués aux environnements mobiles en raison de la charge
minimale qu’ils induisent (tous les mécanismes visant à rendre transparentes les couches
inférieures). En effet, celle ci dépasse déjà les capacités des appareils mobiles de faible
puissance.
4.2.
Les middlewares orientés messages :
Les composants communiquent à l’aide de messages : Un client envoie un message contenant
la requête pour un service avec ses paramètres à un serveur, qui répond avec un message
contenant le résultat. Ce type de middleware supporte donc les communications asynchrones
mais il nécessite de nombreuses ressources, notamment en mémoire pour pouvoir stocker la
liste des messages qu’il doit exécuter. De plus, aucune forme de conscience (awareness) n’est
supportée : les messages sont gérés de façon transparente pour les applications. Sun’s Java
Message Queue et IBM’s MQSeries font parties de cette catégorie.
4.3.
Les middlewares orientés transactions :
Ils sont principalement utilisés dans les applications de base de données. Ils supportent les
transactions sur un système distribué : un client regroupe plusieurs opérations dans une
transaction et le middleware l’envoie au serveur. Ils permettent des communications
asynchrones et synchrones tout en garantissant une atomicité des transactions (seulement si le
serveur implémente un protocole de validation à deux phases. IBM CICS et BEA’s Tuxedo
appartiennent à cette catégorie, qui ne peut pas être non plus utilisée pour les mobiles.
5. Vers des middlewares adaptés aux mobiles
Il s’agit ici de présenter des plates-formes qui n’ont pas nécessairement été conçues dans
l’optique de la mobilité mais qui comportent certaines fonctionnalités permettant d ‘envisager
ce type d’application.
Les solutions développées actuellement peuvent être regroupées en trois catégories à savoir
les Reflective middleware solutions permettant de construire des middlewares légers et
reconfigurables donc adaptatifs, les tuple-space based systems proposant un espace de
stockage virtuel partagé pour gérer des communications asynchrones ; les Context-aware
middleware qui fournissent aux applications des informations sur les modifications du
contexte d’exécution.
5.1.
Réflective middleware solutions :
Les réflectives middlewares, utilisent le principe de réflexion pour s’auto modifier et donc
s’adapter au mieux à la situation rencontrée. Les middlewares classiques décident seuls du
comportement à adopter sans consulter l’application. Avec la réflexion, c’est l’application
qui, en fonction de ses besoins, commande au middleware de modifier son comportement.
5.1.1.
OpenCorba :
OpenCorba [Ledoux 1999] permet aux utilisateurs d’adapter la représentation et les
politiques d’exécution de l’application dynamiquement. Il fait la distinction entre ce que fait
un objet et comment il le fait. Le protocole permet de changer de classe ou de meta-classe
dynamiquement, sans regénérer du code.
En dépit de sa flexibilité, des résultats expérimentaux ont montré l’impact négatif de cette
approche sur l’efficacité. En effet, le standard CORBA est bien trop lourd pour tourner sur des
mobiles. Les performances risquent d’être pires en utilisant OpenCorba.
5.1.2.
Next generation middleware :
Dans Next generation middleware [Blair et al. 1999], chaque interface (un objet peu en avoir
plusieurs) a un ensemble de meta-espaces, qui sont structurés en trois modèles :
encapsulation, environnement et composition. L’encapsulation fournit un ensemble de
méthodes et d’attributs pour cette interface. La composition permet d’accéder aux éléments
constitutifs de l’objet. Le problème d’intégrité est minimisé car chaque interface a son metaespace qui est structuré. Cette configuration permet d’adapter et d’ajouter facilement des
services.
Cependant les expérimentations qui ont été effectuées sont basées sur le modèle CORBA, qui
n’est pas adapté aux environnements mobiles.
5.1.3.
Globe
Globe [Van Steen et al. 1999 ; Bakker et al. 1999] est une plate-forme middleware spécialisée
dans la conception d’applications distribuées à grande échelle. Pour cela, Globe utilise des
mécanismes de réplication de l’information couplés au principe de réflexion.
Alors que la plupart des middleware prennent seuls les décisions concernant les données à
répliquer et les moyens de le faire, Globe laisse la possibilité au développeur de définir cela.
Globe introduit la notion d’objets distribués et partagés (Distributed Shared Object). Il s’agit
d’objets conceptuels répartis et partagés entre plusieurs machines qui disposent de
représentants locaux des objets (proxies et réplicats). Les représentants coopèrent pour mettre
à disposition une image consistante de chaque objet. Cette approche apporte une certaine
flexibilité au système tout en respectant les mécanismes de réplication et de répartition.
On notera que la structure des représentants locaux sépare la partie du code chargée de la
réplication de celle chargée de la communication. De cette façon, le programmeur peut
développer son propre protocole de réplication indépendamment de l’aspect communication.
Les algorithmes de réplications les plus courants sont fournis en standard par la plate-forme.
Le principe de réplication commandé par l’application est intéressant car il répond à un des
besoins émis par la mobilité. Mais la plate-forme Globe en elle même est conçue pour
fonctionner sur des postes fixes ayant une connexion permanente, elle n’est donc pas adaptée
au monde mobile.
5.2.
Tuple-space based systems
Les middlewares à base d’espace de tuples se prêtent bien aux applications mobiles car ils
permettent d’implanter des mécanismes de communications asynchrones. Avec ce type de
système, l’émetteur et le récepteur n’ont pas besoin d’être connectés simultanément au réseau
pour échanger des données.
Un tuple peut être considéré comme un vecteur de données typées. L’espace de tuple est un
conteneur permettant la mise en partage des tuples et la gestion des accès concurrents.
Tout ceci reste théorique et certaines questions fondamentales restent en suspend comme la
persistance des données ou encore la présentation des données aux clients mobiles et surtout
le problème de la résolution des conflits dans le cadre de la synchronisation des données.
5.2.1.
Lime
Lime [Picco et al. 1999] propose une adaptation du Linda tuple space [Gelernter 1985]. Il
s’agit de décomposer l’espace de tuples en sous espaces associés à une unité mobile. Ainsi
chaque unité détient une partie de l’information qu’elle partage pour la durée de sa connexion
au réseau (notion de partage éphémère ou transient sharing).
Pour mettre en partage l’information, chaque unité dispose d’une interface d’espace de tuple
(interface tuple space, ITS). Cette interface contient les tuples que l’unité souhaite partager.
Lorsque l’unité est connectée au réseau, le contenu de l’ITS est recalculée de manière à
fusionner les tuples mis à disposition par l’ensemble des unités accessibles. A la connexion
d’une nouvelle unité, les ITS sont recalculées pour prendre en compte l’apport informationnel
des nouveaux tuples, on parle d’engagement. Par un processus inverse, la déconnexion d’une
unité entraîne le désengagement de son espace de tuple au sein de l’espace global. Ainsi, la
disponibilité de l’information est mise à jour dynamiquement et de manière transparente pour
l’application ce qui peut être vu comme un avantage.
Cependant cet avantage est à relativiser si l’on cherche à implanter un certain degré de
conscience au niveau applicatif (notion de context awareness cf. 5.3), en particulier si l’on
voulait par exemple implanter une politique de contrôle d’accès à l’espace de tuple global.
Lime tente d’apporter une réponse à cela en permettant d’effectuer différentes projections de
l’espace partagé et par conséquent de présenter à l’application une partie restreinte de l’espace
global.
Concernant l’implantation du « context awareness », Lime introduit la notion de LimeSystem
qui assure le partage des informations relatives au système (utiles à la définition d’un contexte
comme par exemple le type de composants mobiles présents sur le réseau et les relations
existantes entre ces composants) dans un espace de tuples dédié dont l’accès est en lecture
seule. Enfin, il est possible de définir des réactions sur l’espace de tuples. Il s’agit de
procédures déclenchées par certaines modifications dans la configuration du système.
Bien que cela offre une certaine réactivité, aucun mécanisme ne permet pour le moment à
Lime d’adapter son comportement aux modifications du contexte.
5.2.2.
Tspaces
Tspaces [Wyckoff et al 1998] se présente comme l’alliance entre espaces de tuples et
technologies issues des bases de données. Les espaces de tuples apportent un moyen de
communication flexible pour le partage de l’information. Le recours aux technologies issues
des bases de données garantit la cohérence du système(mécanismes transactionnels) et offre
des possibilités de requêtage évoluées.
Tspaces est basé sur une architecture clients/serveurs. Les serveurs peuvent gérer plusieurs
espaces de tuples mais chaque espace de tuples est géré de manière centralisée par un seul
serveur ce qui élimine la notion de tolérance aux fautes. De plus l’adoption de ce type
d ‘architecture limite Tspaces aux applications nomades puisque les serveurs doivent disposer
de ressources importantes et donc être fixes.
Tspaces est programmé en Java ce qui est un atout en terme de portabilité mais rajoute une
couche supplémentaire pénalisante en terme de performance et de charge.
5.2.3.
JavaSpaces
Javaspaces [Waldo 1998] repose sur les mêmes principes que Tspaces avec en particulier
l’apport des mécanismes transactionnels permettant de garantir l’intégrité de l’espace de
tuples. Mais Javaspaces se différencie en ne considérant plus les tuples comme de simples
vecteurs mais comme de vrais objets Java ce qui permet de leur associer des méthodes et par
conséquent d’en étendre les capacités.
Au même titre que Tspaces, Javaspaces repose sur une architecture client légers mobiles
/serveurs fixes ce qui induit les mêmes limitations que celles énoncées précédemment.
5.2.4.
Limitations des middleware à base d’espace de tuples
Comme nous l’avons montré, le concept d’espace de tuples permet d’implanter efficacement
le mode de communication asynchrone mais il souffre de nombreuses limitations.
Tout d’abord, les tuples sont des structures plates et par conséquent difficilement
organisables. Cela induit de piètres performances lors de l’accès aux données, notamment
lorsque le volume d’informations atteint un certain niveau.
Ensuite, les primitives read, write et take offertes par les systèmes à base d’espace de tuples
sont trop basiques pour permettre l’intégration du « context awareness » c’est à dire la
possibilité pour l’application d’influencer le comportement du middleware en fonction des
modifications du contexte d’exécution. Cela nécessiterait l’adoption de paradigmes
d’interaction beaucoup plus complexes qui s’appuient sur une structuration des données bien
plus évoluée que celle offerte par les tuples.
Un autre point noir de ces systèmes réside dans la gestion de la synchronisation des données.
Les déconnexions sont fréquentes dans le cadre d’applications mobiles, il est donc nécessaire
de fournir des mécanismes de « réconciliation » qui permettent de résoudre les conflits de
tuples répliqués et modifiés par plusieurs entités lorsque celle ci se reconnectent au réseau.
5.3.
Context aware middleware
Ce type de middleware permet aux applications de s’adapter aux modifications du contexte
d’exécution et/ou à l’hétérogénéité des entités avec lesquelles elles interagissent.
La notion de contexte d’exécution correspond à un ensemble de données relatives à :
•
•
•
•
La localisation.
Les caractéristiques de l’appareil (puissance, mémoire, état de la batterie, …)
L’environnement physique (Bande passante disponible, bruit sur la ligne,…)
L’activité de l’utilisateur (faible/forte mobilité, veille, …)
Dans l’état actuel des choses, seul le critère de localisation a donné lieu à une réalisation dans
le monde des middleware mais la prise en compte des autres indicateurs s’avère cruciale dans
un contexte mobile.
La prise en compte de la localisation au niveau applicatif permet en autre d’adapter le service
en fonction de la situation géographique de l’utilisateur. Cela peut aller de l’aide à la
navigation jusqu’à la publicité ciblée en fonction du lieu dans lequel on se trouve. La
problématique dans ce domaine consiste à gérer de manière transparente les différents
capteurs de position (GPS en extérieur, infrarouge ou radio en intérieur). A ce niveau, le
middleware apporte la transparence en proposant une interface commune aux différents
systèmes. C’est le cas du middleware Nexus [Fritsch et al. 2000].
Nexus apporte une couche d’abstraction pour l’exploitation de différents types de système de
positionnement et possède aussi la faculté de s’adapter à des appareils n’ayant pas les mêmes
ressources matérielles (puissance, mémoire,…).
En fait la problématique du context awareness se résume à une question de compromis entre
le volume d’information qu’il est possible de collecter et la charge supplémentaire induite par
la collecte et le traitement de ces données. En effet, ces deux opérations impliquent l’ajout de
capteurs et de code au sein des terminaux augmentant d’autant leur coût et leur consommation
en ressources (batterie, processeur, mémoire, …).
5.4.
Les autre solutions intéressants
Nous allons présenter dans cette partie des solutions qui n’appartiennent à aucune des trois
catégories précédentes mais qui répondent à certains problèmes posés par l’informatique
mobile comme la gestion des déconnexions ou la découverte dynamique de nouveaux
services.
Ainsi des systèmes comme Coda et Odyssey, Bayou et Xmiddle ont pour but de maximiser la
disponibilité des données en permettant aux utilisateurs d’accéder à des réplicats. Les
différences entre ces solutions se situent dans la façon de détecter et résoudre les conflits
engendrés par l’utilisation de ces réplicats.
5.4.1.
Coda et Odyssey
Coda [Satyanarayanan et al. 1990] est à la base un système de fichier distribué spécialisé dans
le déploiement d’applications à grande échelle. Il repose principalement sur la réplication des
serveurs et un mode déconnecté. La réplication implique la redondance dans le stockage de
l’information. Le mode déconnecté met en jeu un système de caches temporaires.
Dans l’architecture Coda, il existe une distinction entre les serveurs, peu nombreux, qui sont
fiables et synchronisés et les nombreux clients, aux comportements aléatoires, qui peuvent
être coupés du réseau pendant une longue période. Par conséquent Coda repose sur un cœur
de serveurs fixes et se prête dans le meilleur des cas aux applications nomades (pas ad-hoc).
Les déconnexions sont considérées comme des phénomènes rares sous Coda. Lors des
déconnexions, les clients accèdent uniquement aux données qu’ils avaient précédemment mis
en cache. A la reconnexion, les modifications apportées sont propagées au groupe de serveurs
gérant le réplicat affecté. La déconnexion est donc perçue comme un état transitoire qui doit
être transparent pour le client. Cela pose néanmoins un problème dans la mesure ou le client
ne dispose d’aucun moyen de définir quelles sont les informations qui doivent être répliquées
localement (gâchis de bande passante et de mémoire au niveau du client).
Odyssey est le successeur de Coda, il apporte des fonctionnalités permettant la prise en
compte du contexte d’exécution. Grâce au modèle collaboratif d’adaptation qu’il propose,
Coda permet aux applications de définir des seuils de disponibilité sur les ressources qui leur
sont les plus utiles. Ainsi, le middleware sera capable de réagir en fonction de la qualité de
l’accès aux données.
5.4.2.
Bayou
Le système de stockage bayou [Demers et al. 1994 ; Terry et al. 1995] se donne pour objectif
la résolution des conflits résultant de l’activité concurrente sur les appareil ayant un accès
réseau de faible qualité. Avec Bayou, chaque application peut lire et écrire les réplicats de
données sans qu’une synchronisation permanente ne soit nécessaire. Chaque terminal reçoit
des mises à jour de la part des autres.
La spécificité de Bayou est qu’il collabore avec les applications qu’il supporte. En fait, il
appartient aux développeurs de décrire les situations de conflits ainsi que les procédures de
résolution associées. Le middleware implémente le code pour concrétiser ces traitements.
La détection des conflits se base sur le contrôle des dépendances. Sur chaque opération
d’écriture, un serveur est consulté pour savoir si la donnée à modifier est à jour. Si ce n’est
pas le cas, l’autorisation de modifier la donnée est refusée et la procédure de résolution de
conflit est déclenchée.
La consistance du système est assurée grâce à la synchronisation des opérations d’écriture au
niveau du cœur de serveurs (les opérations d’écriture sont toutes effectuées dans le même
ordre) et au déterminisme des opérations de détection et résolution de conflits (les conflits
sont résolus de la même manière sur tous les serveurs).
En raison de son architecture basée sur un cœur de serveurs fixes bayou impose les mêmes
limites que Coda et Odyssey.
5.4.3.
Jini
Dans un contexte mobile, il est possible qu’un service disponible à la dernière connexion, ne
le soit plus à la reconnexion ; de même un nouveau service peut devenir disponible en cours
d’exécution d’une application.
Jini [Arnold et al. 1999] se propose de répondre à ce problème en définissant un service
comme une entité qui peut être utilisée par une personne, un programme ou un autre service.
Les membres du système Jini se regroupent pour partager l’accès aux services. Un service de
base permet la recherche d’autres services à partir de leur description fonctionnelle (primitive
discovery) et la mise en relation avec les services trouvés (primitive join). En fait, il s’agit
d’un service de type pages jaunes.
Encore une fois cette solution repose sur une infrastructure fixe et ne se prête donc pas aux
applications ad-hoc.
Conclusion
Après ce tour d’horizon, nous pouvons conclure qu’à l’heure actuelle, aucun middleware ne
réunit toutes les caractéristiques requises par les applications mobiles. Le middleware idéal
pour l’informatique mobile doit être suffisamment léger pour fonctionner sur des terminaux
bénéficiant de peu de ressources, supporter des modes de communication asynchrone et doit
pouvoir prévenir l’application des changements opérés sur le contexte d’exécution
(fluctuation de la qualité de service sur le réseau, faible niveau de batterie, …).
Il faut donc s’appuyer sur les solutions existantes et les fusionner pour développer un nouveau
middleware.
Le « contexte awareness » est une des propriété qui apparaît comme essentielle au
développement de la mobilité. Les travaux la concernant sont en cours et des questions
fondamentales restent sans réponse. Comment représenter les informations relatives au
contexte et comment les présenter à l’application (au développeur)? Une solution serait
d’utiliser des méta données. Dans cette optique, le langage XML apporte le niveau de
structuration nécessaire à ce type d’application.
Concernant l’interaction entre middleware et application, on pourrait s’appuyer sur le
principe de réflexion et implanter un certain nombre de comportements prédéfinis au niveau
du middleware. Il appartiendrait à l’application de modifier le comportement du middleware
en fonction des informations que ce dernier lui transmet.
Au niveau des structures de données partagées, on pourrait se pencher sur l’utilisation du
paradigme de communication peer to peer. L’information est répartie sur l’ensemble des
terminaux avec des mécanismes de réplication, l’accès aux informations s’effectue par le biais
de requêtes se propageant de proche en proche. Cette approche décentralisée pourrait convenir
aux applications ad-hoc sous réserve que le réseau dispose en permanence d’une masse
critique de terminaux connectés ou que le degré de réplication soit important.
L’aspect sécurité revêt une importance capitale dans les applications mobiles. La facilité
d’accès au médium physique (l’air) rend le recours à la cryptographie quasi obligatoire pour
préserver le caractère privé des informations circulant sur le réseau. Néanmoins ces
mécanismes sont coûteux en terme de bande passante et de puissance calcul.
Autre point important, on note une différence importante des capacités entre les terminaux
mobile si bien qu’il serait intéressant de disposer de composants modulaires pour
l’élaboration de middlewares « à la carte » suivant le terminal cible. On pourrait coder les
même fonctionnalités avec différents niveaux de détail et donc de légèreté pour trouver le
meilleur compromis entre intelligence du système et charge induite pour chaque type
d’appareil.
Bibliographie
Arnold, K., O'
Sullivan, B., Scheifler, R. W., Waldo, J., and Wollrath, A. 1999.
The Jini[tm] Speci_cation. Addison-Wesley.
Baker, S. 1997. Corba Distributed Objects : Using Orbix. Addison-Wesley.
Blair, G., Coulson, G., Robin, P., and Papathomas, M. 1998. An Architecture for
Next Generation Middleware. In Proceedings of Middleware '
98 (Sept. 1998), pp. 191{206.
Springer Verlag.
Bray, J. and Sturman, C. F. 2000. Bluetooth: Connect Without Cables. Prentice Hall.
Capra, L., Emmerich, W., and Mascolo, C. 2001a. Middleware for Mobile Computing:
Awareness vs. Transparency (Position Summary). In Proceedings of the 8th Workshop on
Hot Topics in Operating Systems (HotOS-VIII) (Schloss Elmau, Germany, May 2001), pp.
142.
Capra, L., Emmerich, W., and Mascolo, C. 2001b. Re ective Middleware Solutions for
Context-Aware Applications. In Proceedings of REFLECTION 2001. The Third International Conference on Metalevel Architectures and Separation of Crosscutting Concerns
(Kyoto, Japan, Sept. 2001). To appear.
CellPoint, Inc. 2000. The CellPoint System. http://www.cellpt.com/thetechnology2.htm.
Demers, A., Petersen, K., Spreitzer, M., Terry, D., Theimer, M., and welch, B. 1994.
The Bayou Architecture: Support for Data Sharing among Mobile Users. In Proceedings of
the IEEE Workshop on Mobile Computing Systems and Applications (Santa Cruz, California, Dec. 1994), pp. 2{7.
Dey, A., Futakawa, M., Salber, D., and Abowd, G. 1999. The Conference Assistant:
Combining Context-Awareness with Wearable Computing. In Proc. of the 3 rd International
Symposium on wearable Computers (ISWC '
99) (San Fran_sco, California, Oct. 1999), pp.
21{28. IEEE Computer Society Press.
Eliassen, F., Andersen, A., Blair, G. S., Costa, F., Coulson, G., Goebel, V., Hansen,
O., Kristensen, T., Plagemann, T., Rafaelsen, H. O., Saikoski, K. B., and Yu,
W. 1999. Next Generation Middleware: Requirements, Architecture and Prototypes.
In Proceedings of the 7 th IEEE Workshop on Future Trends in Distributed Computing
Systems (Dec. 1999), pp. 60{65. IEEE Computer Society Press.
Emmerich, W. 2000a. Engineering Distributed Objects. John Wiley & Sons.
Emmerich, W. 2000b. Software Engineering and Middleware: A Roadmap. In The Future
of Software Engineering - 22 nd Int. Conf. on Software Engineering (ICSE2000) (May
2000), pp. 117{129. ACM Press.
Fritsch, D., Klinec, D., and Volz, S. 2000. NEXUS Positioning and Data Management Concepts for Location Aware Applications. In Proceedings of the 2nd International
Symposium on Telegeoprocessing (Nice-Sophia-Antipolis, France, 2000), pp. 171{184.
Gelernter, D. 1985. Generative Communication in Linda. ACM Transactions on Programming Languages and Systems 7, 1, 80{112.
Held, G. 2000. Data Over Wireless Networks: Bluetooth, WAP, and Wireless Lans.
McGraw-Hill.
Ledoux, T. 1999. OpenCorba: a Re ective Open Broker. In Re ection'
99 , Volume 1616 of
LNCS (Saint-Malo, France, 1999), pp. 197{214. Springer.
Long, S., Kooper, R., Abowd, G., and Atkenson, C. 1996. Rapid prototyping of mobile
context-aware applications: the Cyberguide case study. In Proceedings of the Second Annual International Conference on Mobile Computing and Networking (White Plains, NY,
Nov. 1996), pp. 97{107. ACM Press.
Picco, G., Murphy, A., and Roman, G.-C. 1999. Lime: Linda meets Mobility. In Proc.
21 st Int. Conf. on Software Engineering (ICSE-99) (May 1999), pp. 368{377. ACM Press.
Roman, G.-C., Murphy, A. L., and Picco, G. P. 2000. Software Engineering for Mobility: A Roadmap. In The Future of Software Engineering - 22 nd Int. Conf. on Software
Engineering (ICSE2000) (May 2000), pp. 243{258. ACM Press.
Satyanarayanan, M., Kistler, J., Kumar, P., Okasaki, M., Siegel, E., and Steere, D.
1990. Coda: A Highly Available File System for a Distributed Workstation Environment.
IEEE Transactions on Computers 39, 4 (April), 447{459.
Terry, D., Theimer, M., Petersen, K., Demers, A., Spreitzer, M., and Hauser, C. 1995.
Managing Update Con icts in Bayou, a Weakly Connected Replicated Storage System. In
Proceedings of the 15th ACM Symposium on Operating Systems Principles (SOSP-15)
(Cooper Mountain, Colorado, Aug. 1995), pp. 172{183.
van Steen, M., Hauck, F., Homburg, P., and Tanenbaum, A. 1999. Globe: a Wide-Area
Distributed System. IEEE Concurrency 7, 1 (March), 70{78.
Waldo, J. 1998. Javaspaces speci_cation 1.0. Technical report (March), Sun Microsystems.
Wyckoff, P., McLaughry, S. W., Lehman, T. J., and Ford, D. A. 1998. T Spaces. IBM
Systems Journal 37, 3, 454{474.
Yokote, Y. 1992. The Apertos reflective operating system: The concept and its implementation. In Proceedings of OOPSLA'
92 (1992), pp. 414{434. ACM Press.