Building a Configurable
Pub/Sub Notification Service
Cristian G. Fiorentino
Advisor: Mariano Cilia
UNICEN, June 2006
Previous Work - Foundations
– Event-based MMPOG (J2EE, JMS)
• JMS limitations
– Rebeca NS extension: Channels
– Research Initiation Scholarship:
• DVS Group, TU-Darmstadt, Germany
– Paper Accepted at IFIP – DAIS ‘05
• International Conference on Distributed Applications
and Interoperable Systems
• Athens, Greece, June 2005
– NS Performance and Reliability Analysis
– Framework Development / Documentation
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Introduction
Introduction: Event-Based Paradigm
• Since more than a decade commercial applications do apply
the Client/Server architectural style
• New Technology Trends have emerged:
– imposing convergence of technologies (sensor miniaturization,
intelligent adaptative autonomous systems)
– business trends like: the supply chain management, or zero-latency
enterprises, real-time enterprises
• They have begun mistakenly using the Client/Server
architectural style.
– Request/Reply paradigm not suited for event-based systems
• Event-based paradigm has emerged as the proper solution
– allowing the flow of data/events from producer to consumer(s)
– the producer of data is responsible to initiate the interaction when a
situation of interest is observed
– incorporation of new applications do not imply code modification
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
1
Introduction
Introduction: Pub/Sub Notification Services
• In distributed systems, the responsibility of data
dissemination is delegated to the middleware
• We focus on Pub/Sub NS as a particular case of this
middleware, that implements the event-based paradigm
• Pub/Sub mechanisms offer loosely coupled exchange of
asynchronous notifications, facilitating extensibility and
application scalability
• Internally: Network of brokers, Routing Algorithms, Transport
C1
C3
NS
C2
C4
Introduction
Introduction: Pub/Sub Notification Services
• Addressing models
– a main classification for NS. Define subscription expressivity and are
intimately related with routing strategies.
– They have evolved from channel-based, to more flexible subject-based,
and expressive content-based and concept-based approaches
• Many commercial products and specifications:
– WebSphereMQ, TIB-Rendezvous, and various JMS compliant
implementations (Sun, JBoss, OpenJMS, ActiveMQ)
• Content-based research prototypes
– Rebeca, Siena, JEDI, Gryphon, etc.
• More recently have emerged Topic-based Pub/Sub systems
built on top of a P2P overlay network.
– Examples of these NSs are: Scribe, Hermes, Fiorano.
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
3
Introduction - Pub/Sub Notification Services
Introduction: Rebeca
• Open Source Notification Service Framework
• Rebeca Event-Based Electronic Commerce Architecture
– Research prototype at DVS Group, TU Darmstadt, Germany
• Principal purpose
– Test Routing Algorithms and Performance
• Routing Algorithms
– Flooding, Simple Routing, Identity Routing, Covering, Merging
• Characteristics
– Filters
– Advertisements
• Extended functionality
– Transactions, Concept-based Addressing, Caching, JMS interface,
Channels
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
4
Introduction
Introduction: Peer-to-Peer (P2P)
• P2P: an Overlay Network topology
–
–
–
–
–
Offer failure resilience
Self managing system
Allow high Scalability
Nodes hold a circular Ring address
Point-to-point O(log N) connections
• DHT Solutions:
– Pastry: Scalable Distributed Object Location, Ring O(log(n)), RT, Leaf,
Neighbors, Locality
– Bamboo: Pastry DHT, Hi Level Churn, Static Resilence, Failure
Detection, Recovery Algorithms
• P2P Content-based Routing Algorithms:
– Spanning Tree approach: Tree over P2P Graph, Edge Filter, Invariant,
Pub/Sub over Trees
– Bit Zipper: Data placement for P2P, Rendezvous Problem
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
5
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Motivation
Motivation: NS Required Features
• To provide applications, the NS needs to interpret,
aggregate, filter and analyze streams of messages to
adequately make messages flow from any data
producer to interested consumers
• Applications require many issues of interest
• Academia research has focused on several of them:
–
–
–
–
–
–
efficient dissemination
addressing models
message correlation
mobility
scalability
fault-tolerance
–
–
–
–
–
–
access controls
data integration
security
privacy protection
transactions
caching, etc.
• But still many others need to be offered …
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
6
Timestaps
Orders ...
Applicatio
n
Config.
Multiple
Brokers
Life Cycle
Mangemen
t
!
!
Multiple- !
Topologie
Runtime
Adaptabilit
y
!
Tunning
!
!
Optimize
Resources
!
!
Routing
Algorithm
¿ NS?
!
MultiPlatfor
m
Monitoring
NS
Size
!
s
!
Performanc
e
Extensible
Funtionalit
y
Deploymen
t
Tools
!
Network
Protocol
!
Reliabilit
y
!
Messag
e
Models
!
!
!
!
Motivation
Motivation: Today’s Problems
• Different applications require different NS features and
combinations
– News Ticker, Supply-chain management, MMPOG .
• Existent Publish/Subscribe middleware supports the basic
stream of messages
– but are typically monolithic and includes only a subset of features
• Today no product offers all required features and they are
hardly extendible
“A problem arises when developers need a middleware that
(completely) fulfills their application requirements…”
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
8
Index
Agenda
•
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Architecture
Lower-level Design Decisions
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Goals
Goals
• Offer a NS solution that accomplish:
–
–
–
–
Clear NS Design
The inclusion of all desired features BUT only the required ones
Extensible Configurable Features, Usability
Multi-platform Infrastructure, Technology-independent
• Offer a facility for “generating” pub/sub NSs that supports the
combination of required issues based on application
requirements
• Allows the configuration of a Pub/Sub solution based on a
reusable and extensible set of building blocks
• Offer a testbed to experiment and probe different ideas
together with other approaches
Solution...
Fiorentino Cristian, 2006
Framework
“Building a Configurable Pub/Sub Notification Service”
9
Catalogue “A”
Catalogue “B”
Catalogue “D”
A1
B1
C1
D1
A2
B2
C2
D2
A3
B3
C3
D3
C1
D2
NS Framework
NS instance
Catalogue “C”
Organization
A2
B3
Organization
Goals
But also…
• Allow the NS user to easily generate a deployable NS, based
on provided or user generated building blocks
• Provide tools for NS deployment
• Provide tools for management at runtime
–
–
–
–
Allow Functionality Adaptability
Tuning
Remote management
Monitoring
• Offer multiple brokers in the same machine
• Allow different deployment strategies
• Provide different routing algorithms, overlay networks and
transmission protocols
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
11
Goals
Proposed Approach
• FRANSCESCA:
“FRAmework for a Notification Service
ComponEnt-baSed Configurable Architecture”
A framework for Notification Services that enables the construction of a
NS instance according to user needs,
selecting among a predefined and extensible set of components,
that mainly include broker type, routing algorithm and network structure.
The resulting NS must be then adaptable, configurable and easily
deployable and manageable.”
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
12
Goals
Proposed Approach in three steps
Elementary
Building Blocks
(1)
NS Specification
Resulting NS
Adm
User
Framework
Configs.
Services
QoS
(2)
NS Deployment
(3)
NS Management
NS
NS
NS
Deployment
Tool
NS
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Framework Design
Main Architecture
• Analysis, organization and classification of all required NS Features 
Layered Design + Orthogonal Functionality
• Layered design offers:
• Designed layers include:
–
–
–
–
–
Application: specific application
Broker: brokers funct., filters
Routing: router, routing algorithm
Topology: overlay networks
Network: transport, serialization
Application Layer
Management
– Clear, equilibrated organization
– Cohesive independent components
– Goal: modifiability and portability
Broker Layer
Routing Layer
Topology Layer
Network Layer
• Orthogonal Functionality includes Management issues like Life Cycle
Management, Adaptation, Monitoring, Tuning
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
14
Framework Design
(cont. 1)
Main Architecture
– Main component
– Filter
– Strategy
• A service is a specific
combination of components
crossing (possibly) all layers
– Represent a Broker instance
– Not all component
combinations are possible
– Allow to reuse components
in different services
Fiorentino Cristian, 2006
ServiceA
ServiceB
App1
App2
Application
Management
• Layers group a set of
components with similar
functionality sharing the same
common interface.
• Components represent
specific building blocks.
Component types:
Concept-B
Broker
Broker
Scopes
Filter
Content-B
Broker
Bit
Spanning Rebeca
Zipper Tree P2P Routing
Ants
Routing
DHT
Channels
Static tree
Topology
Network
UDP
Network
Serializer
“Building a Configurable Pub/Sub Notification Service”
Network
TCP
15
Framework Design
Interfaces
• A common set of interfaces between layers was crucial to
easily allow to add and change functionality
• It has been defined two kinds of interfaces:
– Asynchronous: they define the main message passing system events
• Divided between pair-of-layers protocol, connection and interface events
• Also divides as upwards and downwards
– Synchronous: define a direct communication between layers and
components
• Used to get/set state of components directly
• Lower overhead approach
• Message design:
– Specific Message interfaces
– Message Models
• Layering: message structure (serialization required)
• Pipeline: message filtering (XML transmission)
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
16
Application
Broker
Exception
Detect()
Routing
ContRoute()
Forward()
Topology
errorDet()
: protocol ev
: connect. ev
: interface ev
errorDet()
read()
: routine
Network
-m: Message
-i: Information
-k: destination Key
-nh: nextHopNode
-D: Destination
-St: State -Ev: Event
-Ae: App Event
-Ex: Exception
write()
Framework Design
Extensibility: Component Creation
1.
2.
Define component type
Decide if include
configurable strategies
Identify Data Agreements
3.
–
–
4.
–
–
Interface
Layer B
Extensible Representation
abstract common data types
For each component class:
specific parameter format
Layer B
and data types
Interface
Implement main class
–
–
–
Layer A
Layer B
Implementing layer interfaces
Possibly include Legacy code Interface
Layer C
Include any programming
languaje code using JNI
Layer C
Framework behavior binding
UserToolkit interface.
Fiorentino Cristian, 2006
Encapsulation
Legacy Legacy
Code Code
Legacy
Code
New Code
“Building a Configurable Pub/Sub Notification Service”
Legacy
components
18
Framework Design
Extensibility: Component Creation
5.
6.
Define component configurations and subscriptions descriptively
–
Layer
–
Type
–
Class
–
Name
–
Identifier
–
Services
–
Message Type
–
Subscriptions
(LDAP syntax)
Create component
bundle
(cont.1)
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Deployment & Runtime
Deployment Options
Broker Layer
Application Layer
Routing Layer
Broker Layer
Topology Layer
Network Layer
Global NS View
Routing Layer
Topology Layer
Network Layer
Broker
Client-Broker
Client
Router
Application Layer
Routing Layer
Broker Layer (Local Broker)
Topology Layer
Network Layer
Network Layer
Deployment & Runtime
Deployment & Runtime
• Different deployment and runtime strategies offered
– Upwards and downwards event shortcuts in the layering stack them
allow different deployment options.
– Component selection at creation time and runtime implicates a variable
pipeline of components with dynamic wiring
– Multi-platform deployment (Mainframes, PCs, Mobile Devices like
PDA, telephones, and embedded systems)
• How to manage homogeneously different component
instantiation and how to automate component wiring?
Solution..
Fiorentino Cristian, 2006
Runtime Environment
“Building a Configurable Pub/Sub Notification Service”
21
Deployment & Runtime
Component-based Infrastructures
• Lightweight containers: Alternative to the heavyweight
complexity in the mainstream J2EE
– Back to POJOs (Plain Old Java Objects)
– Inversion of Control (IoC)  Dependency Injection
• Lightweight containers offers a suited Runtime Environment
– Instantiating component respect to descriptive configurations and
management tools
– Component wiring achieved automatically
• Important Deployment decisions:
– Container independent code: portable code to different containers
– Also allow non container-based deployment (clear interfaces)
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
22
Deployment & Runtime
Container Analysis and Selection Criteria
Feature
Platform
Comp
Characteristics
Pico
Class
Container
Container, startable, dep. iny.
Inv. of Control
JMX
MBean Agents, adaptor
Connectors,
Mbean Server
Bamboo
Stage Stage subscribe
DustDevil
to events. Build
over SEDA
OSGi
Bundle Platform,
bundles (Jar,
Manifest)
Complexity
Config.
Dyn.
Remote
Deploy
Size
Life
Cicle
Manag.
+
+/--
-
++
+/-
Get/set
inteface
Coded
instance
+
+
+/-
Startable
interface
+/-
Web
+
-
Web
-
+
Coded
instance
+
+
Get/set
service
+
+
+/interface
+
+
J2ME
Comm.
line
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Configuration and Management
Configuration and Management
• Formalization of the main Configuration Capabilities:
–
–
–
–
Layer Selection
Component Types
Functionalities Selection
Component Settings (configuration and tuning)
• Orthogonal Functionality includes Configuration and
Management functions
–
–
–
–
Life Cycle Management
Configuration
Monitoring
Includes Runtime Environment and Wiring
• Management components treated as container components
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
24
Configuration and Management
Architecture Configuration Verification
• Architecture-based Verifications: assure architecture
coherence restricting the evolution of architectural design
• For every configuration capability a related Verification
–
–
–
–
Layer Selection
Component Type 
Functionality Selection
Component Settings

Layering Verifications
Component Type Verification

Functionality Arch.Consistency

Component Settings Verif.
• Map NS Framework architecture into Families and Systems of
some ADL (ACME)
• Checks creation or runtime configurations (system) against
predefined architectural family constraints
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
25
Configuration and Management
Management Design
Management
Comp.
Config.
Broker Layer
Routing Layer
Topology Layer
Life
Cycle
Manag.
Main Manager
output
Application Layer
Monitoring
monit
Config. Data
input
Manual
Configuring
Running NS Broker(s)
update
Network Layer
Event Translation
Layer Style
Checker
Main
Checker
Configuring
Verification
Comp Type
Checker
Settings
Checker
output
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Case Study/Framework Usage
Rebeca Encapsulation
•
•
•
•
Relying on Franscesca, reuse Rebeca code
A way to validate Framework design and defined interfaces
Encapsulate Rebeca code into Franscesca component for each layer
Just encapsulating components, Rebeca gains Franscesca advantages:
management, different message models, extensibility, etc.
Application
Management
Application
Rebeca
Content-B
Broker
Flooding
Simple
Identity
Covering
Merging
Routing
Channels
Static tree
Topology
Network
Fiorentino Cristian, 2006
Network TCP
“Building a Configurable Pub/Sub Notification Service”
27
Case Study/Framework Usage
Encapsulation Implementation
• Different design found
• Similitudes: Routing, Application
• Lower design intersections:
Application
– Broker/Network, Topology/Routing
• Not all interfaces used
• Map data types, Main comp. types
Topology
Router
L. Broker A
Broker
Routing
Network
Event
Broker
Event
Transport
Event
Router
Routing
Engine
L. Broker B
Event
Broker
EvRouting
Conn
Event
Transport
Event
Transport
Case Study/Framework Usage
Framework Usage Tools
•NS Creation
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
29
Case Study/Framework Usage
Framework Usage Tools
•NS Creation
•Component
Life Cycle
Management
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
30
Case Study/Framework Usage
Framework Usage Tools
•NS Creation
•Component
Life Cycle
Management
•Component
Configuration
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
31
Index
Agenda
•
•
•
•
•
•
•
•
Introduction
Motivation
Goals
Framework Design
Deployment & Runtime
Configuration and Management
Case Study / Framework Usage
Conclusions and Future Work
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
Conclusions and Future Work
Conclusions
• Main Contributions:
– Obtained a solution to satisfy specific NS requirements
– Flexible framework, covering wide range of NSs
– Well suited layered architecture, with a accurate definition
Interfaces for each layer
– Allow Different deployment configurations
• Main Characteristics:
– Allow multi-brokers (optimizing computational resources)
– Different message representations (structured, XML)
– Message Definition and Common data agreements allow to implement
components using to legacy code
– Different component types, offering design flexibility
– Descriptive configuration allow reusable components
– Good extensibility due to: framework behavior binding, UserToolkit
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
32
Conclusions and Future Work
Conclusions
• Facilities and Tools offered:
– Allows to generate NS instances, ready to be deployed in a Runtime
Environment
– Remote deloyment tools (NS instances or components)
– Components’ life-cycle Management (Component Adaptation)
– Manual or Automated component tuning
• Other interesting features:
– The architecture based configuration verification formalize
component relationship
– Scalability and self managing NSs using P2P overlays
– Reliability protocols are ready to be included
– Management components treated as layering ones .
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
33
Conclusions and Future Work
Future Work
• Offer a wide component catalog:
– Support with P2P Overlays and related Routing algorithms
– Include Concept-based addressing components
– Implement SOAP-based protocols (in network layer) to transmit XML
messages
• Analysis and comparison:
– Use framework as a testbed to compare different combinations
– Test framework overhead comparing monolithic with frameworkintegrated solutions.
• Include QoS metrics based on recent research
• Establish NS Security models based on scopes
• Based on the SOAP implementation, implement and test
WSNotifications specifications
• Implement aspects of reliability, based on JMS approaches and
Web Services Reliability specifications.
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”
34
The End.. Thank you!
Questions?
Fiorentino Cristian, 2006
“Building a Configurable Pub/Sub Notification Service”