Composition d’évènements sur les systèmes publier/souscrire basés DHT 97

publier/sous-crire basés DHT

Le premier travail proposé pour traiter les évènements composites sur un système pu-blier/souscrire basé DHT est celui de Courtenage et al. [16]. Ils utilisent Functional Event

Language(FEL) comme un langage formel pour définir les souscriptions. FEL est un langage

déclaratif et fortement typé (voir [81] pour plus de détails).

L’architecture du framework est fondée sur la DHT Chord. Pour la décentralisation de la gestion d’évènements, chaque nœud DHT peut être un détecteur d’évènements atomiques ou un détecteur d’évènements composites selon son ID. Le hachage permet au service de

détection d’être placé sur un nœud DHT particulier. La Figure 4.7 illustre l’architecture

du framework fondé sur FEL. Elle montre la distribution des services sur une DHT de 256 nœuds en montrant les 4 nœuds d’IDs : 14, 46, 97, 167. Le nœud 14 est un conteneur de deux services : Détecteur d’Evènements Composites (CED) et Détecteur d’Evènements Atomiques (AED). Les deux types d’évènements composite et atomique sont hachés pour associer les valeurs de CED et AED (10 et 191 respectivement) au nœud de la DHT d’ID 14 qui est le

Chapitre 4

successeur le plus proche des identifiants des services comme le montre la même figure. Ceci permet d’équilibrer automatiquement la charge entre les nœuds du réseau. Si un nouveau nœud rejoint la DHT avec un ID 255, alors l’AED d’ID 191 migre du nœud 14 au nœud 255.

Figure 3. FEL over Meteor

(including creation of new event detectors where neces-sary), acknowledgement messages are returned to indicate completion. The event detector discovery and acknowl-edgement messages are carried by the underlying Meteor layer of FEL, through a modified Meteor API that allows application-generated messages to be injected into the P2P network. However, the subscription is finalized at the ap-plication layer by further, separate use of JXTA. Once an event detector is ready, and before it sends acknowledge-ment messages to its parent (i.e., its subtree of the subscrip-tion graph has been fully configured), it creates a JXTA out-put pipe to publish its event notifications if one does not already exist. On receipt of the acknowledge message, the parent event detector binds to the JXTA output pipe in order to receive event notifications.

The use of JXTA, separate from the use of JXTA in the Meteor implementation of Chord, for event publications has the advantage that the P2P network is not congested by po-tentially heavy volumes of event notifications. Instead, the potentially expensive routing of messages around the Chord ring are reserved for the much lighter load of messages im-plementing new routing configurations. Direct use of JXTA pipes for event publication also has the advantage of solving the problem posed by the asynchronous, subscriber-driven creation of new composite event detector nodes mentioned in Section 2. A JXTA output pipe can be used to implement a form of loosely-coupled multi-cast, where one source can broadcast to potentially many clients, without needing to know which clients are receiving the outputs written to the pipe. This feature allows composite event detectors to con-figure themselves to receive component event notifications asynchronously without action on the part of the compo-nent event detector. To implement discovery of which pipe a composite event detector should bind to in order to receive

component events, we used the JXTA discovery service. A composite event detector needs to know only the type of the component event to use the JXTA discovery service to locate the pipe and to bind to it. Using JXTA in this way also has the further advantage that if an event detector is migrated to another node (as nodes join or leave the un-derlying P2P network), the routing of events between event detectors through JXTA pipes is unaffected.

5. Related Work

The work most directly related to ours is Hermes [9]. Hermes is an attempt to develop a middleware-based content-based event notification system, and delivers prim-itive events using a broker-oriented P2P-based architecture. In the composite event extension of Hermes [10], composite event detectors are external to the event notification system and have to be manually (and statically) placed at strategic positions around the system, subscribing to receive compo-nent events and, when a particular pattern is detected, inject-ing the composite event back into the system disguised as a primitive event. Although mobile CEDs are discussed, they require a logical overlay layer is required to move CEDs around the system, requiring as well additional administra-tive services and potentially complex interactions between event brokers to decide where they should be placed. Our work avoids all the problems of complexity, manual inter-vention, and administration posed by this approach by uti-lizing the hashing scheme of the underlying P2P network to perform automatic load balancing, service placement and dynamic service migration, as well as the JXTA technology to connect event brokers.

The peer-to-peer protocol Chord has been used before in the implementation of publish/subscribe systems: for exam-ple, content-based publish/subscribe systems using Chord is described in Triantafillouet al[15] and Terpstraet al[14]. The primary goals of [14] are the robustness of routing primitive events over a content-based publish/subscribe net-work and the implementation of a filtering strategy on top of a DHT-based P2P system. In [15], the concern is with how range predicates (more complex filters on content, such as

less-thanorgreater-than) can be implemented for primitive events in DHT-based P2P systems such as Chord where the use of hashing to locate nodes makes support of filters other than equality difficult.

6. Conclusion and Further Work

We have shown how a DHT-based P2P architecture and the use of the JXTA P2P open framework can solve the complex problems involved in the dynamic configuration of a composite event notification system that uses content-based routing of events. The DHT-content-based P2P layer allows

Proceedings of the 20th International Conference on Advanced Information Networking and Applications (AINA’06)

IEEE

Figure ^{4.7 – FEL appliqué à Chord pour la gestion distribuée d’évènements [16]}

Nous déduisons alors que ce système a résolu la difficulté de mise à l’échelle par l’utilisa-tion de la DHT mais son problème majeur reste l’expressivité. En effet, le langage FEL utilisé ne permet que de spécifier le type de l’évènement souhaité (filtrage basé type). De plus, FEL permet la détection des patterns d’occurrence d’une suite d’évènements selon leurs types. Autrement dit, il permet de vérifier des compositions d’évènements telles que : l’évènement de type T₂ se produit après l’occurrence de l’évènement de type T₁.

Le dernier travail qui traite la composition d’évènements sur un système publier/souscrire basé DHT est celui de J. Qian et al. [82]. Les auteurs proposent d’utiliser deux structures

sur chaque nœuds DHT : Primitive Subscription Map (PSM) pour la mémorisation des

souscriptions primitives et Composite Subscription Map (CSM) pour la mémorisation des

souscriptions composites.

Le défaut majeur de cette proposition est que tous les évènements primitifs doivent être vérifiés avant la vérification partielle des évènements sous-composites. Ceci s’avère inutile

dans plusieurs exemples de compositions comme celles utilisant les opérateurs logiquesAND

etXOR.

4.4.4 Synthèse

Le Tableau 4.1 récapitule les approches étudiées dans les sections précédentes.

Tableau 4.1 – Traitement de la composition d’évènements dans les systèmes publier/souscrire Approche Architecture Technique Relation de composition Mise à jour

RUBCES [12] centralisée à base de règles relations logiques (AND/OR) automatique selon les intérêts P.R. Pietzuch et al.[13] distribuée (se-lon les sources des CE)

FSA contraintes temporelles par le programmeur du système

M. Gaoet al. [14]

centralisée capteurs contraintes spatio-temporelles

par programmation des capteurs

PSware [15] centralisée capteurs opérateurs temporels (sé-quentiel et parallèle) et opé-rateurs logiques (conjonc-tion, disjonction et négation)

par programmation des capteurs

Courtenage et al.[16]

DHT FEL occurrence d’une suite d’évè-nements selon leurs types

automatique selon les intérêts

JtangCSPS [82]

DHT PSM/CSM relations logiques et tempo-relles

par le programmeur du système

Les travaux présentés par [12], [14] et [15] adoptent une architecture centralisée et traitent généralement peu de relations de composition. Seul [12] permet la mise à jour automatique, pour l’intégration de nouvelles compositions, afin d’exprimer les nouveaux intérêts compo-sites des utilisateurs. Le reste des approches centralisées ([14] et [15]) ne permet l’intégration de nouvelles compositions que par l’intervention d’une tierce partie (programmeur du sys-tème ou programmeur des capteurs).

Le travail présenté par [13] propose de distribuer les détecteurs des évènements composites selon leurs sources pour améliorer la scalabilité. Cependant, le problème d’ajout de nouvelles souscriptions composites reste restreint à l’intervention du programmeur du système. De plus, cette proposition ne traite que les contraintes temporelles pour la composition d’évènements. Les travaux présentés par [16] et [82] traitent la composition sur une architecture P2P structurée. Avec le travail de [16], l’ajout de nouveaux patterns de souscriptions selon les

Chapitre 4

intérêts des utilisateurs est possible sans intervention du programmeur, mais il ne permet d’exprimer que le besoin d’occurrence d’une suite d’évènements selon leurs types (manque d’expressivité). En contrepartie, [82] permet de bien exprimer une variété de relations de compositions (temporelle et logique). Toutefois, l’intégration de nouvelle composition n’est possible que par l’intervention du programmeur du système.