Towards Data-Aware QoS-Driven Adaptation for Service Orchestrations c 1 , Manuel Carro 1 , Manuel Hermenegildo 1 , 2 Dragan Ivanovi´ 1 Universidad Polit´ ecnica de Madrid 2 IMDEA Software Institute Madrid ICWS 2010 Miami, FL, US July 7, 2010 Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 1 / 19
Components Impacting Orchestration QoS Services can be used as components within a service composition to achieve more complex tasks. At least two groups of factors affecting composition QoS: ◮ Variations from the environment (detected by monitoring): ⋆ Bandwidth, current load and throughput, network status. ⋆ Behavior of external services (e.g., meeting deadlines?). ⋆ Usually not under designer control. ◮ The structure of the composition: ⋆ What it does with incoming requests? ⋆ Which other services it invokes and how? ⋆ Partially under designer control, known in advance. We focus on the latter aspect, and We indicate how it can be combined with the former to improve results of e.g. adaptation. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 2 / 19
Computation Cost Analysis and Services We propose applying static analysis of computation cost to service orchestrations: ◮ Traditionally: number of steps, worst-case execution time (WCET). ◮ Generalized resources : counting and measuring events ⋆ Number of iterations, number of partner service invocations, number of exchanged messages, network traffic (number of bytes sent/received). Infer upper and lower bounds (safe approximations) for computational cost / resource usage. ◮ Not based on probabilities / empirical measurements. ◮ Always a guaranteed upper or lower bound. ◮ Hopefully, the exact cost (the bounds coincide). Data Awareness: bounds expressed as functions of input data . We leverage on existing analysis tools. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 3 / 19
An Example: Car Part Reservation . q e r OK / not OK Maker 1 t r a P Cancel Request Client Provider Part req. OK / not OK Cancel Maker K Car part provider serves client (an assembly line) by reserving a number of car parts of different types from different makers. The protocol requires reserving one car part type at a time. If a maker answers with “not OK,” the provider sends “Cancel” messages for all reserved parts and moves to the next maker. Total time depends (among other things) on number of parts (in the input message) and characteristics of individual makers. Time-oriented adaptation: try first maker which gives the lowest time for a given situation. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 4 / 19
Computation Cost of Service Networks T B 1 ( n ) = n + 1 B 1 Input message abstracted as the ? B 1 o t g n number of parts n . d i n b i T A ( n ) = 2 n + 3 + nS ( n ) A binding to B 2 ? Time T A for provider ( A ) depends on n and the time S ( n ) of the B 2 T B 2 ( n ) = 0 . 1 n + 7 chosen maker ( B 1 or B 2 ). 140 QoS / Comp Cost for A+B1 Structural part 2 n + 3 in T A does QoS / Comp Cost for A+B2 120 not depend on the choice of maker. QoS / Computational Cost 100 The graph shows the QoS / computation cost for two possible 80 bindings: 60 T A with B 1 ( n ) = 2 n + 3 + n ( n + 1) 40 = n 2 + 3 n + 3 20 T A with B 2 ( n ) = 2 n + 3 + n (0 . 1 n + 7) 4 5 6 7 8 9 10 Input data size (for a given metric) = 0 . 1 n 2 + 9 n + 3 Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 5 / 19
Computation Cost of Service Networks (cont.) Computation cost information for B 1 and B 2 can be made available together with other service-related information (e.g., WSDL extensions): ◮ Cost expressed as function of some metrics of input data. ◮ Relationships between the size of input and output data (when they exist). A should in turn publish synthesized information (for reuse in other compositions involving A ). Such abstract descriptions of computation cost do not compromise privacy of implementation details. ◮ They act as higher-level contracts on composition behavior. Providers that publish the computation cost information would enjoy an advantage in an open service ecosystem. ◮ Customers can make better decisions on which services to bind to. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 6 / 19
Approximating Actual Behavior With Upper and Lower Bounds Automatic analysis often can only determine safe upper and lower bounds . Exact cost function somewhere in between. 140 Upper bound QoS / Comp Cost for A+B1 Assumption: different instances of Lower bound QoS / Comp Cost for A+B1 Upper bound QoS / Comp Cost for A+B2 the same event type contribute 120 Lower bound QoS / Comp Cost for A+B2 QoS / Computational Cost equally to the overall computation 100 cost. 80 Safe cost bounds are combined 60 with current environment 40 parameters from monitoring (e.g., network speed) to produce QoS 20 4 5 6 7 8 9 10 bounds. Input data size (for a given metric) QoS ≈ cost ⊗ environment not strictly safe, but: ◮ More informed than data-unaware, single point predictions, static bounds, or averages. ◮ Can be used to predict future behavior of a composition. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 7 / 19
Benefits of the Upper/Lower Bounds Approach QoS QoS Good for aggregate measures. Focus: Usually simpler Average to calculate. Case Not very informative for individual running Input data measure Input data measure instances . QoS QoS Can be combined with the average case approach. Focus: Upper/ More difficult to Lower calculate. Bounds Useful for monitoring / adapting individual Input data measure Input data measure running instances . Insensitive to Input Data Sensitive to Input Data General idea: More information ⇒ more precision Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 8 / 19
Benefits of the Computation Cost Approach Statistical, data-mining based approach: structure and environmental factors contribute to QoS variability: Enviroment factors Structural factors QoS ◮ Hard to separate structural & environmental variations. ◮ Whole range of input data may not be represented / sampled. ◮ Runs may not be representative. ◮ Results reflect historic variations in the environment. Computation cost approach: safe approximations of structural contributions. Enviroment factors Structural factor bounds QoS ◮ Structural and environmental factors separately composed into QoS. ◮ Entire input data range accounted for. ◮ Results are safe and hold for all possible runs. ◮ Results reflect current variations in the environment. ◮ Challenge: avoid loss of precision (minimize over- or under-approximation). Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 9 / 19
Overview of the Analysis Process Feedback Translation Analysis WSDL T r a n s l a t i o n Intermediate Logic Analysis n o t i a language program s l results a n r T BPEL Feedback Service / orchestration descriptions represented in intermediate language. Intermediate representation translated into (annotated) logic program. ◮ Independence from initial language. ◮ Can capture just the relevant characteristics of the orchestration. Logic program analyzed for generalized resource consumption. Analysis results useful to drive adaptation, predictive monitoring, matchmaking, and other mechanisms that can be driven by QoS. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 10 / 19
Current Restrictions on Input Orchestrations (Working around them) Orchestrations must follow receive-reply interaction pattern: ◮ All processing between reception of the initiating message and dispatching of (final) response. ◮ Applicable to processes that accept one among several possible input messages. ◮ Future work: relax restriction by using fragmentation to identify/separate reply-response service sections. Orchestration must have no stateful callbacks: ◮ I.e., no correlation sets / WS-Addressing. ◮ Practical problem: current analyzers lose precision when passing opaque objects containing state. ◮ Future work: improve translation and analysis itself. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 11 / 19
BPEL-Style Orchestration Definitions Intermediate language (partially) reflects BPEL: Data Types: XML-style data structures with basic (string, boolean, number) and complex types (structures, lists, optionality). Expression language: XPath restricted to child/attribute navigation that can be resolved statically. Basic arithmetic/logical/string operations. Basic constructs: assignment, sequence, branching, and looping. Partner invocation: invoke follows the synchronous pattern. The moment of reply reception is not accounted for. Scopes and fault handlers: usual lexical scoping and exception processing. Parallel flows: using logical link dependencies. Compensation Handlers We currently do not support BPEL-style compensation handlers that operate on past snapshots of scope/loop iteration variables. Without snapshots, compensations can be inlined at the place of invocation. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 12 / 19
Recommend
More recommend
