Notre problématique

2.4.1.4 Les services applicatifs

Ce type de service constitue le type le plus évolué. Ils orent aux utilisateurs des possibilités d'eectuer des achats, de réserver des billets d'avion de contrôler des machines à distance, etc...

Le premier exemple français de ce type de service fut le Minitel qui, grâce à un terminal spécialisé, permettait d'accéder (et permet toujours d'ailleurs, même si le Web tend à remplacer ce terminal préhistorique) à un grand nombre d'ap- plications comme des services bancaires par exemple.

Grâce à l'exécution d'applications dont l'entrée et la sortie sont rediri- gées vers une page HTML au moyen de scripts CGI (Common Gateway In- terface) [CR99], les services applicatifs basés sur le Web se développent de plus en plus.

Cependant, contrairement aux types de services présentés dans les sections précédentes, aucune norme n'est disponible quant au développement de ces ap- plications. Les programmeurs doivent en général réaliser leur propre gestion de l'interaction entre leur service et les utilisateurs ou les autres services.

Pour pallier à ces problèmes des couches logicielles intermédiaires permet- tant de développer facilement des applications distribuées ont été développées et pour certaines, standardisées. Les standards les plus connus de ces middle- ware [Ber96] sont les bus à objets répartis CORBA (Common Object Request Broker) [Obj04] de l'OMG (Object Management Group), DCOM [Mic95] de Mi- crosoft et Java/RMI [Mic98] de Sun.

Le principe sous-jacent de ces architectures et d'uniformiser l'appel à des mé- thodes sur des objets, que ces derniers soit hébergés par la machine locale ou un hôte distant. De plus, l'architecture de ces middleware permet également de masquer l'hétérogénéité du matériel, du système d'exploitation et même (sauf pour Java/RMI) du langage de programmation. Une application développée en C++, qui tourne sur une plate-forme Windows pourra appeler des méthodes sur un objet programmé en Java, hébergé par une machine sous Unix de façon com- plètement transparente. Grâce à ces abstractions, l'écriture de service ainsi que l'interopérabilité de ces derniers est simple à mettre en ÷uvre. Grâce à des ser- veurs de types pages jaunes, une application pourra même, si elle en a besoin, demander à obtenir une référence sur un objet fournissant le service qu'elle désire (par exemple, un objet qui peut eectuer un chirement) de façon dynamique.

censent les services disponibles. Comme ses serveurs sont toujours accessibles, il sut de les interroger pour obtenir l'adresse de l'hôte qui fournit le service que l'on cherche. Pour fournir un service, il est également facile de le publier auprès d'un de ces serveurs an de le rendre disponible au reste du réseau.

Dans les réseaux ad hoc, une telle centralisation des données est inadaptée. En eet, les serveurs qui recensent les services peuvent être inaccessibles à cause de la mobilité. Si on considère que le réseau est uniquement constitué d'entités mobiles, donc de petite taille, il est peu probable qu'il existe dans le réseau une machine possédant les capacités physiques en terme de mémoire, d'énergie et de bande passante pour se permettre de stocker tous les services disponibles et répondre aux requêtes de tous les autres membres du réseau. Il convient donc de proposer des méthodes permettant de distribuer l'information dans le réseau. C'est ce point que nous adressons dans le Chapitre 3.

Une fois que le service à été trouvé, il s'agit de s'en servir. Si l'on met de côté l'aspect standardisation des services (point qui ne fait pas l'objet de notre travail), un problème apparaît quand on passe du monde laire au monde ad hoc.

En laire, une fois la connexion établie, cette dernière reste valide tout au long de la phase d'utilisation du service. Si ce n'est pas le cas, le réseau est considéré comme en panne et aucun mécanisme n'est mis en place car cela n'est pas censé arriver. Il est en eet rare d'être privé de son serveur mail favori et, quand c'est le cas, il sut souvent d'attendre quelques heures pour de nouveau proter de plusieurs mois d'utilisation sans problème. Par contre, dans les réseau ad hoc, cette conjecture de abilité n'est plus vériée. Il n'est en eet pas rare que la mobilité des n÷uds entraîne la séparation du réseau en plusieurs composantes disjointes. Si la plupart des protocoles de routage proposent de corriger les routes quand elles deviennent invalides, une fois que deux n÷uds ne peuvent plus phy- siquement se joindre, il est trop tard pour tenter quoique ce soit ! Il devient alors intéressant d'analyser l'état du réseau an d'essayer de prédire les moments où les n÷uds vont être physiquement déconnectés car, si on prévoit l'événement suf- samment à l'avance, il sera encore temps de réagir. Cette réaction peut être de diérente nature, chercher à dupliquer le service, chercher un autre n÷ud fournis- sant un service équivalent, renforcer la connexion en déplaçant d'autre n÷uds...

Le Chapitre 4 traite des méthodes possibles pour eectuer une telle prédiction.

Dissémination d'informations

Découvrez ce que vous aimeriez faire et faites tout votre possible pour y parve- nir

Jonathan Livingston le goéland, Richard Bach.

Dans ce chapitre, nous présentons une solution originale au problème de dif- fusion d'information dans les réseaux ad hoc. L'application que nous visons en particulier est la recherche de services mais nous nous attacherons au problème de diusion dans une optique générale. La solution proposée pourra alors se décliner pour diverses applications comme, évidemment, la recherche de services [BR00], mais aussi le routage géographique [Sto02, BCSW98] ou toute autre application nécessitant la répartition de données dans le réseau en vue de la rendre accessible le plus facilement possible du plus grand nombre de n÷uds.