Debs 2010 context tutorial
•Télécharger en tant que PPT, PDF•
2 j'aime•554 vues
This document provides an agenda for a tutorial on context aware computing and its use in event-based systems. The tutorial will be presented at DEBS 2010 on July 12, 2010. It will cover context in general, context in depth, and context in practice. Specifically, it will introduce context in pragmatics and language. It will also discuss roles of contexts in computing and event processing. Additionally, it will cover temporal, segmentation, spatial, and state contexts as well as context composition. Finally, it will discuss operational semantics of context and implementations of context in event processing and other computing areas.
Recommandé
Recommandé
Contenu connexe
Plus de Opher Etzion
Plus de Opher Etzion (20)
Dernier
Dernier (20)
Debs 2010 context tutorial
- 1. Context Aware Computing and its Utilization in Event-based Systems DEBS 2010 Tutorial - place holder To be presented in DEBS 2010 @ July 12, 2010. Opher Etzion (opher@il.ibm.com) Ella Rabinovich (ellak@il.ibm.com)
- 2. This tutorial’s agenda Part I: Context in general Introduction – context in pragmatics and language Roles of contexts in computing Introduction contexts in event processing Part II: Context in depth Introduction to Context categories Temporal context Segmentation context BREAK Spatial context State contexts Context composition Part III: Context in practice Operational semantics of context Context implementation in practice in event processing Context implementation in other computing areas Conclusion
Notes de l'éditeur
- … So in the world of software, context-aware software takes into account indirect information, in addition to its direct input – which can be service parameters for instance. Take for example automatic tow service ordering system - if your car breaks down on the side of the road, instant information about nearby tow, pushed automatically to your mobile device will be more helpful than making phone calls or surfing the net. Another example is calls routing applications - routing phone calls based on the user’s location and pre-defined preferences: at home – wire line phone, at office – IP phone or instant messaging application, at the movie theater – SMS only.
- Strategic Imperative: Proceed with gradual adoption of service-oriented architecture (SOA) and event-driven architecture (EDA) as fundamental steps in the software industry evolution to greater agility, intelligence and relevance. This slide, created by Gartner, demonstrates the evolution of software architecture over the years. You can see that during the last decade SOA and Advanced SOA were introduced, including complex event processing and extreme transaction processing. Gartner classifies CEP as advanced SOA, also called event-driven SOA. The next generation of application will be based on context – it a Context Driven Architecture generation. Having context as a first-class citizen will stimulate all these context-based types of applications to become more and more common. Presence, Mobility, Web 2.0 and Social computing applications have context and not content as a primary element.
- This slide demonstrates again the idea that context is indirectly relevant information, useful to functioning of the service but not provided to the service as part of its invocation. The service is surrounded by a context, which can come from various sources – event brokers, sensors, web feeds, social interaction logs and so on. Software capable of adding new types of context and new sources of context is the most valuable to users.
- Telecommunication applications are probably the most noticeable context applications. Smart phones can find an ATM on our way home, make a purchase, point to the nearby gas station or ping us about end of season sales as we pass a near a mall. Smart call routing systems are another example of context aware telecommunication applications, as we’ve already mentioned a couple of slides before.
- Social computing is another emerging field where context a primary element – google search for instance adjusts search results and even advertisements placement according to users search history characteristics – such as content and frequency of search. Amazon improves user experience by offering the user products based on his shopping history, location, shopping history of other relevant users (those who bought the product the user just put in his shopping bag for example), and even political and social environment. In facebook the content a user retrieves depends on his identity, membership and power of his connection to other facebook members. After talking about context in general, we will focus on context in event processing…
- The role of managing the content in each of the partitions can either fall on context service or on the agent associated with the specific context. In case of context service managing the partition’s content: Context service decides on affiliation of an object instance to a certain partition Context service saves the object instance and it’s mapping to the specific partition The context forwards the agent information on the update of the partition’s content, this information is necessary for the agent’s pattern evaluation logic In case of pattern evaluation the agent requests the content of the relevant partition from the context service, and evaluates the pattern In case of agent managing the partition’s content Context service decides on affiliation of an object instance to a certain partition The object is enriched with this context information and forwarded to the agent The agent stores the enriched object The agent performs a pattern evaluation of the relevant set of objects The first method can be better in terms of memory management – if the same event participates in several patterns, it can be maintained once The second one is betted in terms of context service and agents interactions, resulting in the reduced traffic.
- Distributed topology: We have Context service on EPA level – The context management can either be distributed between different context services or duplicated between them. In the first case we need to maintain the distribution mechanism and consider logical integrity and synchronization issues that can arise when partitioning context into several pieces. In the second case we need to maintain replications between different instances on every context state change. Both approaches – context partitioning and duplication are scalable in terms of number of agents and throughput of events. We also avoid the performance bottleneck as opposed to the centralized approach.
- Another approach combining the previous two is the hybrid approach – this architecture consists of context service component attached to each one of the agents sharing a single context data store. We can of course have several such a components – the entire system can have several groups of agents (probably logically connected agents) sharing the same context state. This approach offers both scalability typical to the distributed systems, and lack of synchronization and traffic issues typical to centralized context service architecture. Having several components of this type in our system, we can obtain a reasonable performance with relatively a small need in communicating context state changes to all interested parties.