Looking into the Past: Enhancing Mobile PublishSubscribe Middleware

1
Looking into the Past EnhancingMobile
Publish/Subscribe Middleware

• Exponent
• Pablo E. Guerrero
• Thesis Supervisor
• Mariano A. Cilia

Universidad Nacional del Centro de la Provincia
de Buenos Aires Facultad de Ciencias
Exactas Tandil, Argentina, October, 2004
2
Agenda

• Motivation
• Problem Statement
• Proposed Approach
• Design Implementation
• Experimental Results
• Conclusions

3
Motivation

• Convergence of Technologies
• Usage of Large-Scale Distributed Systems
• Mobile Devices Wireless Technologies
• Client/Server (Request/Reply) Predominance
• New Paradigm for Information-Driven Applications
• WWW, Sensor Networks, Enterprise Strategies
• Pull-based (Request/Reply) Does Not Fit
• Polling implies resource waste
• Leads to Network Saturation or Server Breakdown!
• Not Suitable for Mobile Devices
• Push-based
• Event-based Dissemination

4
Motivation (II)

• Publish/Subscribe Middleware provides
• Asynchronous communication
• Loose coupling
• Producers dont know who is subscribed
• Clients can dynamically join and leave
• Doesnt require publishers and subscribersat the
  same time
• Reflects intrinsic behavior of Information-driven
  Application
• Support for roaming clients
• Notion of Location
• Location Transparency
• Pub/Sub needs an Intermediator

5
Publish/Subscribe Systems Structure

• Independent Process Data Flow Style
• Message Manager or Notification Service
• Clients (producers/consumers/both)
• Communication links
• Service Semantics
• Implementation
• Decentralized brokers
• Connected graph
• Clients proxies

6
Problem Statement

• Problem Found _at_ Applications Startup
• Initial Bootstrapping Sequence phase
• Getting a Consistent State
• Request/Reply (combination)
• Observation phase (pure Pub/Sub)
• Cannot assume how long will it take

anEventBasedApp
aNotificationService
7
Problem Statement (II)

• Problem Aggravated in Mobile Environments
• Disconnections
• Context Changes (new location)
• Pervasive environments dynamic behavior
• A new bootstrapping phase must be initiated!
• System responsiveness degraded

8
Proposed Approach

• Goal
• Reduce bootstrapping latency
• Use already published (past) notifications
• Extend an existing pub/sub system, REBECA
• Store notifications in its Infrastructure
• Caches Distributed in the Network
• Minimize underlying system changes

aNotificationService
anEventBasedApp
9
The REBECA Notification Service
10
REBECA Brokers Network
11
REBECA Routing Algorithms

• Flooding
• Filter Forwarding
• Simple Routing
• Identity-based Routing
• Covering-based Routing
• Merging-based Routing
• Routing with Advertisements

12
Proposed Approach

• Approach Analysis
• Caching Requirements
• Caching in Event-Based Systems
• Notifications Storage
• Cache Querying Strategies
• Guidelines

13
Proposed Approach Analysis

• Store Notifications in Distributed Caches
• Extending External Behavior
• Past Bound
• Interface Extension

14
Proposed Approach Analysis (II)

• Extend Internal Behavior
• Extend System Behavior

• Support for Different Strategies

15
Caching Strategies Requirements

• Response Time
• Time Overhead
• Space Usage
• Integrability
• Correctness
• Transparence
• Dynamism
• Separation of Concerns
• Specification of the Requirementsfrom the
  Infrastructure

16
Caching in Event-Based Systems

• Caching applied in a different fashion than
  traditional systems
• Main differences
• Cache Coherency and Consistency
• Cache Sizes
• Information Lifetime
• Caching vs. Buffering

17
Notifications Storage

• When? Locality Principle not Applicable!
• Distributed decision based on
• Subscriptions and Unsubscriptions
• Advertisements and Unadvertisements
• Notifications
• How? Behaving as FIFO queues
• Circular Ring Buffer

18
Notifications Storage (II)

• Parallel Circular Ring Buffers

• Take advantage of Content-based NS
• Filter Identity, Covering and Merging

19
Notifications Storage (III)

• A Combination, which
• avoids Replicating Notifications
• allows Ordering Notifications

20
Cache Querying

• NS is an Undirected Acyclic Graph
• How deep to search? (i.e. How many levels k?)
• Link traversals involve costs similar to RPCs
• De / Serialization, Un / Marshalling
• RPC Runtime Costs, Physical Network Transfer
• RPC requires 10.00015.000 machine instructions
• LPC 100 times faster than RPC
• Strategies Classification
• k 1 a Restricted to Local Event Brokers
• 1 lt k m a Restricted to maximum depth m
• k a Allowed to perform exhaustive search

21
Cache Querying LocalBrokerCaching
22
Cache Querying BorderBrokerCaching
23
Cache Querying MergingCaching
24
Cache Querying

• Caching w/More Complex Routing Algorithms
• Routing Algorithms selects which neighbors to
  forward a subscription
• Solution Force Forwarding an explicit Fetch
  message
• Caching w/Advertisements
• Avoid asking every peer by usingadvertisements
  information
• Considering the Time Dimension
• Border Brokers clocks synchronization
• Attach a Timestamp to notifications

25
Cache Querying Guidelines
26
Design Implementation

• OOPAproaches
• ClassInheritance
• DecoratorDesignPattern

27
AOP Architectural Approach

• Usage ofAOP tools

28
AOP Architectural Approach (II)

• Method Interceptions
• Advices
• Inter-Type Declarations
• Aspects

before (RoutingEngine routingEngine,
Subscription sub, EventProcessor
processor)
subscription(routingEngine, sub, processor)
if (sub.isBounded())
routingEngine.getCachingStrategy().beforeSubscribe
(sub, processor)
public void EventBroker.subscribe(Subscription
sub,
EventProcessor source,
PastBound
bound) private PastBound Subscription.bound
pointcut initRoutingEngine() initialization(Rout
ingEngine.new())
pointcut subscription() withincode(void
LocalEventBroker.subscribe(..)) call(void
RoutingEngine.addSubscription(..))
29
AOP Architectural Approach (III)

• CachingClassHierarchy

30
Experimental Results

• Provide details on Caching Behavior
• Evaluations Setup
• Hierarchical Network
• Consumers issue RandomSubscriptions
• Producers publishNotifications of Random Types
• Caching Efficacy Metric
• Measures Best-Effort

31
LocalBrokerCaching Evaluation
32
BorderBrokerCaching Evaluation
33
MergingCaching Evaluation
34
Caching Strategies Comparison
35
Conclusions

• Notification Service was Extended
• Reduced Bootstrap Latency
• Used a pure pub/sub Approach
• Minimal Changes on the pub/sub Subscription
  Interface
• Incorporated Distributed Caching
• Efficient, Content-based Notification Storage
• Several Strategies Analyzed Implemented
• Aspect-Orientation
• Achieved good modularity for a crosscutting
  concern
• Allowed a plug-and-play functionality
• Evaluation
• Measured Compared Caching Efficacy
• Gave Insights of Caching Behavior

36
Future Work

• Caching Functionality Integration
• On-line Integrationthrough Dynamic AOP
• Experiment with otherNotification Services
• Extend Evaluations
• Develop Analytical Response Time Models
• Perform Large Scale Simulations
• Consider Other Enhancements
• Priorization and Interactions with other Aspects
  of the Notification Service