S-CUBE LP: Monitoring Adaptation of Service-based Applications
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 515 views

 

Statistics

Views

Total Views
515
Views on SlideShare
316
Embed Views
199

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 199

http://vc.infosys.tuwien.ac.at 199

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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 © 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
  • 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 © Ricardo Contreras, Andrea Zisman
  • MotivationScenario – 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 © Ricardo Contreras, Andrea Zisman
  • 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 © 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
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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) © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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– 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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… © Ricardo Contreras, Andrea Zisman
  • 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) 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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) 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • Adaptation ProcessThe adaptation process involves semi-instantiated patterns. A semi-instantiated pattern is the result of a rule pattern instantiated with eventsand fluents from an identified path in the SBA (it can be seen as amonitor 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 © Ricardo Contreras, Andrea Zisman
  • 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;} } © Ricardo Contreras, Andrea Zisman
  • Adaptation ProcessC2: 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 ifnecessary;} 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; © Ricardo Contreras, Andrea Zisman
  • Adaptation ProcessExample: consider the user in the role personal user and arepository 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 © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • 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
  • DiscussionAdvantages 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
  • DiscussionDisadvantages 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 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/ServiceWave09), 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. © Ricardo Contreras, Andrea Zisman
  • 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 © Ricardo Contreras, Andrea Zisman
  • AnnexAdditional Patterns for the different user context types can be found inhttp://vega.soi.city.ac.uk/~abdw747/MADap © Ricardo Contreras, Andrea Zisman
  • 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