Context Management in Event Marketplaces

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

Context Management in Event Marketplaces

Yiannis Verginadis

Ioannis Patiniotakis

Nikos Papageorgiou

Dimitris Apostolou

Gregoris Mentzas

Nenad Stojanovic

7th International Workshop on Semantic Business Process Management

Information Management Unit

Institute of Communication and Computer Systems

National Technical University of Athens

FZI Forschungszentrum Informatik, Karlsruhe, Germany


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).



Introduction




Conclusions


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

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

The black arrow indicates the order of visiting child nodes.

Parent is visited fist.


Sub-Goal

Root Goal

Root

Situation

Context

Condition 1

Situation Action Context

Condition 2

More complex SANs

Sub-Goal 2

Root Goal

S2 A2 CC2

//

Sub-Goal 1

S1 A1 CC1

S 0 CC 0



Introduction




Conclusions



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



Introduction




Conclusions


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.

http://www.aishub.net/


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



Introduction




Conclusions


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

Documents

Transcript of Context Management in Event Marketplaces