www.s-cube-network.eu S-Cube Learning Package Monitoring Specification: Monitoring Adaptation of Service-based Applications City University London Ricardo Contreras, Andrea Zisman
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
© 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
© Ricardo Contreras, Andrea Zisman
Motivation
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
– 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
© Ricardo Contreras, Andrea Zisman
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
Learning Package Overview
Problem Description
– Motivation
User Context Types
Monitor Adaptation Framework
– Overview
– Annotation
– Patterns
– Adaptation Process
– Evaluation
Discussion
Conclusions
© Ricardo Contreras, Andrea Zisman
User Context Types
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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)
© Ricardo Contreras, Andrea Zisman
• 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)
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
Architectural Review
© Ricardo Contreras, Andrea Zisman
Overview
© Ricardo Contreras, Andrea Zisman
– 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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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)
© Ricardo Contreras, Andrea Zisman
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)
Monitor Rule: Happens (ic_Start Web-Organizer, t1, R(t1,t1))
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
Example: consider the user in the role personal user and a
repository consisting of the following 2 rules
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)
Monitor Rule: Happens (ic_Start Web-Organizer, t1, R(t1,t1))
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
Learning Package Overview
Problem Description
– Motivation
User Context Types
Monitor Adaptation Framework
– Overview
– Annotation
– Patterns
– Adaptation Process
– Evaluation
Discussion
Conclusions
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
Learning Package Overview
Problem Description
– Motivation
User Context Types
Monitor Adaptation Framework
– Overview
– Annotation
– Patterns
– Adaptation Process
– Evaluation
Discussion
Conclusions
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
Some Related Work
There have been previous studies regarding context,
semantics and annotations in SBAs, earlier work includes
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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
© Ricardo Contreras, Andrea Zisman
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).
© Ricardo Contreras, Andrea Zisman