Conception de systèmes répartis

Nous présentons ici les diverses approches orientées langages pour la program-mation de systèmes répartis.

2.6. ÉTAT DE L’ART 51 Les langages de programmation généraux (C, Ada, Java) sont pourvus de li-brairies permettant la programmation répartie. La répartition n’est cependant pas automatique, dans le sens où la conception d’un système réparti au moyen de ces langages induit une première phase de répartition manuelle du système, suivie de la conception séparée de chaque ressource. Ces méthodes permettent une intégra-tion aisée des fragments ainsi conçus, la communicaintégra-tion entre ressources se faisant au moyen de librairies standardisées. Parmi les méthodes les plus récentes, on peut citer l’API Java RMI4, qui permet l’invocation distante de méthodes, en fai-sant abstraction de la technique sous-jacente (connections TCP/IP). Le standard CORBA5 [77] permet l’intégration de systèmes hétérogènes, conçus éventuelle-ment au moyen de langages de programmation différents, en faisant abstraction des techniques de communication entre les différentes parties du système. Enfin, l’approche de l’annexe Distributed Systems du langage Ada [69] est celle qui se rapproche le plus de celle développée dans cette thèse. Cette annexe permet la conception d’un système réparti sous forme d’un programme global, comprenant des partitions exprimant le programme à exécuter sur chacune des ressources de calcul. Parmi les langages moins notoires, on peut citer le langage Oz [51], qui permet la conception de systèmes répartis au moyen de la notion de ports, sur lesquels une primitive sendpermet d’envoyer des valeurs. Là encore, les partitions du systèmes sont explicites, ainsi que les communications entre ces partitions. Le langage Sequoia [35] permet de décrire l’architecture de la machine, puis d’instan-cier par compilation de ce langage un programme décrit au moyen de primitives de parallélisation (localisation et synchronisation des calculs) sur l’architecture dé-crite. L’approche proposée dans [26] permet de partitionner un unique programme en un client et un serveur, en fonction des politiques de sécurité définies par le programmeur au moyen d’annotations sur le programme à répartir.

Parmi les approches les plus récentes concernant les langages de programma-tion généralistes de systèmes répartis, on peut citer le langage Acute [73]. Ce langage est une extension d’un noyau ML permettant le développement de sys-tèmes répartis, par le biais de primitives de sérialisation et de désérialisation de données incluant la sérialisation du type des données communiquées d’un site à l’autre. Cette caractéristique permet de vérifier, à l’exécution, que le type de don-nées d’une donnée reçue correspond au type attendu, étendant ainsi le concept de typage fort de ML d’un unique programme à une architecture répartie. Cepen-dant, cette vérification de type est faite lors de la désérialisation des données, et est donc forcément dynamique : on perd ainsi l’avantage du typage statique de ML, permettant de vérifier le type des données à la compilation. L’approche que nous proposons permet de conserver le typage statique, effectué sur le programme

4

Remote Method Invocation

5

complet avant sa répartition.

Les langages de description d’architecture, et particulièrement le langage AADL [36, 3], permettent de concevoir un système composé de plusieurs ressources géo-graphiquement réparties. Dans le cas d’AADL, la conception d’un tel système est effectuée de manière hiérarchique : l’architecture matérielle est décrite en terme de processeurs, mémoires, bus et périphériques. Des contraintes temps-réel de pé-riodes d’exécution sont associées à ces éléments matériels. l’architecture logicielle est ensuite un raffinement de cette architecture matérielle, ce qui ne permet pas la conception du système indépendamment de l’architecture, lorsque la modularité fonctionnelle rentre en conflit avec la modularité de l’architecture.

Le principe de la conception orientée plateforme (platform-based design, [18]) est de concevoir le système en définissant des couches d’abstraction (les dénom-mées plateformes). Ces couches permettent d’abstraire l’implantation à un niveau donné du système, sous forme d’un ensemble de ressources offertes, associé à des contraintes entre ces ressources. On peut voir cette notion comme la généralisa-tion de la nogénéralisa-tion de module à l’échelle d’un système entier, architecture matérielle comprise. Cette généralisation permet la conception conjointe architecture/logiciel, sans toutefois perdre en modularité : l’objectif affiché de la conception orientée plateforme, utilisée dans l’industrie électronique, est de réduire la durée de déve-loppement de systèmes induite par cette conception conjointe. Dans le cadre d’un système réparti, la notion de « plateforme réseau » (network platform) permet de décrire une architecture composée de plusieurs ressources de calculs, reliées par des liens de communication. La méthode exposée dans cette thèse peut ainsi être considérée comme une instance de cette notion de conception orientée plateforme, instance dans laquelle l’architecture matérielle est la plateforme considérée.

Enfin, plusieurs modèles de calculs formels de description de systèmes répartis ont été définis. La plupart de ces calculs sont basés sur leπ-calcul, afin d’exprimer l’exécution concurrente de ces systèmes répartis. Ils consistent en la définition de sites (oulocations en anglais), permettant de délimiter la localisation de parties du calcul. La différence entre ces différents calculs tient à l’expression de l’architecture, et l’expression des communications entre sites. L’architecture peut ainsi soit être non hiérarchique : c’est le cas du π1ℓ-calcul [4] et du Dπ-calcul (distributed π -calculus, [5]) ; soit hiérarchique ou arborescente, par exemple pour les ambients [17] ou le join-calcul [37]. Le cas non hiérarchique correspond à la volonté de représenter une architecture physique (ressources de calcul tels que des processeurs) ou logique (processus légers sur un même processeur) composée de ressources s’exécutant de manière concurrente. Les architectures hiérarchiques permettent d’exprimer des propriétés de sécurité (par exemple, interdire l’accès à certaines informations depuis d’autres ressources), par encapsulation de ressources logiques à l’intérieur même de ressources parentes. L’expression des communications entre les ressources

2.6. ÉTAT DE L’ART 53 diffère d’un calcul à l’autre : elles peuvent prendre la forme d’émission de valeurs sur un canal global (π1ℓ-calcul et join-calcul), ou faire l’objet d’une migration du processus ou de la ressource qui elle-même effectuera une communication locale une fois reçue (Dπ-calcul et ambients). Parmi les modèles synchrones, on peut enfin citer ULM (Un Langage pour la Mobilité, [14]), qui permet au sein d’un même programme de déclarer plusieurs processus légers, et offre la possibilité de migrer un calcul en cours d’exécution d’un processus à l’autre. Un programme ULM permet de décrire unréseau asynchrone de machines synchrones. Le point commun entre ces modèles formels est qu’ils décrivent des systèmes dont la répartition des calculs est entièrement déterminée. De plus, sauf pour le Dπ-calcul, la structure fonctionnelle du programme est un raffinement de la structure de l’architecture. Notre approche est donc différente en deux points : tout d’abord, nous proposons un langage permettant de décrire de manière partielle la répartition du programme, cette répartition étant complétée automatiquement à la compilation. D’autre part, ces calculs sont basés sur le π-calcul, ce qui leur donne un caractère impératif. Le formalisme que nous utilisons, les réseaux de Kahn, permet de rendre compte plus aisément de l’exécution de programmes flots de données répartis, avec une sémantique globale synchrone.