Software Architecture Styles and (Self-) Adaptation

Transcription

1 Software Architecture Styles and (Self-) Adaptation Schahram Dustdar Distributed Systems Group TU Wien 1

2 Architectural Styles Goal: Describe a family or class of architectures sharing a common pattern of structural organization Analogy to styles in civil architecture: Gothic style Russian style Contemporary style 2

3 Components Recap: Components & Connectors A component is a modular unit with well-defined interfaces which is replaceable within its environment interfaces are both required and provided Connectors A connector is an abstraction mediating communication, coordination, cooperation among components that is, anything providing a mechanism for interaction among components Putting together components and connectors... produces a huge range of possible organisations (topology and constraints) -> configurations that are then classified in terms of architectural styles 3

4 Some Common Architectural Styles (Shaw & Garlan, 1996) Dataflow Systems Pipes and Filters Batch Sequential Call-and-Return Systems Main Program and Subroutines Object-based architectures Layered architectures Event-based architectures 4

5 Some Common Architectural Styles (Shaw & Garlan, 1996) Independent Components Communicating Processes Client / Server Peer-to-peer Event Systems Implicit Invocation Virtual Machines Interpreters Rule-based Systems 5

6 Some Common Architectural Styles (Shaw & Garlan, 1996) Data-Centered Systems (Repositories) Databases Hypertext systems Blackboards 6

7 Example Style: Pipes and Filters One component type: Filter Filters incrementally transform streams of input data into streams of output data One connector type: Pipe Pipes move data from a filter output to a filter input The styles has a number of invariants: 1. Filter are independent units of computation: External data is only given into the system using inputs and outputs 2. The identity of other filters are unknown to a filter 3. Filters can only be combined through pipes 7

8 Example Style: Pipes and Filters Example for a Pipes and Filters Topology: Pipes & Filters is the primary style supported by Unix. Example: Filter Pipe Filter cat /var/log/messages grep sshd 8

9 Basic idea Layered architecture Components are organised in a layered fashion where components of a layer only call components of the layer below, and are only called by the components of the layer above Data flow The request-response flow is always top-down / bottom-up Control flow follow the same pattern along with data 9

10 Object-based architectures Basic idea Components are objects Components are connected through a RPC mechanism Client-server architectures... are built out of this style Layered and object-based architectures are the most important styles for distributed systems today However, a lot of things are going to happen in the future, which may change such an overall picture 10

11 Data-centered architectures Basic idea Communication among processes occurs through a shared repository The repository might be either passive (reactive) or (pro)active Main features... depends on the choice made for the shared repository how information is represented how events are handled how the shared repository behaves in response to interaction how processes interact with / through the shared repository Examples are everywhere Web-based systems, for instance, are largely data-centric Also, many distributed applications still work by sharing files around the network 11

12 Basic idea Event-based architectures Processes communicate through an event bus through which events are propagated possibly carrying data along Main example: Publish / subscribe systems Publishers publish events through the middleware Subscribers receive events to which they have subscribed Main feature Processes can communicate with no need of reference to each other / to know each other, they are referentially decoupled Processes can communicate with no need to share the same space, they are decoupled in space 12

13 Shared data-space architectures Basic idea Putting together Data-centric and Eventbased architectures The shared repository is a shared persistent data-space, and also an event bus where data is stored and accessed along with related events Main example: Blackboard systems Processes put data in the blackboard The blackboard aggregates knowledge, implements policies and drives the coordination of processes Main feature Processes can communicate Processes are also decoupled in time 13

14 Architecture vs. Middleware Main problem In practice, middleware commonly incorporates some architectural element /abstraction / component / style For instance, CORBA is designed around the object-oriented architectural style This means that middleware tends to be not adaptable to every application scenario The solution of adding different abstractions and elements affects conceptual integrity of middleware and of the resulting applications The typical solution As usual and as generic as it may seem, it is again separating mechanisms from policies This allow the behavior of the middleware to be modified according to the application needs 14

15 Architecture vs. Middleware 15

16 Main idea Adapting Middleware The problem of (unpredictable) change Any fixed solution / response may fail when facing an unpredictable modification E.g., interceptors represent a generic solution to adaptation in terms of a naive mechanism Adaptive software? Easier said than done Preparing for the unpredictable might result in quite an issue Said that, this is one of the hottest fields of research in computer science 16

17 Unknown unknowns There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns the ones we don't know we don't know Former United States Secretary of Defense Donald Rumsfeld 17

18 Toward Adaptive Software Three basic techniques [McKinley et al., 2004] 1. Separation of concerns 2. Computational reflection 3. Component-based design Separation of concerns Separating functional and non-functional concerns Non-functional properties like reliability, performance, security,... should be faced separately-> very difficult Aspect-oriented programming and aspect-oriented software development deals with cross-cutting concerns 18

19 Deployment, Architecture, and Quality of Service Deployment Architecture: allocation of s/w components to h/w hosts h c deployment architectures are possible for a given system Many provide the same functionality Provide different qualities of service (QoS) 19

20 Deployment Planning How do we find and effect a deployment architecture that improves multiple QoS dimensions? 20 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

21 Scenario with a Single QoS Dimension Latency Schedule ModifyResourceMap ResourceMonitor Objective is to minimize latency The optimal deployment architecture is deployment 1 21 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

22 Conflicting QoS Dimensions Durability Latency Schedule ModifyResourceMap ResourceMonitor Objective is to minimize latency and maximize durability There is no optimal deployment architecture! -> Pareto optimal To resolve multicritera problem -> introduce additional criteria to reconcile 22 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

23 Resolving Trade-Offs between QoS Dimensions Commander Durability Latency Schedule ModifyResourceMap ResourceMonitor A utility function denotes a user s preferences for a given rate of improvement in a QoS dimension Guiding Insight System users have varying QoS preferences for the system services they access Allows expression of optimization 23 in terms of a single scalar value

24 A Slightly Larger Scenario 24 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

25 Deployment Modeling & Configuration Interaction Path of components (e.g. procedure calls) & Network connectivity (dashed lines) 25 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

26 Modeling Architectural Elements Define sets that specify system elements and their properties Set C of software components C = {ResourcesMap, SendMessage, Display, } Set CP of software component properties CP = {size, reliability, } Other sets H of hardware nodes, N of network links, I of logical links, S of services, Q of QoS, U of users HP of hardware params, NP of network link params, CP of software component params, IP of logical link params Define functions that quantify system properties Function cparam:c CP R cparam(resourcesmap, size) = 150 Other functions hparam, nparam, IParam, sparam 26

27 Modeling QoS Dimensions Define QoS functions qvalue:s Q DepSpace R quantifies the achieved level of QoS given a deployment qvalue(schedule, Latency, Dep 1) = 1ms Define users preferences in terms of utility qutil:u S Q R [MinUtil,MaxUtil] represents the accrued utility for given rate of change qutil(commander, Schedule, Latency, 0.25) = -1 27

28 Modeling System Constraints A set PC of parameter constraints PC={memory, bandwidth, } A function pcsatisfied:pc DepSpace [0,1] 1 if constraint is satisfied 0 if constraint is not satisfied Functions that restrict locations of s/w components loc:c H [0,1] loc(c,h)=1 if c can be deployed on h loc(c,h)=0 if c cannot be deployed on h colloc:c C [-1,1] colloc(c1,c2)=1 if c1 has to be on the same host as c2 colloc(c1,c2)=-1 if c1 cannot be on the same host as c2 colloc(c1,c2)=0 if there are no restrictions 28

29 Deployment Analysis 1. Are both deployments valid? 2. Which of the two deployments is better? 3. Does the selected deployment have required properties? 29 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

30 Deployment Analysis Strategies Different strategies with different strengths Most of them offer approximate solutions 1. Mixed Integer Non-linear Programming (MINLP) 2. Mixed Integer Linear Programming (MIP) 3. Heuristic-based strategies A. Greedy B. Genetic C. Decentralized [1,2] Nemhauser, G.L., Wolsey, L.A., 1988, Integer and Combinatorial Optimization, Wiley [3] e.g.. Malek, S. et al. A Framework for Ensuring and Improving Dependability in Highly Distributed Systems, in Architeting Dependable Systems III, Springer

31 Toward Adaptive Software Computational reflection The ability to inspect oneself and possibly self-adapt behavior Reflection is at the core of modern programming languages like Java Observing the state of a program by the program itself Reification is changing the state of the program after reflection Observing own state related to the environment makes it possible to change behavior adaptively 31

32 Toward Adaptive Software Component-based design Adaptation through composition Once an architecture is open, e.g., hot-pluggable a new behavior may be added by adding a component on the fly Once an architecture for open systems is available, the point is how to select a component that may add the required behavior to the system 32

33 Automatic Adaptation Main idea Unpredictability of change makes guided adaptation essentially faulty Systems should be able to detect (relevant) change in the environment and consequently change / adapt This is the field of autonomic computing [Kephart and Chess, 2003] and of self-* systems [Babaoglu et al., 2005] Many views on self-* systems What all of them have in common is that adaptations come from a feedback loop of some sort Including some perception of the environment and of its change in the loop 33

34 Feedback Control Model 34

35 Bibliography Babaoglu, O., Jelasity, M., Montresor, A., Fetzer, C., Leonardi, S., van Moorsel, A., and van Steen, M., editors (2005). Self-star Properties in Complex Information Systems: Conceptual and Practical Foundations, volume 3460 of Lecture Notes in Computer Science. Springer. Kephart, J. O. and Chess, D. M. (2003). The vision of autonomic computing. IEEE Computer, 36(1): McKinley, P. K., Sadjadi, S. M., Kasten, E. P., and Cheng, B. H. (2004). Composing adaptive software. IEEE Computer, 37(7): Tanenbaum, A. S. and van Steen, M. (2007). Distributed Systems. Principles and Paradigms. Pearson Prentice Hall, Upper Saddle River, NJ, USA, 2nd edition. 35

36 Towards (Self-) Adaptive Software Architectures

37 Challenges of today s applications heterogeneity (SOA, GRID) large-scale (pervasive, GRID, P2P, ULS) dynamic (MANET, SOA) run continously (24*7) time to market cost pressure Human maintenance and repetitive software development processes error-prone and costly slow, sometimes prohibitively BUT: self-learning and highly adaptive ;-) dependability degradation / dependability gap 37

38 System Life Cycle revisited Development Environment: physical world, human developers, development tools, production and test facilities development faults. Use Environment: physical world, administrators, users, providers, infrastructure, intruders. Use phase: service delivery, service outage, service shutdown. Maintenance: repairs and modifications (iterative development process). Design-time/run-time convergence 38

39 Adaptivity Answer on the process level does not address runtime needs sufficiently run-time adaptivity is needed for dependability key idea 1 key idea 2 disturbance context change (environment, failures) set point user needs with respect to dependability and security properties - offset deviation controller negotiation set value actuator protocol coupling controlled system SW system actual value dependability and security properties sensor, measuring transducer measurement of dependability and security properties 39

40 Adaptive Coupling Complexity theory demands focus on structure and interaction rather than properties of the individual constituents (-> SOA) Relationships of differing strengths mixture of tightly and loosely coupled parts overall system properties are also determined by the strength of coupling inner loop provides adaptivity (balancing) by controlling the strength of coupling 40

41 Long-term evolution regulate emerging behaviour (policies) evolvement of user needs and context change the system s design while running! requires run-time accessible and processable requirements and design-views, e.g. constraints models (e.g., UML virtual machine ) -> next lecture (partial) architectural confgurations requires methods to balance and change design and implementation during run-time 41

42 Run-time software development requires middleware support for requirements stored in repositories accessed via reflection or aspect-oriented programming (dynamic aspects) or protocols for meta-data exchange APIs to change software artifacts convergence of software development tools with middleware services ( re-engineering running software ) new challenges: e.g., run-time testing and verification, e.g., see G2 42

43 Control loop Emerging techniques adaptiveness self-properties autonomic computing Software evolution convergence of design-time and run-time run-time software development Architectural dependability (e.g., P2P systems) Bio-inspired methods 43

44 Autonomic Computing Research Approach Sensors Analyze Effectors Plan Monitor Knowledge Execute Sensors Effectors 44

45 Our recent research 45

46 Distributed MAPE Looking at distributed MAPE loops like middleware looks at different software tiers. 46

47 Decentralized MAPE pattern Structural View Instance View 47

48 Master/Slave MAPE Pattern Structural View Instance View 48

49 Regional Planner MAPE Structural View Instance View 49

50 Information Sharing MAPE Pattern Structural View Instance View 50

51 Self-Healing H. Psaier, S. Dustdar (2011). A survey on self-healing systems: approaches and systems, Computing, Vol 91, pp Download at:

52 Application of self-healing Support people with the complexity of current systems Avoid design errors Avoid configuration errors Replace failing service Handle service invocation transparently to keep system healthy Support service maintenance

53 Definition of self-healing A self-healing system should recover from the abnormal (or unhealthy ) state and return to the normative ( healthy ) state, and function as it was prior to disruption. A system with self-healing properties can be identified as a system that comprises faulttolerant, self-stabilizing, and survivable system capabilities and, if needed, must be human supported.

54 Self-healing origins Fault-tolerant system refers to a system that continues working at a reasonable degree in the presence of faults Self-stabilizing system refers to a system that continuously stabilizes the system from any perturbations. Survivable systems sustain the unexpected

55 Self-healing research IBM's autonomic computing research envisions a layered structure that can manage itself to given highlevel objectives from administrators. Motivated by the amount spent on and overwhelming effort in system maintenance The research tries to cover all adaptable layers down to network and operating system Defines 4 properties for a self-managing system (self- CHOP): self-configuring: The ability to readjust itself on-the fly self-healing: Discover, diagnose, and react to disruptions self-optimization: Maximize resource utilization to meet enduser needs self-protection: Anticipate, detect, identify, and protect itself from attacks.

56 Self-healing research Self-adaptive systems evaluate their behavior and adapt on system irregularities or when better functionality or performance is possible The research primarily covers the application and the middleware layers and focuses on the system as a whole. Includes also self-healing as a combination of self-diagnosing and self-repairing with the capabilities to diagnose and recover from malfunctions.

57 Self-healing characteristics What: Continuous availability by compensating the dynamics of a running system. Why: maintenance of health momentarily and... Enduring continuity by resilience against unintentional behavior How: Detect disruptions Diagnose root cause Derive recovery strategy

58 Self-healing characteristics When: Continuously in a closedloop for timely reaction Who: System itself Human administrator by configuration, e.g., set of policies Where: Complex, unpredictably behaving systems

59 Self-healing requirements Closed loop with sensor and effector interfaces Status knowledge and state recognition Failure classification Recovery policies Fitness and evolutionary aspects

60 Self-healing loop detecting: filters any suspicious status information diagnosing: does root cause analysis and calculates appropriate recovery recovery: carefully applies the planned adaptations

61 Self-healing states Normal: Healthy system that signalizes intentional functioning of the system. Degraded: System is in a fuzzy transition zone. Drift from acceptable to failure. Recognizable by considerable loss of performance. Provides additional time for recovery. Broken: Unhealthy system with unacceptable response (failure)

62 Failure classification Assists root cause and resolving the failure Failure types: Crash failure: undetectable malign interruption Fail-stop: detected benign interruption Transient: instantaneous transparent with side-effects Omission: message loss, transmission errors Performance: violation of constrains in execution time Arbitrary: any type of failure with no specific pattern

63 Failure classification The three different types are: Action policies: no learning expected but immediate response is expected. Goal Policies: define a set of desired states. Calculate the set of actions for the transition from the current (failure affected) to a desired state Utility Function Policies: the set of states is connected to a utility. Problem solving includes history information, adaptation knowledge and a comprehensive system awareness Common recovery policies are: Replacement, balancing, isolation, persistence, redirection, relocation, diversity.

64 Fitness and evolution Current systems, especially self-* enhanced, are designed for long-term service. Issues: many requirements are not known a-priori but expose themselves and evolve over time malicious failures might restrict parts of the system s functionality to essential services adaptation might reach its limits in resources Current solution: human assisted healing

65 Summarizing Self-Healing Why is it required. What's the motivation? Increasing complexity of current systems causes...escalating costs...overwhelming effort in system maintenance...system incomprehensibility How does self-healing work. What are the requirements? Sensor and effector interfaces provide the essential awareness (self and environment) Closed loop with timely information flow State recognition: healthy, degraded, unhealthy Fault classification Policies with recovery strategies

66 Example of Self-Adaptation in Socially enhanced SOA

67 Factory Delegation Factory/Sink a accepts and delegates tasks frequently a processes few tasks and has a low task-queue Sink d accepts too many tasks d processes slow (capability vs. overload) Misbehavior impact Produces unusual amounts of task delegations Tasks miss their deadline Leads to performance degradations of the entire network Psaier H., Juszczyk L., Skopik F., Schall D., Dustdar S. Runtime Behavior Monitoring and Self-Adaptation in Service-Oriented Systems, 4th IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO'10), 27 Sept.-01 Oct. 2010, Budapest, Hungary. 67

68 (Mis)behavior monitoring Open System with varying participation All services use the communication infrastructure Interaction logging: Log the exchanged messages and process their content Logs provide information on: Task properties: id, tags, etc. Type, skills, and interests of services 68

69 Similarity Service Cos-similarity to determine the similarity of two services profile vectors: Trust mirroring: similar minded nodes tend to trust each other more than random nodes Trust teleportation: the past trust relation (u,w) teleports to others having similar interests. Note: u and w have different profile, e.g., different roles 69

70 Misbehavior adaptation initial state -> b queue overload detected -> find alternative/similar service -> (i) 1 st support b mirroring of trust -> (ii) 2 nd avoid b teleportation of trust 70

71 Self-adaptation concepts feedback loop design for misbehavior healing MAPE loop of autonomic computing: monitor interactions and queue threshold analyze behavior and compare to misbehavior models update behavior registry (part of knowledge) plan adaptive actions execute channel regulations and redirections 71

72 VieCure framework Interaction logging updates monitoring db and behavior registry. Policy Store and Similarity Service determine the adaptations Administration Adaptation/Diagnosis Monitoring/Environment Model Admin tools allow to fine-tune the framework 72

73 Adaptation - some conclusions Mixed Dynamic Systems require novel programming model composing HPS and SBS Identification of (mis)behavior patterns and protocols and composition primitives in Mixed Systems Non-intrusive adaptation of misbehavior with self-healing 73

74 Related papers 1. Trust-based Discovery and Interactions in Mixed Service-Oriented Systems Schall D., Skopik F., Dustdar S. IEEE Transactions on Services Computing (TSC), Volume 3, Issue 3, pp Modeling and Mining of Dynamic Trust in Complex Service-oriented Systems Skopik F., Schall D., Dustdar S. Information Systems Journal (IS), Volume 35, Issue 7, November 2010, pp Elsevier. 3. Programming Human and Software-Based Web Services Schall D., Dustdar S., Blake M.B. IEEE Computer, vol. 43, no. 7, pp , July Unifying Human and Software Services in Web-Scale Collaborations Schall D., Truong H.-L., Dustdar S. IEEE Internet Computing, vol. 12, no. 3, pp , May/Jun, Runtime Behavior Monitoring and Self-Adaptation in Service-Oriented Systems Psaier H., Juszczyk L., Skopik F., Schall D., Dustdar S. 4th IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO'10), 27 Sept.-01 Oct. 2010, Budapest, Hungary.

75 Related papers for adaptive SOA Moser, O., Rosenberg, F., Dustdar, S., (2011). Domain-Aware Service Selection for Composite Services, IEEE Transactions on Software Engineering, forthcoming Moser, O., Rosenberg, F., Dustdar, S., (2008). VieDAME - Flexible and Robust BPEL Processes through Monitoring and Adaptation (Informal Demo Paper). In: Proceedings of the 30th International Conference on Software Engineering (ICSE'08), May 2008, Leipzig, Germany. Moser, O., Rosenberg, F., Dustdar, S., (2008). Non-Intrusive Monitoring and Adaptation for WS-BPEL. In: Proceedings of the 17th International World Wide Web Conference (Web Engineering Track) (WWW'08), April 2008, Beijing, China. 75

76 Thanks for your attention! Schahram Dustdar Distributed Systems Group Vienna University of Technology Austria 76