Context Management in Event Marketplaces

Information Management Unit / ICCS of NTUA www.imu.iccs.gr

7th International Workshop on Semantic Business Process Management

Context Management in Event Marketplaces
Yiannis Verginadis
Ioannis Patiniotakis
Nikos Papageorgiou
Dimitris Apostolou
Gregoris Mentzas
Nenad Stojanovic

FZI Forschungszentrum
Information Management Unit Informatik, Karlsruhe,
Institute of Communication and Germany
Computer Systems
National Technical University of Athens


Overview of presentation

 Introduction

 Situation-Action-Networks (SANs)

 Event-based Context Management

 Illustrative Scenario

 Conclusions


Introduction

 Context is “any information that can be used to characterize the
situation of an entity, i.e., a person, place, or object that is
considered relevant to the interaction between a user and an
application, including the user and applications themselves.” [1].

 Events from event marketplaces are an important source of context
for service-based applications and systems that consume them
because they may convey important information, which is relevant
for service execution and adaptation.

[1] Dey, AK & Abowd, GD: Towards a Better Understanding of Context and Context-Awareness, In Proceedings of
the PrCHI 2000 Workshop on the What, Who, Where, When, and How of Context-Awareness, pp. 304-307 (2000)


The Event Marketplace (1/2)
 Event-driven World: services exchange events asynchronously
 Events are input for services
 Just as Services should be tradable, so should events
 To receive events, the sources of events must be known
 A marketplace like a search engine provides visibility to distributed
sources of events

 Nowadays, Everything can generate Events


The Event Marketplace (2/2)

 A platform offering a service based architecture, for maintaining
subscriptions (along with their cost), receiving and relaying event
notifications with the aim of different and distributed event sources
integration (e.g. Pachube).


Motivation

 Not everything can be captured at design time
 but we can predefine the Goals to be pursued and achieved
 Unexpected or non-ordinary situations must be identified
 from streams of events exchanged in SBA environment and structure
 they are usually not considered at design-time
 Selection of (re)Actions to the unexpected situations at runtime
 exploiting the current application context information originating from…
 Identified situations; they update and enrich application context

 In previous work, we have proposed Situation Action Networks
(SANs) framework


A Basic SAN

The black arrow indicates the order of visiting child nodes.
Parent is visited fist.

 Goal expresses what is pursued. I.e. the purpose of process / app
 Situation “monitors” when a situation occurs. Blocks meanwhile
 Context - Condition
 Updates and enriches app context from situation metadata
 Checks whether context conditions hold
 Action to take if situation occurs and context condition is true
 Situation-driven execution, i.e. execution when necessary


More complex SANs
Root Goal

Root Context
Situation Condition 1 Sub-Goal

Context
Situation Action
Condition 2

Root Goal

S0 CC 0 //

Sub-Goal 1 Sub-Goal 2

S1 CC1 A1 S2 CC2 A2


Event-based Context Management

 We discuss a Context Model that associates Context
elements with Events and SANs
 We provide two approaches for acquiring context from
simple or complex events and instantiating our context
model. Both approaches use the SAN Editor for:
 defining SPARQL queries to specific RDF event payload
information that can update the values of an entity’s context
elements
 defining SANs that can use information from several event
streams, analyse them and/or combine them with external
services, in order to update the derived values of context
elements. In this way, we succeed in acquiring higher level
context compared to the lower level information that events
carry.


Context Model (1/2)

 We extend and use a context model for facilitating
event-based context detection and derivation
functionality,
 in order to better understand situations in dynamic service
oriented environments that demand for new additional
information sources or/and lead to a number of service
adaptations as means for successfully coping with dynamic
environmental changes.
 This model is based on the W4H model [9] that
describes the five main elements associated within a
context; the five elements are arranged into a quintuple
(When, What, Where, Who, How).

[9] Truong, HL, Manzoor, A & Dustdar, S: On modeling, collecting and utilizing context information for disaster responses in
pervasive environments, In Proceedings of the 1st int. workshop on Context-aware software technology and applications, pp.
25–28 (2009)


Context Model (2/2)
 This Context Model expresses the temporal (i.e. When), spatial (i.e.
Where), declarative (i.e. Who, What) and explanatory (i.e. How) dimensions
of context having as central point of focus the notion of Entity and the
association of Context elements and Events


Context Model Lifecycle


Marine Scenario – AIS Hub (1/2)
 The International Maritime Organization (IMO) requires all vessels
to carry an AIS (Automatic Identification System) transponder on
board,
 which transmits their position, speed and course, among some other static
information, such as vessel’s name, dimensions and voyage details.
 A vast amount of real time events are available from portals
(http://www.aishub.net/ ) connected to automatic identification
systems (AIS) that contain important vessel information worldwide.


Marine Scenario – AIS Hub (1/2)


Context Model Specialization (1/2)
 In the AISHub Scenario we consider the “Vessel” as the
entity of interest.
 In order to capture contextual information related to
Vessels’ context, we have defined the following Context
Elements:
 Speed, Course, Position, Status, Distance2Port

 Context Model Specialisation using SAN Editor


Context Model Specialization (2/2)


Detecting Context

 Using SAN Editor, we are able to define SPARQL queries to
specific event payload information that update the values of an
entity’s context elements.


Context Model Instantiation for Position Context
Element


Deriving Context using SANs (1/2)
 We define a number of SANs that can use information from several
event streams and combine them with external services in order to
update the derived value class of context elements.


 Context derivation can be more complex and may involve multi-level SANs.
Upon traversal of the following SAN the derived value class of the Status
context element will be updated


Ongoing Work

 The Detection and Derivation of Context from Events is
considered essential for Event Marketplaces
 The proposed context management approach aims to
cover the increased needs of such dynamic
environments and consists the pillar of our ongoing work
regarding:
 Situation Awareness
 Dynamic Event Subscriptions Recommendations
 Service Adaptation Recommendations


Thank you for your attention!!!

Context Management in Event Marketplaces

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Context Management in Event Marketplaces

Semelhante a Context Management in Event Marketplaces (20)

Context Management in Event Marketplaces