Matching PatternsEvaluationRationale for chosen ExpressivenessSimulation Studies ( to assess scalability )Application Behavior1.Total CostObservationsComparison of total costs below saturation point2.Cost per service requestObservations3.Cost per subscription and per NotificationHow‘hs’ and ‘as’ forwards subscriptions4. Worst-case Per-site CostSummarySIENA PrototypeComparing Siena with other related technologiesSubscription LanguagesRelated TechnologiesConclusionMatching PatternsServers assemble sequences of notifications from smaller subsequences or from single notifications.This technique requires an advertisement based semantics. •Pattern Factoring Subscription factored into elementary components. Output of factoring process is always a sequence.•Pattern DelegationServer sends out necessary subscriptions to collect the required Subpatterns and uses a monitor that will observe and distribute the occurrence of the whole pattern.Evaluation•Reasoning qualitatively about the rationale for the expressiveness of the notification selection mechanism•Performing simulation studies•Constructing a prototypeMore study required to fully validate the design, but achieved the goal of a Wide area event notification serviceRationale for chosen ExpressivenessFactors unaccounted for – Network Latency and Data Structure size(Also restricted the expressiveness of Patterns in Siena in the interests of efficiency )Factors under control – Definitions of notifications, filters, patterns and complexity of computing covering relations.Covering RelationsComplexity of determining whether a given subscription and a given notification are related by is O(n+m) where n = No. of Attribute constraints in the subscription filter m = No. of Attributes in the notificationValues of n and m small so computations negligible compared to the network costs .SIENA = SQL in terms of expressivenessSimulation Studies ( to assess scalability )Simulation Framework•Configuration of servers and clients mapped onto the sites of a wide area network•An assignment of application behaviors to objects of interest and interested partiesNetwork Configuration•Site•Costs•LinksAssumptions1. Links have constant latency2. Sites and links have infinite capacity3. Costs of computation at sites and communication through links are linear functions of loadEffect of congestion unaccounted?SitesLinksServersClientsHomogenous ArchitectureApplication BehaviorObjects of Interest executes m sequences like Interested party executes p sequences like Main purpose of simulations is to highlight the relative behaviors of the architectures and algorithms.Simulation was conducted on objects of interest and interested parties associated with only one particular kind of event.Additional kinds of events (with their own publishers and subscribers) not considered ?Why (inspite of chances of final results getting affected) ?Four event notification service architecture/algorithms:ce = centralized architecture ( omitted because total cost far outweighs that of distributed architectures )hs = hierarchical client-server with subscription forwardingas = acyclic peer to peer with subscription forwardingaa = acyclic peer to peer with advertisement forwarding1.Total CostSaturation pointTotal cost = sum of the costs of all site to site message trafficIt captures an important aspect of scalability by revealing how communication cost is impacted by increases to load presented to the service.Observations • When more than 100 interested parties, total cost constant beyond the saturation point (no additional cost incurred) - since there is an object of interest at every site• All architectures scale sub linearly when No. of Interested parties is below saturation point - since object of interest and interested party are not at the same site• As No.of Objects of interest increases, ‘hs’ performs worst when compared to ‘as’ - ‘as’ is penalized by its broadcast of subscriptions whereas ‘hs’ propagates notifications towards the root of the hierarchy and it is forced to do so whether or not interested parties exist on the other side of the root of the network• ‘aa’ depicts unstable cost profile for low densities of interested parties - objects of interest unadvertises and readvertises frequentlyOverall ‘as’ scales well and predictable under all circumstancesComparison of total costs below saturation point2.Cost per service requestAvg. per service cost = Total Cost ------------------------------------ Total number of Client requests hs does wellhs does wellas does wellas does wellObservations1. ‘ce’ unreasonable in all scenarios as compared to other architectures2. Advertisement forwarding becomes unstable for high no. of objects of interest3. For low number’s of objects of interest and interested parties, the costs are dominated by message passing costs internal to ‘SIENA’3.Cost per subscription and per NotificationAvg per subscription cost = Total cost of all subscription related messages -------------------------------------------------------- Number of subscriptions processedAvg per notification cost = Total cost of all notification related messages----------------------------------------------------------Number of notifications processed‘as’ higher cost ‘hs’ higher costHow‘hs’ and ‘as’ forwards subscriptionsIn ‘as’ a subscription is propagated throughout the network, in a network of N sites, a subscription goes through O(N) hops Cost = O(N)In ‘hs’ a subscription is forwarded upward only to the root serverCost = O(log N)4. Worst-case Per-site CostCalculated by averaging the cost of communication incurred by each siteover the 10 simulations of that scenario, and then by computing the maximumover those average per site costs‘hs’ incurs maximum per site cost than ‘as’ for high densities of objectsof interest and therefore high volumes of notificationsSummary Costs as hsPer-Subscription costHigherO(N)LowerO(logN)Worst-case per-site costLower Higher( for higher densities)Cost of ignored notificationsNil Fixed costO(log N)Cost of delivering notificationSame Same •‘hs’ performs better at low densities of interested parties that subscribe unsubscribe frequently•‘as’ performs well in the presence of ignored notificationsSIENA Prototype• Implemented in C++ and Java• Java event server based on hierarchical
View Full Document