Building Dynamic Models of Service Compositions With Simulation of - PowerPoint PPT Presentation

Building Dynamic Models of Service Compositions With Simulation of Provision Resources Dragan Ivanović 1 , Martin Treiber 2 , Manuel Carro 1 , Schahram Dustdar 2 1 Universidad Politécnica de Madrid 2 Technische Universität Wien S-Cube Network of Excellence – 7th Framework Program EU ER 2010 Vancouver, Canada November 3, 2010 Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 1 / 16

Web Services and Service Compositions Web Services are software components that expose their interfaces to service clients in a standards-based and platform-independent manner. ◮ XML messages, typed by XML schema definitions. ◮ Interfaces (ports, operations) abstractly described using WSDL. ◮ Message transport using SOAP/HTTP. ◮ Security, addressing, policies... ◮ But also: RESTful services, Human-Provided Services (HPS). Service Compositions can be used to put together several (specialized) services in order to achieve more complex tasks. ◮ Also exposed as services to the outside world: composability. ◮ Usually designed around the notion of business processes. ◮ Potentially long running – possibly for hours, days. ◮ Cross organizational boundaries – loose coupling. ◮ Events, asynchronous exchanges, stateful conversations. ◮ Usually expressed in a specialized language: BPEL, YAWL, etc. ◮ Choreography (global view) vs. orchestration (control passing). Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 2 / 16

QoS and SLA Quality of Service ( QoS ) describes (mostly non-functional) properties of Web services and their compositions such as: ◮ running time, ◮ cost, ◮ availability, ◮ user experience, ◮ security/privacy, etc. Expressed as: expected values, ranges, data (in)dependent. Service-Level Agreements ( SLAs ) define constraints on values of QoS attributes that the provider and the client are expected to comply with. Aspects of QoS/SLA specifications include: ◮ Definition : reference models, definition language. ◮ Assurance : prediction, proactive QoS-driven adaptation. ◮ Negotiation : contract establishment, variation, agreement. Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 3 / 16

QoS-Driven Adaptation Service adaptation can be used for introducing change on the provider’s side to meet some objectives — e.g. target QoS. ◮ Adapting process definitions : changing the logic. ◮ Selecting components/fragments : based on QoS values. ◮ Adjusting provision infrastructure : policies for up- and down-scaling computation and communication resources. From the client perspective, attributing QoS to logic, components and/or infrastructure resources is hard. Providers normally include some way of ensuring elasticity of provision resources to meet demand: different scenarios for load/request rates. Goal Develop dynamic (time-dependent) simulation models of service provision with QoS attributes, taking into account characteristics of the particular composition being served. Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 4 / 16

Orchestration Modeling Here we use (connected) !& place-transition networks ( PT-nets or /617-6, Petri Nets ), which are well understood and widely used in workflow modeling. #% !" ◮ In reality, we ask for stricter constraints w.r.t. the shape of the net. Places (circles) stand for conditions in !% #" #$ workflow execution (including start and finish ). Tokens (dots) denote running instances !$ and mark places. Transitions (squares) stand for workflow activities and fire when all input places (preconditions) are marked (stochastic choice). A step through a PT-net involves firing all transitions that can fire, and moving the corresponding tokens to new places. Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 5 / 16

Places, Transitions vs. Flows, Stocks The basic PT-nets oversimplify behavior because transition times are not taken into account (only discrete steps). In reality, transitions (activities) take definite time, while tokens (orchestration instances) do not stay in places for significant periods of time. To recover that dynamics, we use continuous-time models. ◮ Transitions are represented by stocks that measure the number of instances of the activity at any moment of time. ◮ Places are represented as flows to and from the activity stock, and measure the number of instances per second passing through. Initial Stock ( S 0 ) Inflow ( f i ) Outflow ( f o ) Stock ( S ) � t S | t = 0 = S 0 , d d t S = f i − f o ⇔ S = S 0 + 0 ( f i − f o ) d t Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 6 / 16

Conceptual Continuous-Time Model This brings us to the conceptual orchestration continuous-time model ( OCT model). 1 * OCT Model Quantity 2..* name process def value 1..* * * CCT Model Variable Aggregation composition def aggregate op 1 * 1 * Connection Rate Var Activity Var * 1 place id net rate is parameter? activity id Choreography continuous-time models ( CCT ) add an aggregate view of several compositions working together. Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 7 / 16

Overview of the Approach Sensitivity etc. Policy Testing What-If Analysis QoS Estimates Workflow Monitoring Simulation Data Definition Dynamic Petri Net Workflow Model Model Abstract Exec. YAWL BPEL BPEL Provision Resource Model Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 8 / 16

Automatic CT-Model Derivation The CT scheme for a place is simple: non-input places aggregate outputs from one or more activities. ··· p p ( t ) = ∑ m ∈ • p { o m ( t ) } It is a bit more complex for transitions with several input places. m p ( t ) : a new stock ∀ p ∈ • m ··· q t = argmin p ∈ • m { m p ( t ) } m ( t ) = m q t ( t ) d m d t m p ( t ) = p ( t ) w pm − o m ( t ) , ∀ p ∈ • m � m ( t ) / T m T m > 0 o m o m ( t ) = q t ( t ) w q t m T m = 0 Luckily, the model derivation process can be fully automated. Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 9 / 16

Composability We can easily model asynchronous message exchange between services: ··· ··· s A r A A s A e A r We can “open” the transition boxes that represent component or partner services and interpolate their CT-models. To account for failures, we can introduce failure probabilities, and a common failure sink. ··· ··· Φ φ m m m ⇒ 1 − φ m Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 10 / 16

Example p 1 A p in Formatter service AND-split Format d Service d t A ( t ) = p in ( t ) − p 1 ( t ) o F ( t ) = F ( t ) / T F p 2 p 3 p 1 ( t ) = A ( t ) / T A p 6 ( t ) = p 4 ( t ) w 4 nh + p 5 ( t ) w 5 nh F d Data Checker Calibration p 2 ( t ) = p 1 ( t ) d t G ( t ) = p 6 ( t ) − o G ( t ) Calibration Service Service Service d d t B ( t ) = p 2 ( t ) − p 8 ( t ) o G ( t ) = G ( t ) / T G C Search Service precision not ok w 5 p p 8 ( t ) = B ( t ) / T B p 7 ( t ) = p 4 ( t ) w 4 h + o G ( t )+ p 5 ( t ) w 5 h Logging Search multiple Check Service Check Service d Service Service hits w 4 mh p 3 ( t ) = p 1 ( t )+ o F ( t ) d t J p 8 ( t ) = p 8 ( t ) − p 9 ( t ) p 4 p 5 Log Service B E d d hit d t C ( t ) = p 3 ( t ) − p 4 ( t ) d t J p 7 ( t ) = p 7 ( t ) − p 9 ( t ) no hit no hit w 4 h w 4 nh w 5 nh w 5 h p 6 p 4 ( t ) = C ( t ) / T C Storage Add Service Service � d p 8 ( t ) J p 8 ( t ) ≤ J p 7 ( t ) d t E ( t ) = p 4 ( t ) w 4 mh − p 5 ( t ) p 9 ( t ) = hit p 7 ( t ) J p 7 ( t ) < J p 8 ( t ) d Machine HPS condition Service invoke Loop p 5 ( t ) = E ( t ) / T E d t H ( t ) = p 9 ( t ) − p out ( t ) Service G Add Service d d t F ( t ) = p 5 ( t ) w 5 p − o F ( t ) p out ( t ) = H ( t ) / T H p 8 p 7 Service Service Parallel Execution p 9 p out AND-join ( J ) H Storage Service Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 11 / 16

Framework Model We plug the OCT model into a modeling framework. T e Incoming Requests Rejects i R E e = R / T e T in p in = β · R / T in β Successful finishes Successful finishes p out p out S S Resource OCT Model Model F F p fail p fail Failures Failures The resource model uses the aggregations from the OCT model to model provision infrastructure capacity and load. ◮ The blocking factor ( β ) quenches the request inflow when capacities are exceeded. Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 12 / 16

Model Simulation The framework simulation model can be fed to a standard dynamic simulation tool: Simulating a set of concurrently served orchestrations under different input regimes. Running time and reliability QoS “for free”, others like cost easily derivable. Typical simulations: what-if, goal-seek, sensitivity. ◮ We are working on a custom simulation tool that is better tailored for the service setting. Ivanović, Treiber et al. (UPM, TUW, S-Cube) Dynamic Models of Service Compositions 2010-11-03 13 / 16