A Framework for Utility-Based Service Oriented Design in SASSY

Transcription

1 A Framework for Utility-Based Service Oriented Design in SASSY The material in these slides comes from the paper A Framework for Utility-Based Service Oriented Design in SASSY, D.A. Menasce, J. Ewing, H. Gomaa, S. Malek, and J.P. Sousa, First Joint WOSP/SIPEW International Conference on Performance Engineering (WOSP/SIPEW 2010), San Jose, California, USA. January 28-30, The copyrights to this material are the authors' or the paper publisher's.

2 Topics Overview of SASSY SASSY framework Service Activity Schema (SAS) Service Sequence Scenario (SSS) System Utility Service System Architecture (SSA) Base architecture Architecture patterns and architectural adaptation Optimizing Global Utility Experimental Results Contributions

3 SASSY Framework

4 SASSY Framework Self-Architecting Software Systems - SASSY Utilizes domain ontology which must be specified ahead of time Domain expert specifies high-level processes and service goals using a visual tool. The high-level components of SASSY are for the most part easily-recognizable as analogs of other autonomic systems we have seen so far. Components specific to the system: Service Activity Schema (SAS) and Service Sequence Scenario (SSS) models Architectural Pattern Model (APM) library System Service Architecture (SSA) models

5 Service Activity Schema (SAS) An SAS defines the high-level actions the system should take. Modeling constructs are defined by the domain ontology ahead of time. An SAS is put together by a domain expert, not a software engineer.

6 Service Sequence Scenarios (SSS) Specifies desired QoS properties Specified by the domain expert Uses a list of metrics defined in the domain ontology Each SSS deals with one QoS metric.

7 System Utility Each SSS has its own local utility function specific to that QoS metric The SAS has an overall global utility function which specifies the importance of each particular QoS metric to the service goals of the application SASSY's monitoring may replace service providers or re-architect the system based on the overall system utility.

8 Service System Architecture (SSA) The SSA provides an accurate functional model of the structure and behavioral properties of a system at run-time. Structural model is based on the extensible Architectural Description Language (xadl) Extended to include the concept of service instances the realization of a service type defined in the ontology Components are drawn from a library of Architectural Pattern Models (APMs)

9 SSA (cont.) Left: An SSA model for a base architecture Right: A modification of the base architecture using a fault-tolerant component

10 Base Architecture SASSY automatically generates a base architecture which minimally fulfills the task requirements e.g., one service per activity in the SAS, plus a coordinator Base architecture probably will probably not fulfill QoS objectives well, but provides a starting point for optimization

11 Architecture Patterns / Architectural Adaptation As optimization takes place, components of the architecture may be replaced to meet QoS goals The specific service provider which services an instance may be replaced A particular piece of the architecture may be replaced with a different piece from the APM library. The number of service instances associated with multi-instance components may be changed Each piece in the APM library carries with it one or more QoS metrics, and a QoS model for each metric it influences.

12 Architectural Patterns (cont.) The fault tolerant component in the figure has availability A = 1 - ( 1 a 1 ) ( 1 a 2 ) a 1, a 2 are availability of server 1, server 2 respectively Execution time E = a 1 (1-a 2 )e 1 /A + a 2 (1-a 1 )e 2 /A + a 1 a 2 min{e 1,e 2 }/A

13 Optimizing Global Utility Build a neighborhood N Unfiltered Replace every component of every SSS with architectural patterns that improve the metric associated with that SSS. May generate large neighborhoods. Filtered Concentrate on those SSSs which provide better gains to the utility function; for instance by selecting the SSSs that exhibit the lowest numerical contribution to the global utility function.

14 Optimizing Global Utility (cont.) Search proceeds using local search methods, e.g., hill climbing. May introduce randomness to prevent getting stuck in local optima. Smaller neighborhoods from filtering increase the risk of getting stuck in local optima. A naïve filtering methodology may also concentrate on less important SSSs due to smaller numerical contribution; these may not adequately contribute to the global utility due to low weighting.

15 Experimental Results Left: Convergence rate for different filtering values Right: The final architecture of the system

16 Autonomous Adaptation SASSY will autonomously adapt to changing service conditions. In the event of degradation of service from a provider, SASSY will re-evaluate the architecture based on current data, and re-architect the system.

17 Contributions The paper itself lists several contributions Models system requirements as a high-level visual language usable directly by domain experts Maintains four types of run-time models which are synchronized with one another, and collectively support a rich set of alternatives for satisfying the system's requirements Provides a uniform approach to automated composition, adaptation and evolution of SOA systems

18 Contributions (cont.) The first and third of these contributions seem to be the most important The ability of domain experts to directly specify the desired behavior of the system is very important, in particular it ensures that information is not lost in translation between the domain experts and software engineers The introduction of a meaningful unified approach of how to model and automatically adapt the system architecture to meet the goals specified by domain experts is significant.

19 Potential Issues / Open Problems Filtering methodology the filter introduced in the paper is extremely simple, and could narrow neighborhoods in undesirable ways. Local search selection Could SASSY be employed to build self-protecting systems? In particular, modelling security concerns is treated roughly discrete utility based encryption strength and key lengths. There may potential to use SASSY to build and adapt systems that address security and vulnerability more robustly these are not typically employed as services however. Is the currently system flexible enough, or would it need to be extended to model threat evaluation and coping?