building a configurable pub/sub notification service
Post on 01-Jan-2016
54 Views
Preview:
DESCRIPTION
TRANSCRIPT
Building a Configurable Pub/Sub Notification Service
Building a Configurable Pub/Sub Notification Service
Cristian G. FiorentinoAdvisor: Mariano Cilia
UNICEN, June 2006
Cristian G. FiorentinoAdvisor: Mariano Cilia
UNICEN, June 2006
Previous Work - FoundationsPrevious Work - Foundations
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
– 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
– 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
AgendaAgenda
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
AgendaAgenda
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
Introduction: Event-Based ParadigmIntroduction: 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
• 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
IntroductionIntroduction
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 1Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 1
Introduction: Pub/Sub Notification ServicesIntroduction: 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
• 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
IntroductionIntroduction
NSNS
C1
C2
C3
C4
pub(a)
pub(b)
sub(a,b)
notif(a)
sub(a)
notif(a)notif(b)
NSNSNSNS
C1
C2
C3
C4
C3
Introduction: Pub/Sub Notification ServicesIntroduction: 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.
• 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.
IntroductionIntroduction
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 3Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 3
Introduction: RebecaIntroduction: 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
• 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
Introduction - Pub/Sub Notification ServicesIntroduction - Pub/Sub Notification Services
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 4Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 4
Introduction: Peer-to-Peer (P2P) Introduction: Peer-to-Peer (P2P)
IntroductionIntroduction
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 5Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 5
• 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
• 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
AgendaAgenda
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
Motivation: NS Required FeaturesMotivation: 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
• 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
MotivationMotivation
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 6Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 6
– access controls– data integration– security– privacy protection– transactions– caching, etc.
– access controls– data integration– security– privacy protection– transactions– caching, etc.
• But still many others need to be offered …• But still many others need to be offered …
NS
Life Cycle Mangemen
t
!Timestaps Orders ... !
Application
Config.!
MultipleBrokers !
Monitoring!Routing
Algorithm!NS Size !
Optimize Resources
!
Reliability !
Deployment
Tools!Runtime
Adaptability
!
Multi-Platfor
m
!
Tunning!
?¿NetworkProtocol!
Message
Models
!
ExtensibleFuntionalit
y
!
Performance !
Multiple-Topologie
s
!
Motivation: Today’s ProblemsMotivation: 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
• 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
MotivationMotivation
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 8Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 8
“A problem arises when developers need a middleware that (completely) fulfills their application requirements…”
• Today no product offers all required features and they are hardly extendible
• Today no product offers all required features and they are hardly extendible
AgendaAgenda
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
• Introduction• Motivation• Goals• Framework Architecture• Lower-level Design Decisions• Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Architecture• Lower-level Design Decisions• Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
GoalsGoals• 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
• 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
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 9Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 9
FrameworkFrameworkSolution...
GoalsGoals
NS
inst
ance
Organization
NS
Fra
mew
ork
Bui
l din
g bl
ock s
Catalogue “A” Catalogue “B” Catalogue “C” Catalogue “D”
Us e
rD
e fin
edPr
ovid
ed b
y Fr
amew
ork A1 B1 C1 D1
A2 B2 C2 D2
A3 B3 C3 D3
B3 D2
Organization
A2 C1
A2
C1
D2
B3
But also…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
• 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
GoalsGoals
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 11Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 11
Proposed ApproachProposed 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.”
•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.”
GoalsGoals
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 12Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 12
Proposed Approach in three stepsProposed Approach in three steps
GoalsGoals
Configs.Services
QoS
User
Adm
Framework
(2)NS Deployment
(1) NS Specification
(3)NS Management
NS
NSNS
Elementary Building Blocks Resulting NS
NS
DeploymentTool
FrameworkFramework
AgendaAgenda
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
Main ArchitectureMain Architecture
Framework DesignFramework Design
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 14Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 14
• Analysis, organization and classification of all required NS Features Layered Design + Orthogonal FunctionalityLayered Design + Orthogonal Functionality
• Layered design offers:– Clear, equilibrated organization– Cohesive independent components– Goal: modifiability and portability
• Designed layers include: – Application: specific application – Broker: brokers funct., filters– Routing: router, routing algorithm– Topology: overlay networks– Network: transport, serialization
• Analysis, organization and classification of all required NS Features Layered Design + Orthogonal FunctionalityLayered Design + Orthogonal Functionality
• Layered design offers:– Clear, equilibrated organization– Cohesive independent components– Goal: modifiability and portability
• Designed layers include: – Application: specific application – Broker: brokers funct., filters– Routing: router, routing algorithm– Topology: overlay networks– Network: transport, serialization
Routing Layer
Topology Layer
Network Layer
Broker Layer
Ma
na
gem
en
t
Application Layer
• Orthogonal Functionality includes Management issues like Life Cycle Management, Adaptation, Monitoring, Tuning
• Orthogonal Functionality includes Management issues like Life Cycle Management, Adaptation, Monitoring, Tuning
Main ArchitectureMain Architecture• Layers group a set of
components with similar functionality sharing the same common interface.
• Components represent specific building blocks. Component types:– 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
• Layers group a set of components with similar functionality sharing the same common interface.
• Components represent specific building blocks. Component types:– 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
Framework Design (cont. 1)Framework Design (cont. 1)
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 15Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 15
ScopesBit
ZipperSpanning Tree P2P
RebecaRouting
Ants
DHT Static tree
Network UDP
Concept-BBroker
Content-BBroker
Broker
Routing
Topology
Network
Man
agem
ent
App1
Application
App2
Network TCP
ServiceA ServiceB
Filter
Serializer
Channels
InterfacesInterfaces• 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)
• 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)
Framework DesignFramework Design
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 16Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 16
Del
iver
(Rm
)R
ecei
ve(T
m)
read()
Rou
teIn
it(R
m,
k)Rou
teC
ont(
Rm
,
k,
nh)
write()
Topology
Network
Routing
Broker
Sen
d(T
m,
D)
errorDet()
Upd
ate
(Ni,j
oin)
Upd
ate(
Ri,j
oin)
Upd
ate(
Mi,j
oin)
Upd
ate(
Bi,j
oin)
(Un)
Sub
(sub
,Ai)
Pub
(Ae,
pub)
C/E
-P
ubA
dv(a
dv,A
i)
C/E
-D
est(
dest
)
Application
errorDet()
(D)C
onnR
eq(B
i,D
)(D
)Con
nReq
(Ni,
D)
(D)C
onnR
eq(R
i,D
)
Con
ntR
es(C
onn)
Con
nRes
(Con
n)C
onnt
Res
(Con
n)
Con
nCon
f(C
onn)
Con
nIC
onf(
Con
n)C
onnC
onfC
onn)
(D)C
onnI
nd(B
i)(D
)Con
nInd
(Ni)
(D)C
onnI
nd(R
i)
Con
firm
(St,E
v)C
onfi
rm(S
t.Ev)
Con
firm
(St,E
v)C
onfi
rm(S
t,Ev)
: protocol ev
: connect. ev
: interface ev
: routine
Cha
nge(
Ti,j
oin)
Cha
nge
(Ri,j
oin)
Cha
nge(
Bi,j
oin)
Cha
nge(
Ai,j
oin)R
espo
nse(
St,E
v)R
espo
nse(
St.E
v)R
espo
nse(
St,E
v)R
espo
nse(
St,E
v)
A/R
-A
dv(A
dv)
A/R
-S
ub(S
ub)
Rou
te(P
ub)A
/R-
Des
t(D
est)
Not
ify(
Am
)
ExceptionDetect()
-m: Message-i: Information-k: destination Key-nh: nextHopNode-D: Destination-St: State -Ev: Event-Ae: App Event-Ex: Exception
New
Pub
(Pu
b) On-
A/R
-S
ub(S
ub)
On-
A/R
-A
dv(A
dv)
On-
A/R
-D
est(
Des
t)
Forward()
ContRoute()
Han
dleE
x(E
x)
For
war
d(R
m,k
,nh)
Extensibility: Component CreationExtensibility: Component Creation1. Define component type2. Decide if include
configurable strategies3. Identify Data Agreements
– Extensible Representation abstract common data types
– For each component class: specific parameter format and data types
4. Implement main class – Implementing layer interfaces– Possibly include Legacy code– Include any programming
languaje code using JNI– Framework behavior binding– UserToolkit interface.
1. Define component type2. Decide if include
configurable strategies3. Identify Data Agreements
– Extensible Representation abstract common data types
– For each component class: specific parameter format and data types
4. Implement main class – Implementing layer interfaces– Possibly include Legacy code– Include any programming
languaje code using JNI– Framework behavior binding– UserToolkit interface.
Framework DesignFramework Design
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 18Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 18
Encapsulation
New CodeNew Code
Layer B
Layer A
Layer C
LegacyCode
LegacyCode
InterfaceLayer B
InterfaceLayer C
InterfaceLayer B
Legacy components
LegacyCode
Extensibility: Component CreationExtensibility: Component Creation
Framework Design (cont.1)Framework Design (cont.1)
5. Define component configurations and subscriptions descriptively– Layer – Type – Class – Name – Identifier– Services – Message Type– Subscriptions
(LDAP syntax)
6. Create component
bundle
5. Define component configurations and subscriptions descriptively– Layer – Type – Class – Name – Identifier– Services – Message Type– Subscriptions
(LDAP syntax)
6. Create component
bundle
AgendaAgenda
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
Deployment OptionsDeployment Options
Deployment & RuntimeDeployment & Runtime
Routing Layer
Topology Layer
Network Layer
Broker Layer
Application Layer
Routing Layer
Topology Layer
Network Layer
Broker Layer
Routing Layer
Topology Layer
Network Layer
Broker Layer (Local Broker)
Application Layer
Network Layer
Client
BrokerClient-Broker
Router
Global NS View
Deployment & RuntimeDeployment & 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?
• 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?
Deployment & RuntimeDeployment & Runtime
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 21Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 21
Runtime EnvironmentRuntime EnvironmentSolution..
Component-based InfrastructuresComponent-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)
• 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)
Deployment & RuntimeDeployment & Runtime
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 22Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 22
Container Analysis and Selection Criteria Container Analysis and Selection Criteria Deployment & RuntimeDeployment & Runtime
+
+
+/-
+
Com-
plexity
+Comm.
line
+J2ME
+ +Get/set
service
Platform, bundles (Jar, Manifest)
BundleOSGi
+/-interface
+-Coded
instance
-Stage subscribe to events. Build over SEDA
StageBamboo
DustDevil
+Web
+/-++Web
Agents, adaptor
Connectors,
Mbean Server
MBeanJMX
+/-Startable interface
++-Coded
instance
+/--Get/set
inteface
Container, start-
able, dep. iny.
Inv. of Control
ClassPico Container
Life
Cicle
Manag.
SizeDyn.
Remote
Deploy
Config.CharacteristicsCompFeature
Platform
AgendaAgenda
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
Configuration and ManagementConfiguration 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
• 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
Configuration and ManagementConfiguration and Management
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 24Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 24
Architecture Configuration VerificationArchitecture Configuration Verification
• Architecture-based Verifications: assure architecture coherence restricting the evolution of architectural design
• For every configuration capability a related Verification– Layer Selection Layering Verifications– Component Type Component Type Verification– Functionality Selection Functionality Arch.Consistency– Component Settings 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
• Architecture-based Verifications: assure architecture coherence restricting the evolution of architectural design
• For every configuration capability a related Verification– Layer Selection Layering Verifications– Component Type Component Type Verification– Functionality Selection Functionality Arch.Consistency– Component Settings 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
Configuration and ManagementConfiguration and Management
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 25Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 25
Management DesignManagement Design
Configuration and ManagementConfiguration and Management
ManualConfiguring
Monitoring
MainChecker
Settings Checker
Layer Style Checker
Comp Type Checker
Event Translation
Con
fig. D
ata Routing Layer
Topology Layer
Network Layer
Broker Layer
Application Layer
Running NS Broker(s)
output
input monit
update
Life
Cyc
leM
anag
.
Mai
n M
anag
er
ConfiguringVerification
Management
output
Com
p.C
onfig
.
AgendaAgenda
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
Rebeca EncapsulationRebeca 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.
• 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.
Case Study/Framework UsageCase Study/Framework Usage
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 27Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 27
Flooding Simple Identity Covering Merging
Static tree
Broker
Routing
Topology
Network
Man
agem
ent
ApplicationApplication
Network TCP
RebecaContent-B
Channels
Encapsulation ImplementationEncapsulation Implementation• Different design found• Similitudes: Routing, Application• Lower design intersections:
– Broker/Network, Topology/Routing
• Not all interfaces used• Map data types, Main comp. types
• Different design found• Similitudes: Routing, Application• Lower design intersections:
– Broker/Network, Topology/Routing
• Not all interfaces used• Map data types, Main comp. types
Case Study/Framework UsageCase Study/Framework Usage
EventRouter
RoutingEngine
EventTransport
EvRoutingConn
EventTransport
EventTransport
EventBroker
EventBroker
L. Broker A L. Broker BRouter
Application
Broker
Routing
Topology
Network
Framework Usage ToolsFramework Usage Tools
Case Study/Framework UsageCase Study/Framework Usage
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 29Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 29
•NS Creation
Framework Usage ToolsFramework Usage Tools
Case Study/Framework UsageCase Study/Framework Usage
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 30Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 30
•NS Creation•Component Life Cycle Management
Framework Usage ToolsFramework Usage Tools
Case Study/Framework UsageCase Study/Framework Usage
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 31Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 31
•NS Creation•Component Life Cycle Management•Component Configuration
AgendaAgenda
IndexIndex
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
• Introduction• Motivation• Goals• Framework Design • Deployment & Runtime• Configuration and Management• Case Study / Framework Usage• Conclusions and Future Work
ConclusionsConclusions• 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
• 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” 32Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 32
Conclusions and Future WorkConclusions and Future Work
ConclusionsConclusions• 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 .
• 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” 33Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 33
Conclusions and Future Work Conclusions and Future Work
Future WorkFuture 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 framework-
integrated 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.
• 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 framework-
integrated 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” 34Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” 34
Conclusions and Future Work Conclusions and Future Work
The End.. Thank you!The End.. Thank you!
Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service” Fiorentino Cristian, 2006 “Building a Configurable Pub/Sub Notification Service”
Questions?
top related