Le service de diffusion d’événements CORBA est basé sur la notion de canal à
événements, qui sert d’intermédiaire entre les producteurs et les consommateurs
d’événements. Les producteurs et les consommateurs sont découplés dans l’espace, puisqu’un producteur ne sait pas quel est le nombre de consommateurs qui reçoivent ses événements, ni leur identité ; et les consommateurs ne peuvent pas savoir quel producteur est à l’origine d’un événement donné.
Le rôle du canal à événements est d’accepter des demandes d’inscription provenant de consommateurs ou de producteurs, puis de diffuser tous les événements des producteurs vers les consommateurs. Les consommateurs peuvent choisir d’utiliser un fonctionnement en mode pull (où ils interrogent régulièrement le canal afin de savoir si des événements sont disponibles), ou un modèle push (où le canal leur envoie un message à chaque fois qu’un événement leur est destiné). Symétriquement, les producteurs d’événements peuvent choisir d’envoyer les événements au canal ou demander à ce que le canal les interroge régulièrement pour récupérer les événements en attente.
3.3.1 Configuration expérimentale
La charge applicative que nous avons développée est constituée d’un producteur d’événements et de deux consommateurs. Les événements créés par le producteur contiennent une estampille indiquant l’heure où ils ont été créés, ainsi qu’un numéro de séquence. Lorsqu’il reçoit un événement, un consommateur compare l’estampille du message avec l’heure courante, afin de déterminer le temps de propagation de l’événement. Les consommateurs comparent également le numéro de séquence du message à un compteur qu’ils maintiennent localement, afin de déterminer si des événements se perdent.
Dans notre banc de test, le service de diffusion d’événements, le producteur et les consommateurs s’exécutent sur des machines différentes. Nous utilisons un modèle
de communication push-producteur, pull-consommateur, avec des événements non- typés5. La charge de travail est capable de détecter des événements invalides qui lui
sont délivrés par le service en examinant leur numéro de séquence. L’injection de fautes est effectuée par un producteur d’événements, qui invoque la méthode push sur le canal d’événements. La suite du déroulement d’une expérience est semblable au déroulement d’une expérience ciblant le service de désignation.
3.3.2 Résultats
La figure 3.12 page suivante présente les résultats d’une campagne d’injection d’inversions de bits, visant les services de diffusion d’événements d’ORBacus,
TAO et OpenORB. Ces expériences sont une extension de celles rapportées
dans [Marsden et al. 2002b]. Comme pour les résultats que nous avons présentés pour le service de désignation (c.f. §3.2.2 page 77), la figure regroupe les résultats d’expériences où chaque position de bit possible dans la requête push a été corrompue, soit environ 1500 expériences par cible.
Ces expériences montrent que le service de diffusion d’événements d’ORBacus est plus robuste que celui de TAO, puisque son taux de manifestation de ServiceCrash est plus faible, et que son taux de détection est plus élevé. Le service de diffusion d’événements de OpenORB est peu robuste, puisqu’il présente un fort taux d’arrêts inopinés.
Les manifestations de ApplicationFailure dans cette campagne sont des cas d’arrêt inopiné du consommateur d’événements : la corruption du message d’un producteur
database Channel Event producer producer consumer push, push, ... push, push, ... pull, pull, ... logging logging push controller démarrer
FIG. 3.11 –Configuration des expériences ciblant le service de diffusion d’événements 5Le service de diffusion d’événementsCORBApermet le choix entre des événements non-typés et des
événements typés. Dans le premier cas, les événements sont emballés dans un conteneur Any, ce qui permet de transporter n’importe quel type de données IDL, mais qui nécessite un accord entre les producteurs et les consommateurs pour emballer les données sous un format particulier. Dans le cas d’événements typés, le programmeur fournit une interface IDL décrivant les opérations qui pourront être invoquées par les consommateurs et les producteurs d’événements.
ORBacus TAO OpenORB somme = 100% 0 10 20 30 40 50 60 RemotePropagation ServiceCrash ApplicationFailure ServiceHang ConnectionHang DetectionException NonObservation
FIG. 3.12 –Distribution des manifestations de faute par cible.
Expériences d’inversion de bits pour le service de diffusion d’événements.
ORBacus TAO OpenORB
somme = 100% 0 10 20 30 40 50 60 70 COMM_FAILURE BAD_OPERATION MARSHAL OBJECT_NOT_EXIST OBJ_ADAPTER BAD_PARAM BAD_TYPECODE NO_MEMORY UNKNOWN
FIG. 3.13 –Distribution des exceptions par cible, expériences avec détection.
Expériences d’inversion de bits pour le service de diffusion d’événements.
d’événements s’est propagée via le service vers un consommateur. Le taux non né- gligeable de ApplicationFailure pour les candidats ORBacus et TAO indique que ces services analysent peu le contenu des événements qu’ils diffusent, permettant à des événements corrompus d’atteindre le consommateur d’événements. Par contre, aucune propagation d’erreur n’a été constatée pour le service d’OpenORB, qui semble s’arrêter avant de transmettre une donnée corrompue.
Il est intéressant de constater que la variété des exceptions levées est plus restreinte pour ce service que pour les expériences concernant le service de désignation. Ceci peut s’expliquer en partie par le fait que l’opération push, qui subit une corruption dans ces expériences, est une opération oneway. Le courtier peut traiter ces invocations sans retour différemment des opérations ordinaires. Nous observons la présence d’une nouvelle exception BAD_TYPECODE levée par le service de diffusion d’événements de
ORBacus, pour signaler que le typecode de l’événement qu’on lui demande de diffuser
n’est pas valide ; le candidat OpenORB semble signaler cette corruption par la levée d’une exception BAD_PARAM.