S-CUBE LP: Monitoring Adaptation of Service-based Applications

www.s-cube-network.eu

S-Cube Learning Package

Monitoring Specification:

Monitoring Adaptation of Service-based Applications

City University London

Ricardo Contreras, Andrea Zisman

© Ricardo Contreras, Andrea Zisman

Learning Package Categorization

S-Cube

Adaptation and Monitoring Principles,

Techniques and Methodologies

for Service-based Applications

Monitor and Analysis of SBA

Monitoring Adaptation of Service-based

Applications


Learning Package Categorization

Other S-Cube approaches include …

Adaptation Principles & Mechanisms

Conceptual models and taxonomies of SBA monitoring and adaptation

Reactive Adaptation

Modification in reaction to changes that already occurred

Proactive Adaptation

Modify a SBA before a deviation occurs

Context Monitoring Proactive Adaptation

Influencing factors in a SBA

http://www.s-cube-network.eu/results/deliverables/wp-jra-1.2/CD-JRA-1.2.2_Taxonomy_of Adaptation_Principles_and_Mechanisms.pdf/at_download/file

http://www.s-cube-network.eu/km/terms/r/reactive-adaptation/?searchterm=adaptation

http://www.s-cube-network.eu/km/terms/p/proactive-service-adaptation/?searchterm=adaptation

http://www.s-cube-network.eu/km/terms/c/context-monitoring

http://www.s-cube-network.eu/km/terms/p/proactive-service-adaptation/?searchterm=adaptation

Learning Package Overview

Problem Description

– Motivation

User Context Types

Monitor Adaptation Framework

– Overview

– Annotation

– Patterns

– Adaptation Process

– Evaluation

Discussion

Conclusions


Motivation


Monitoring of Service-based Applications (SBA)

– Collecting information about the execution of SBA and verifying if the system operates correctly based on system’s properties (monitor rules)

Monitoring approaches

– Assume monitor rules are pre-defined and known in advance

Monitor needs to support changes in

– SBA and services used by SBA

– Types of interactions of users with the system

– Context characteristics of the users interacting with the system

http://www.s-cube-network.eu/km/terms/m/monitoring

http://www.s-cube-network.eu/km/terms/s/service-based-application/?searchterm=service-based%20application



http://www.s-cube-network.eu/km/terms/m/monitored-property

http://www.s-cube-network.eu/km/terms/s/service

http://www.s-cube-network.eu/km/terms/c/context

Motivation Scenario


– Consider a web-Organizer (a SBA) that provides access to user email accounts and allows users to schedule activities in a calendar

– Consider the web-Organizer allows different types of users to access the system ranging from “conference planner” to “personal user”

– A user on holidays would use the web-Organizer to access her personal emails. In this case the user would be using the system in the role of a “personal user”. After coming back from holidays the same user could use the web organizer to schedule (calendar) work meeting. Now, the user would be using the system in the role of a “conference planner”.

– Since both roles imply different features of the system, different rules should be applied to monitor the correct behaviour. As a consequence changes in context may trigger the need for monitor adaptation

http://www.s-cube-network.eu/km/terms/a/adaptation

Motivation Summary


The focus of our work is on user context and its relation with

monitor adaptation. More specifically, how user context (and its

changes) result in the need for the monitor adaptation

The user plays a major role in our approach

– We consider the interaction of the user with the service-based

application

– We consider context types related to the user


Problem Description

– Motivation

User Context Types


– Overview

– Annotation

– Patterns


– Evaluation

Discussion

Conclusions


User Context Types


Context types can be classified in two groups

Direct user context types: representing information of

the characteristics of the users, including

– role, skills, need, preferences and cognition

Related user context types: representing information

that may influence user information, including

– time, location, environment

While direct user context types are intrinsic to the

user, related user context types are more related to

the general situation of the user

User Context Types


Role: It signifies a social behaviour of an individual within the domain of a

SBA

Skills: It signifies the level of expertise of an individual with respect to a

SBA

Preferences: It signifies an individual’s choice over pre-established

alternatives of computational resources, of a SBA

Needs: It signifies what an individual wants or requires from a service-

based system

Cognition: It signifies individual’s characteristics associated to the

cognitive process

Time: the moment an individual interacts with a SBA

Location: the place where an individual interacts with a SBA

Environment: the environment where a SBA is used

User Context Types


We have developed an ontology to represent the different user context

types

User context information, is represented in user context models based on

the ontology

The different context types are represented as classes, with subclasses in

some cases, and are associated with a central class representing the user

For each class their attributes and respective data types are presented

inside the class

The focus regarding the relationships is between users and context types

(not between context types)

http://www.s-cube-network.eu/km/terms/c/context-model

User Context Types (Ontology)


• Some attributes in the

model are defined as

symbols of values (e.g.,

low, medium, high),

while others support

definition of specific

values represented as

string, integer, or real

data types

User Context Types (Example)


An example of a user model based on the ontology

The example is based on

the web-Organizer; a user

called James is a personal

user (role) with an medium

cognition level (cognition).

The attributes specified for

role and cognition context

types are associated with

the user through relations

behaves-according-to and

possesses

User Context Types


Benefits of the user-centered context classification

– It focuses on user key factors previously not taken into account (e.g.

cognition). This becomes particularly useful in scenarios where the

user interacts with the SBA

– Each identified context type is general enough so it can be easily

applied to any user

– It does not exclude some well known context types (e.g. location,

time), in fact these context types fall in the category of related user

context types

http://www.s-cube-network.eu/km/terms/s/scenario


Problem Description

– Motivation

User Context Types


– Overview

– Annotations

– Patterns


– Evaluation

Discussion

Conclusions


Architectural Review


Overview


– User models are described in an XML format based on an ontology

– Patterns and rules in the repository are described in event calculus (EC),

which can be used to support behaviour representation of dynamic systems

– Rule Adaptor selects, modifies or creates rules for monitoring a particular

SBA according to the user characteristics, patterns and rules in the

repository

– The Monitor uses the set of rules from the adaptor to check the service-

based system behaviour

– The Rule Verifier: verifies if an existing rule in the repository is still a valid

rule for a service-based application

– The Path Identifier: retrieves the parts in the

specification that are related to the context type

– SLAs (service level agreements): provide the

response time information for a service/operation

http://www.s-cube-network.eu/km/terms/s/service-level-agreement/?searchterm=SLA

Annotations


Annotations are necessary to support identification of parts of

a SBA specification related to a context type

There are different ways of accomplishing this, including

– By adding extra information in the BPEL specification

– By using Semantic Web techniques

– By using Semantic Annotations techniques

We use semantic annotations

http://www.s-cube-network.eu/km/terms/s/semantic-web

http://www.s-cube-network.eu/km/terms/s/semantic-annotation

Annotations


Preserving the original syntax of the SBA specification

– An annotation is added in a different file with links to the system

specification (e.g. Xpath expressions)

– User context is checked against annotations. If there is a match, a

path in the system specification is identified

The resulting path can be the

result of a single user context

annotation or several context

annotations…

Patterns

The framework is based on the use of patterns for monitor

rules

Both patterns and rules are described in event calculus (EC),

a first order logical language useful for specifying quantitative

temporal constraints

– Using EC, the behaviour of a system is represented in terms of the

occurrence of events, i.e. messages in the service-based system and

fluents, i.e. states of the system

– The following predicates are associated to events and fluents

- Happens, meaning the occurrence of an event

- Initiates, meaning the initiation of a fluent

- HoldsAt, meaning the holding state of a fluent

- Terminates, meaning the termination of a fluent


Patterns

For each direct user context type, patterns have been created

– They are meaningful to the context to which they are associated

– They posses a unique structure, i.e. invariant, which differentiates one

pattern from another

Patterns consist of two parts

– Monitor rule: properties of a systems that need to be monitored

– Assumptions: formulae to identify system’s state information

In each pattern the events can be classified as

– Operation request/response: prefix ic/ir

– Initial/last event in the SBA: ic_initial/ic_last

– User interaction: ic/ir + user_op


Examples of Patterns

For example:

– A pattern created for role focuses on the invocation of the operations

present in an identified path (the bold part represents the invariant)

– The pattern in the rule part, means that an invocation of an initial

operation, initialeventE, is followed by an invocation of a posterior

operation operX

– The pattern in the assumption part, means that a state, fluent, is

initiated when an invocation operX occurs

– The pattern is applied to all operations in the identified path


Monitor Rule:

Happens (ic_initialeventE, t1, R(t1,t1)) Happens (ic_operX, t2, R(t1,tn))

Assumption:

Happens (ic_operX, t, R(t, t)) Initiates (ic_operX, fluent, t)

Note: additional patterns can be found in the annex

Examples of Patterns

For example:

– A pattern created for cognition focuses on the response time of a user

operation after a certain period of time (bold part represents the invariant)

– The pattern, in the rule part, means the invocation of a user operation

and response of the user operation, should occur in a defined time

– The pattern, in the assumption part, means a state, fluent, is initiated

when the invocation of a user operation occurs

– The pattern is applied to user operations in the identified path


Monitor Rule:

Happens (ic_OperX_user_op, t1, R(t1, t1))

Happens (ir_OperX_user_op, t2, R(t1, t1+(response time for OperX_user_op)))

Assumption:

Happens (ic_OperX_user_op, t1, R(t1, t1))

Initiates (ic_OperX, fluent, t1)

Note: additional patterns can be found in the annex

Patterns

Applying the role pattern for the web-Organizer example (user

in the role of a personal user)


Monitor Rule: Happens (ic_Start Web-Organizer, t1, R(t1,t1))

Happens (ic_User-Selection, t2, R(t1,tn))

Assumption: Happens (ic_User-Selection, t, R(t, t))

Initiates (ic_User-Selection, User-Selection, t)


Happens (ic_email-accounts, t2, R(t1,tn))

Assumption: Happens (ic_email-accounts, t, R(t, t))

Initiates (ic_email-accounts, email-accounts, t)

Note: the variable of

‘tn’ in the above rules

is obtained from the

SLAs specifications

Patterns

When two or more context types have been defined. Similarly

a user with the role of a personal user and cognition defined

as medium would result in having the same rules as before,

plus the one related to the cognition pattern


Monitor Rule: Happens (ic_User-Selection, t1, R(t1, t1))

Happens (ir_User-Selection, t2, R(t1, t3))

Assumption: Happens (ic_User-Selection, t1, R(t1, t1))

Initiates (ic_User-Selection, User-Selection, t1)

Note: User Selection implies ‘user

interaction’ and therefore a rule

associated to cognition can be

applied; t3 represents the time

obtained from the SLAs and the

user level of cognition

Adaptation Process


Some (not unreasonable) assumptions

1. SBA involves a set of context types (e.g. defining an a priori

execution, during user interaction with the system)

2. A set of general set of context types has already been identified

3. It is possible to identify and relate parts of the SBA (e.g. a path in

the specification including several operations from different

services) with context types (e.g. the role of a user)

4. User context information is available, i.e. the value of a user

context type, such as role, is known

Adaptation Process


The adaptation process involves semi-instantiated patterns. A semi-

instantiated pattern is the result of a rule pattern instantiated with events

and fluents from an identified path in the SBA (it can be seen as a

monitor rule without the time constraints specified).

The adaptation process consists of

Identifying the path in the SBA associated to the context types

Applying the corresponding rule pattern and generating a semi-

instantiated pattern

Comparing the semi instantiated pattern with rules in a repository

and as a result of the comparison a rule can be

Identified

Modified

Created

Removed

http://www.s-cube-network.eu/km/terms/a/adaptation-mechanisms

Adaptation Process


Identify semi-instantiated pattern;

Search for rules that match semi-instantiated pattern

(SI);

C1: repository has rules Set(R) that fully match SI pattern

/*verify if time values in rules are consistent */

For every rule R in Set(R){

if time values in rules are consistent

{rules maintained in the repository;}

if time values in rules are not consistent

{rules are modified with new time values based on

SLAs/historical execution data;}

}

Adaptation Process


C2: repository has rules Set(R) that only match invariant part

of SI pattern

create new rule by instantiating time values for SI pattern;

add new rule in repository;

/*verification of the validity of rules*/

For every rule R in Set(R){

if there is valid path in SBS specification that uses R

{time values for R are checked and adjusted if

necessary;}

if there is no valid path in SBS specification that uses R

{R is removed from repository;}}

C3: repository does not have rules that match SI pattern

create new rule by instantiating time values for SI pattern;

add new rule in repository;

Adaptation Process


Example: consider the user in the role personal user and a

repository consisting of the following 2 rules


Happens (ic_User-Selection, t2, R(t1,tn))

Assumption: Happens (ic_User-Selection, t, R(t, t))

Initiates (ic_User-Selection, User-Selection, t)


Happens (ic_SomethingElse, t2, R(t1,tn))

Assumption: Happens (ic_SomethingElse, t, R(t, t))

Initiates (ic_SomethingElse, SomethingElse, t)

The adaptation process will identify the first rule and

instantiate the time

The second rule will be removed from the repository

since there are no events in in the web-Organizer for

SomethingElse

Evaluation


We have conducted preliminary experiments to analyse the

benefits of user context types in the monitor adaptation of SBAs

– A prototype rule was implemented

– A SBA consisting of seven services, including the five direct user context

types was created

– Different the adaptation cases were considered including: identification,

modification, creation and removal of monitor rules

– Five different cases were considered including

- Variable amount of monitor rules in the repository

- Variable suitability of monitor rules

Evaluation



Problem Description

– Motivation

User Context Types


– Overview

– Annotation

– Patterns


– Evaluation

Discussion

Conclusions


Discussion

Advantages

The use of user context types provides additional information for the

generation of monitor rules capable of verifying the behaviour according to

characteristics previously not taken into consideration

The approach tackles the problem of monitor adaptation triggered by

different factors including

– Changes in the user context

– Changes of the types of interaction of the user

– Changes in the service composition

The approach can be further expanded without major difficulty

The approach does not require the modification of the service specification


http://www.s-cube-network.eu/km/terms/s/service-composition

http://www.s-cube-network.eu/km/terms/s/service-specification

Discussion

Disadvantages

Patterns must be created in EC (previous knowledge required)

It is difficulty to create complex patterns

The approach relies on the existence of context annotations for the SBA

specification



Problem Description

– Motivation

User Context Types


– Overview

– Annotation

– Patterns


– Evaluation

Discussion

Conclusions


Conclusions

Conclusions

– Framework for identifying, modifying, creating, and removing monitor rules expressed in EC

– HCI-aware monitor adaptation

– Use of rule patterns

Current/Future work

– Creation of more patterns

– Evaluation

- Performance

- Use of adapted rules

Extension of the work to support

– Adaptation of assumptions

– Adaptation due to changes of several context types

– Patterns/Rules specified in other formalisms


Some Related Work

There have been previous studies regarding context,

semantics and annotations in SBAs, earlier work includes


Antonio Bucchiarone, Cinzia Cappiello, Elisabetta Di Nitto, Raman Kazhamiakin, Valentina Mazza, and Marco Pistore. 2009. Design for adaptation of service-based applications: main issues and requirements. In Proceedings of the 2009 international conference on Service-oriented computing (ICSOC/ServiceWave'09), Asit Dan, Frederic Gittler, and Farouk Toumani (Eds.). Springer-Verlag, Berlin, Heidelberg, 467-476.

Di Pietro, I.; Pagliarecci, F.; Spalazzi, L.; Marconi, A.; Pistore, M.; , "Semantic Web Service Selection at the

Process-Level: The eBay/Amazon/PayPal Case Study," Web Intelligence and Intelligent Agent Technology,

2008. WI-IAT '08. IEEE/WIC/ACM International Conference on , vol.1, no., pp.605-611, 9-12 Dec. 2008

doi: 10.1109/WIIAT.2008.237

Eberle, H.; Foll, S.; Herrmann, K.; Leymann, F.; Marconi, A.; Unger, T.; Wolf, H.; , "Enforcement from the Inside:

Improving Quality of Business in Process Management," Web Services, 2009. ICWS 2009. IEEE International

Conference on , vol., no., pp.405-412, 6-10 July 2009 doi: 10.1109/ICWS.2009.82

Duy Ngan Le; Ngoc Son Nguyen; Mous, K.; Ko, R.K.L.; Goh, A.E.S.; , "Generating Request Web Services from

Annotated BPEL," Computing and Communication Technologies, 2009. RIVF '09. International Conference on ,

vol., no., pp.1-8, 13-17 July 2009 doi: 10.1109/RIVF.2009.5174641

M. Pistore, L. Spalazzi, and P. Traverso. A Minimalist Approach to Semantic Annotations for Web Processes

Compositions. In Proceeding of the 3rd European Semantic Web Conference (ESWC06), volume 4011 of Lecture

Notes in Computer Science (LNCS), Budva, Montenegro, 2006. Springer.

http://portal.acm.org/citation.cfm?id=1719370

Further S-Cube Reading


R. Contreras, A. Zisman, "A Pattern-Based Approach for Monitor Adaptation," swste, pp.30-37, 2010 IEEE International Conference on Software Science, Technology & Engineering, 2010

R. Contreras, A. Zisman. 2011. Identifying, modifying, creating, and removing monitor rules for service oriented computing. In Proceeding of the 3rd international workshop on Principles of engineering service-oriented systems (PESOS '11). ACM, New York, NY, USA, 43-49. DOI=10.1145/1985394.1985401 http://doi.acm.org/10.1145/1985394.1985401

Bucchiarone, C. Cappiello, E. di Nitto, R. Kazhamiakin, V. Mazza, and M. Pistore,

“Design for adaptation of Service-Based applications: Main issues and requirements,” in WEOSA 2009

Antonio Bucchiarone, Raman Kazhamiakin, Cinzia Cappiello, Elisabetta di Nitto, and Valentina Mazza. 2010. A context-driven adaptation process for service-based applications. In Proceedings of the 2nd International Workshop on Principles of Engineering Service-Oriented Systems (PESOS '10). ACM, New York, NY, USA, 50-56. DOI=10.1145/1808885.1808896 http://doi.acm.org/10.1145/1808885.1808896





Annex


Additional Patterns for the different user context types can be found in

http://vega.soi.city.ac.uk/~abdw747/MADap


Acknowledgements

The research leading to these results has

received funding from the European

Community’s Seventh Framework

Programme [FP7/2007-2013] under grant

agreement 215483 (S-Cube).
