Analysis of Versatility Trade-offs of Publish/subscribe Infrastructures

Introduction

In order to be reused in the support of different problem domains, software must be be versatile. The construction of versatile software is difficult and must observe different trade-offs. For example, problem domain dependencies define valid and invalid combination of features one can simultaneously support at a certain time; specificity versus generality; configurability and extensibility versus simplicify and generality and other trade-offs. 

In this research we focus on publish/subscribe infrastructures  (or notificatoin servers), a special class of middleware that supports the development of event-based applications. In order to support a broader set of application domains and their requirements, publish/subscribe infrastructures have been developed according to different  versatility strategies (see our survey of versatilty strategies in pub/sub infrastructures). For example, generalization: the development of minimal core APIs or coordination languages as tuple spaces; variability : the use of configurable one-size-fits-all infrastructures where a sub-set of predefined optional features can be selected and combined in the support of different applications; and, more recently, compositional strategies: the built of application-specific infrastructures out of existing or new components. 

Existing research usually focus on the benefits of  these individual strategies when supporting specific application domains. Few studies have focused on the comparative  analysis of the trade-offs that exist among these different approaches, when used in the support of different applicatoin domains.  For example, what are the costs and benefits of adopting one approach or another in the support of domain application X? What factors, or criteria, should be considered in selecting a infrastructure A for a given applicatoin domain?

In order to answer these questions, in this project we perform a multi-dimensional analysis of different factors, including: flexibilty (extensibility and configurabilty), reusability and usability of existing publish/subscribe infrastrucutres in the support of different applications.  With the lessons learned in this work, we expect to broaden the understanding of the factors that permeate the development of flexible middleware. We also expect  to derive more precise trade-offs, principles, metrics and guidelines that can better support developers in the construction of middleware in general, and publish/subscribe infrastructures specifically.

Approach

1. Selection of a sublcass of infrastructures representing existing publish/subscribe flexibilty approaches.
2. The development of different benchmarks in the form of heterogeneous application domains and their requirements
3. The implementation of these requirements using the selected infrastructures. For such, we employ blackbox and whitebox reuse.
4. The evaluation of the infrastructures according to different metrics
5. The comparison of the results
6. The derivation of principles and guidelines

Selected Infrastructures

In a previous survey of publish/subscribe infrastructures versatility approaches, we identified different strategies adopted by existing industry and research infrastructures in the support of an increasing set of event-driven applications. These strategies are:

1.        Build from scratch. Very often, publish/subscribe infrastructures have been recreated to support specific application domains. Examples include: Khronika built to support groupware applications, and JEDI employed in the support for workflow management systems and mobile applications.

2.        Adopt minimal core systems as Siena or Scribe , that provide simple but optimized services. These infrastructures are designed to be reused as publish/subscribe cores in different applications;

3.        Adopt coordination languages such as Linda , that provide a primitive vocabulary with which more complex coordination mechanisms can be built.

4.        Adopt one-size-fits-all infrastructures. as for example, CORBA-NS , that supports a broad set of user selectable subscription, notification, routing and QoS options;

5.        Or employ novel reconfigurable compositional approaches (as those provided by GREEN , YANCEES and FACET ). These infrastructures adopt compositional frameworks based on plug-ins (as with GREEN and YANCEES) or aspect-oriented programming (as the case with FACET), allowing the generation of application-specific infrastructures out of a existing or new components.

The approaches above present increasing levels of configurability,  extensibility, generality and reusability. Apart from build-from-scratch approaches, that are, in their majority, monolithic and tailored for specific application domains, all other approaches strive to be versatile, supportting a broader set of applications from different domains.

The selected infrastructures for our experiments were: Siena, JavaSpaces, CORBA-NS (Community OpenORB) and YANCEES.

Test Cases

EDEM

Expectation Driven Event Monitoring (or EDEM) is an approach to software usability testing based on the concept of expectations (common sequences of events that represent user interface interactions). Through the direct monitoring of applications deployed to end-users computers, EDEM detects and logs invalid or unexpected sequences of user interface events. These information is periodically sent to software developers and interface designers helping in the resolution of common usability problems.

EDEM Required publish/subscribe API

public interface IEDEMNotificationServerAPI {

 // State manipulation operations
  void setState(String key, String value);
  void setState(String key, int value);
  String getState(String key);
  void removeState(String key);

 // publication and subscription primitives
  void publish(IEDEMEvent event);
  void subscribe(ISubscriberInterface si, IEventFilter filter);
  void subscribe(ISubscriberInterface si, IStateFilter filter);
  void subscribe(ISubscriberInterface si, IPattern condition);
  void subscribe(ISubscriberInterface si, IRule rule);
  void unsubscribe(ISubscriberInterface si);
  void unsubscribe(ISubscriberInterface si, IEventFilter filter);
  void unsubscribe(ISubscriberInterface si, IStateFilter filter);
  void unsubscribe(ISubscriberInterface si, IPattern condition);
  void unsubscribe(ISubscriberInterface si, IRule rule);

From the point of view of the publish/subscribe infrastructures, EDEM requires the following features: event content-based filtering; event pattern detection supporting disjunction, conjunction and exact sequence match; state change filters; and rules. Rules are special abstract data types that combine patterns, actions (for example: event recording or counting) and a set of begin and end triggers. Triggers (or Guards) are pattern detectors based on state changes or event occurrences. They are used to control the activation and deactivation of actions within a rule. When rules become active (begin trigger is activated), actions are executed whenever the rule-specific pattern is detected. When a rule end trigger is activated, the rule stops operating and a notification is sent to the subscriber in the form of state and event records.

EDEM Benchmark

Vertical dashed boxes represent individual implementations used in our tests, for example: EDEM on JavaSpaces, EDEM on CORBA-NS, EDEM on Siena, etc. Solid rounded boxes represent components integrated in the production of each implementation. For example, EDEM on Siena combines: the tuple space component, the Siena notification server, server-specific event and tuple space adapters (that handle the conversion between Siena and EDEM events, notifications, triggers and subscriptions), and a common set of Pattern, Rule, Action and Guard implementations. Components that crosscut vertical dashed boxes represent are reused by two or more implementations.

EDEM Results

Code

Acknowledgements

This research has been sponsored by NSF (grants 0133749, 0205724, 0326105, 0527729,0524033), an IBM Eclipse technology exchange grant, and the Intel Corporation.