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

S-Cube Learning Package

Monitoring Specification:
Monitoring Adaptation of Service-based
Applications

City University London

Ricardo Contreras, Andrea Zisman

www.s-cube-network.eu

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
© Ricardo Contreras, Andrea Zisman

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


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


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


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


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)


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


Learning Package Overview

 Problem Description
– Motivation

 User Context Types
 Monitor Adaptation Framework
– Overview
– Annotations
– Patterns
– Adaptation Process
– 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


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


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

– 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

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

– 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

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


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


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


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


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.


Further S-Cube Reading

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

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

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


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


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

Recommended

Recommended

More Related Content

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

Similar to S-CUBE LP: Monitoring Adaptation of Service-based Applications (20)

More from virtual-campus

More from virtual-campus (20)

Recently uploaded

Recently uploaded (20)

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