Approches explicites

II.1.3.1. ELECTRA

Basé sur la version 1.2 de la spécification CORBA, ELECTRA [Maffeis 1995] est historiquement le premier ORB qui a visé à introduire la notion de tolérance. Implémenté en C++, cet ORB intègre les fonctionnalités de gestion de groupe et les mécanismes de tolérance aux fautes pour faciliter le développement d’applications distribuées sûres de fonctionnement.

Figure 17 a. Architecture d’ELECTRA b. Aperçu de l'architecture de CORBA 1.2

Comme le montre la Figure 17.a, l’architecture d’ELECTRA est composée de trois parties : • La couche supérieure représente l’interface de programmation des applications (API).

Elle fournit de nouvelles fonctionnalités relatives à la tolérance aux fautes (i.e. gestion d'un groupe de répliques, détection d'une défaillance, etc.).

• La couche intermédiaire est responsable de l'appel à distance d'une procédure. Elle joue le même rôle qu'un ORB ; elle est destinée, particulièrement, à des applications procédurales et non pas orientées objets.

• La couche inférieure a pour rôle de rendre ELECTRA portable par rapport aux différents systèmes de communication de groupe (i.e. ISIS, HORUS, TOTEM, etc.).

ORB

Interface de l’ORB

SII

DII DSI_BOA

DII SII ORB BOA Module de diffusion RPC Machine virtuelle Adaptateur d’objets Machine réelle (exp. Horus)

Système Opératoire

: Méthodes d’interface non standards

Couche su pé rie ur e Couche inf ér ie ur e Couche intermédiaire

L'interface proposée par la partie supérieure est très proche de celle définie par l’OMG (voir Figure 17.b) à l'exception de trois composants. La première différence réside au niveau du BOA qui est la version non portable du POA introduit dans le paragraphe I.1. Ce composant s’est vu rajouter d'une part des méthodes de gestion de groupes (la création ou la destruction de groupes d’objets CORBA, et l’inscription ou le retrait d'une réplique à un groupe d'objets) et d'autre part, des services de tolérance aux fautes, à savoir des fonctionnalités relatives à l’obtention et la mise à jour de l’état interne des différents membres d’un groupe et à la notification des changements d’appartenance. La seconde différence concerne l’interface de la classe environment, qui est responsable de la transmission des exceptions soulevées par le serveur au client. Définie par l’OMG, cette classe se voit ajouter une première méthode qui spécifie le type de la requête (i.e. synchrone, asynchrone ou intermédiaire), puis une seconde qui fixe le nombre de réponses qu’un client reçoit. La dernière différence réside au niveau de la SII. En effet, cette interface est générée par le compilateur IDL d'ELECTRA qui est basé sur l’interface DII. Contrairement à la spécification de l’OMG qui propose à la fois une SII et une DII, ELECTRA considère le DII comme le cœur de l’ORB. Ainsi toute requête est construite dynamiquement en utilisant son type (i.e synchrone etc.) que l'ORB récupère de la classe environment. L'empaquetage des données, marshaling, n'est pas réalisé au niveau de l'ORB mais au niveau de la DII, donc à l'exécution (d'où un surcoût).

De son côté, la couche inférieure est composée d’une machine virtuelle et d’un adaptateur d’objets. La machine virtuelle offre la même abstraction des mécanismes de diffusion, de gestion de groupes qu'un GCS. La seconde composante transforme les méthodes définies au niveau de la machine virtuelle (gestion de groupe, contrôle des différents types de messages, détection des erreurs, synchronisation par sémaphores ou par compteurs d’événements) vers leurs équivalents dans la plate-forme spécifique (i.e Isis, Horus, etc.).

Avec l’ajout de nouvelles méthodes à l’interface BOA, la création d’un groupe d’objets et son initialisation avec un membre sera à la charge de l’application elle même. En outre, même si l’invocation d’une méthode d’un groupe d’objets est transparente au client, elle est non- interopérable. En effet, dans l’approche ELECTRA, un objet est un groupe d’objets avec un membre unique. Ainsi, le client doit récupérer la référence d'un groupe pour invoquer la méthode d'un serveur. Une fois arrivée au niveau du module RPC, cette requête sera émise vers les différents membres du groupe. Seuls la détection de l'arrêt inopiné d’un membre, le contrôle et la mise à jour de l’état interne de groupe sont transparents par rapport aux clients et aux applications.

Le changement de la sémantique de l'IOR a valu à cette approche sa qualification d'explicite. En effet, dans ELECTRA, l'IOR référence un groupe de répliques et non plus un objet CORBA unique. Ainsi, l'utilisation de l'IOR par un client explicite le groupe d'objets auquel une invocation doit être diffusée par le service RPC.

Les approches classiques

II.1.3.2. OGS (Object Group Service)

Élaboré dans le cadre de travaux visant à munir l’intergiciel CORBA de mécanismes de tolérance aux fautes d’une manière inter-opérable, OGS [Felber 1998b] propose un service de gestion de groupe dont l’interface est mise à la disposition des développeurs d’applications distribuées. Dans cette approche, on n’a apporté aucune modification au niveau de l’API proposée par l’OMG, d’où sa classification dans les approches service.

Figure 18. a. Architecture de OGS b. Interactions client/serveur dans OGS

Comme le montre la Figure 18.a, OGS propose quatre services différents :

• Le service de groupe est responsable, d’une part, des opérations relatives au cycle de vie d’un groupe d’objets (i.e. la création, l’ajout ou le retrait d’un membre et la destruction d’un groupe) et d’autre part, de diffuser les requêtes vers les membres actifs du groupe.

• Le service d’observation fournit une interface composée des méthodes permettant au service de groupe d’observer l'état courant des membres d’un groupe (défaillance, élimination ou encore création d’un serveur).

• Le service de messagerie fournit une interface utilisée par les clients pour pouvoir envoyer leurs requêtes asynchrones à un groupe d’objets. En effet, comme l’intergiciel CORBA utilise un modèle d'appel synchrone pour le traitement des requêtes (le client reste bloqué lorsque le serveur est en train de traiter la requête), le service de messagerie ajoute de nouvelles fonctionnalités pour permettre aux clients d’émettre des requêtes non bloquantes et au groupe d’objets de diffuser les requêtes en utilisant des primitives au niveau système.

• Le service de consensus permet de résoudre les problèmes relatifs au consensus entre objets distribués avec communications asynchrones [Fischer 1985]. Ce service implémente l’algorithme de Chandra et Toueg [Chandra 1996] pour permettre à des objets distribués de s'accorder sur le nombre des membres actifs dans un groupe. La Figure 18.b montre les interactions entre client et serveurs en utilisant l’approche service d’OGS. Lorsqu’un serveur est lancé, il commence par créer un administrateur de groupe (ADM) qui offre une interface permettant aux serveurs de gérer le cycle de vie du groupe auquel ils appartiennent ou souhaitent appartenir (i.e. insertion, retrait, etc.). Par ailleurs,

Client Serveur 1 Serveur 2

ORB

ACC ! ADM ADM

Service de messagerie Service d’observation ORB Système Opératoire Co m po sa nt s d’O G S Service de

lorsqu’un client est initialisé, il crée de son côté un accesseur de groupe (ACC). C’est l’interface de l’ACC qui permet au client de pouvoir interagir avec un groupe d’objets. Ainsi, toute requête issue d'un client arrive au niveau de l’accesseur de groupe, puis est reprise par le service de messagerie pour être livrée (diffusée) aux différents membres du groupe via leurs administrateurs de groupe.

En utilisant cette méthode pour la réplication des applications, le problème de la portabilité de cette approche est théoriquement résolu par définition. En effet, en utilisant des services CORBA, tout système d'exploitation qui supporte ce type d’intergiciel peut être utilisé sans modification aucune au niveau du code des services (applications). En revanche, comme cette approche est basée sur les appels de méthodes définies au niveau des interfaces proposées, la gestion des groupes et la transmission des invocations ne sont pas transparentes. Ceci est dû, d’une part à la demande explicite du serveur pour créer un administrateur (création ou ajout d’un membre d’un groupe) et d’autre part, à la demande du client de la création d’un

accesseur qui jouera le rôle de médiateur pour les requêtes qu’il émet pour le groupe d’objets.

Par ailleurs, tout service est amené a implémenter l’interface Groupable, qui permet de récupérer et de mettre à jour l’état d’un membre du groupe. Ceci impose, d'une part, au développeur de l’application de spécifier l’état de son application, d'autre part, cette approche pose des problèmes d’interopérabilité puisqu'on peut avoir des formats de captures d’état qui ne sont pas compatibles entre différentes implémentations.

L'utilisation d'un accesseur de groupe a valu à OGS sa qualification d'approche explicite. En effet, un client adresse explicitement sa requête à l'accesseur du groupe pour qu'elle soit diffusée vers l'ensemble des répliques. Dans cette approche, l'IOR ne perd pas son sens, celui de l'identification d'un objet CORBA unique. Le client n'utilise plus l'identificateur du serveur pour accéder aux services qu'il propose. Néanmoins, il utilise l'identificateur de l'accesseur qui peut le récupérer aussi bien lors sa création (cas où l'accesseur est créé par le client) qu'en utilisant le service de nommage, si l'accesseur est créé par un membre tiers.