Barbara Pernici, Politecnico di Milano Flexible and self- healing e-services February 6, 2007

Outline Introduction and Motivations Scenarios Flexible services Service selection and optimization QoS negotiation Service repair Flexible service design Future work

Adaptivity in web-based Information systems Information systems perspective: business processes, stateful services, autonomous interacting partners Projects: MAIS (Multichannel Adaptive Information Systems) WS-Diamond (EU FET STREP)

Research problems Service research: WS selection, dynamic invocation, adaptation Workflows, business processes: recovery design and execution Looking at Biplav’s terminology: Online information services scenario Composition offline design, template based Trying to improve its low adaptation and recovery characteristics

S1.op1 S1.op2 S1.op3 S2.op1 S2.op2 S2.op3 Service registry Adapti ve networ ks Flexible e- services Dynamic service selection and optimization Adaptive front- ends Context- awareness and personalization MAIS-Platform Scenario (MAIS-P)

Collect field information Sets up and coordinates teams Operation teams Mobile camp Traditional information system Central site Micro-MAIS scenario Maurizio Brioschi, Cinzia Cappiello, Massimo Legnani, Andrea Maurino, Enrico Mussi, Barbara Pernici, Nicola Simeoni, The µMAIS prototype for the risk evaluation of archaelogical heritage, presented at WWW 2006, 23rd-26th May 2006 in the Mobile developer track session.

Flexible services Dynamic service selection and invocation Service Repair

Service selection Service model Registry and matchmaking Optimization with QoS constraints QoS negotiation and contracting

E-service model Abstract service Flexible service Concrete service

Concrete Service Invoker - Scenario MAIS Client Concrete Service Invoker Platform Invoker MAIS Reflective Architecture FlightService Lufthansa Alitalia MAIS Front- End Concrete Service Invoker Location = Italy Location = Germany Wrapper V. De Antonellis, M. Melchiori, L. De Santis, M. Mecella, E. Mussi, B. Pernici, P. Plebani. (2006). A layered architecture for flexible e-service invocation”, Software & Practice Experience. vol. 36(2), C. Cappiello, M. Comuzzi, E. Mussi, B. Pernici: Context Management for Adaptive Information Systems. Electr. Notes Theor. Comput. Sci. 146(1): (2006) S. Modafferi, E. Mussi, A. Maurino, B. Pernici: A Framework for Provisioning of Complex e-Services. IEEE SCC 2004

Receive find-travel Receive book-travel Travel-Service book-travel find-travel pay-travel Receive pay-travel Service interface (+ Port types) behavior QoS

QoS model Multiattribute Dimensions definition Names, ranges User/provider preferences (weights) Carlo Marchetti, Barbara Pernici, Pierluigi Plebani: A quality model for multichannel adaptive information. WWW 2004 C. Cappiello, B. Pernici, P. Plebani. “Quality-agnostic or quality- aware semantic service descriptions?”. W3C Workhsop on Semantic Web Service Framework, Innsbruck, June 2005Quality-agnostic or quality- aware semantic service descriptions?

Selection criteria User context and preferences Fitness of functionality QoS constraints Mapping informations abstract -> concrete

Abstract Service level QoS E-service ontology XXX rif IS

URBE URBE = Uddi Registry By Example UDDI Service discovery is driven by: Keyword-based query Pre-defined taxonomies browsing URBE extends UDDI also supporting a content based query Client submits a WSDL UDDI returns a list of similar Web services D. Bianchini, V. De Antonellis, M. Melchiori, B. Pernici, P. Plebani. (2006). Ontology based methodology for e-service discovery. INFORMATION SYSTEMS. vol. 31(4- 5)

Web service Similarity URBE considers both “structural” and “semantic” similarity Structural similarity Is calculated by analyzing terms in WSDL at different levels: portType, operation, and message names More terms at the same level are related more similar are the Web services Semantic similarity discover relationships among terms Using domain specific term ontology Using generic term ontology, i.e. Wordnet Semantic plug-ins (OWL-S, WSDL-S)

Affinity: e-service publication rif XXX IS

Urbe structure

Matching: further aspects Functional (URBE) Subset of WSDL abstract part Term similarity Classification of services according to reference abstract services (clustering) QoS Request satisfied Weighted user preferences Hierarchical analytical processing M.G. Fugini, P. Plebani, F. Ramoni, ICSOC 2006 Quality of Experience (in context) As perceived by user in the execution context, not as published in registry M.G. Fugini, P. Plebani, F. Ramoni, ICSOC 2006 Carlo Marchetti, Barbara Pernici, Pierluigi Plebani: A quality model for multichannel adaptive information. WWW 2004

Concrete Service Invoker – Wrapper/Mediator Generation Wrapper FlightService WSDL Alitalia WSDL Similarity Engine Similarity Evaluation

Wrapper/mediator generation Semi-automatic construction Similarity of parameters and operations Thesaurus (terms, simple semantic annotations) Reference services Transformation of parameters structure and names Restructuring String concatenation Designer support to extract semantics derived from user interface (web page) Structural analysis of page Thesaurus Mechanism for interaction with stateful asychronous services through a flexible service are provided Rif: Enrico Mussi PhD Thesis, Politecnico di Milano, 2007

Web Service Substitution: Mediator execution Mediation Service External Data Retriever Translation Engine Input message (Warehouse 1 WSDL) Input message (Warehouse 2 WSDL) Output message (Warehouse 1 WSDL) Output message (Warehouse 2 WSDL)

Quality constraints (hard and global): cost <1000 train.reservation.cost<600 Invoke hotel.reservation Invoke train.reservation Preferred: - ACMEHotels - ItalianHotels Negotiate: - lowest price - offer request Invoke flight.reservation not latelate Probability=0.8 Probability=0.2 Service composition

Optimization problem Multi-attribute -> Simple Additive Weighting (SAW) Scoring function, scaling, weighting Transformation to a linear model, with binary variables Multiple-choice Multiple-dimension Knapsack (MMKP) Solution: decomposition (execution paths, extension of Zeng et al. 2004), Admissible solution, HEU heuristic for MMKP Constraints for stateful services Cycles – peeling vs unfolding Reoptimization Negotiation Danilo Ardagna, Barbara Pernici: Global and Local QoS Guarantee in Web Service Selection. Business Process Management Workshops 2005 D. Ardagna, B. Pernici, Dynamic Web Service Composition with QoS Constraints, special issue on "Business Processes and Services" of the International Journal of Business Process Integration and Management (IJBPIM)

Execution paths HP: unfolding dei cicli t1t1 t2t2 t4t4 t5t5 t7t7 t3t3 t6t6 Composite Service C1C1 not(C 1 ) 25% 75% Execution Path ep 2 75% t1t1 t2t2 t4t4 t7t7 t3t3 t6t6 Execution Path ep 1 25% t1t1 t2t2 t4t4 t5t5 t7t7 t3t3

Global constraints Execution time ≤ R Execution time f ≤R D Availability ≥A Price ≤ B Reputation ≥T Data Quality ≥Q

Problem formulation

Loops t1t1 1-p 0 p0p0 t2t2 1-p 1 p1p1 1-p 2 p2p t C1C1 not(C 1 ) peeling D. Ardagna, B. Pernici, technical report, Politecnico di Milano, 2006

Experimental results

Execution time (CPLEX)

Other issues Advanced optimization: Loop peeling vs unfolding Stateful services Reoptimization Reoptimization rules WS on grid Broker Business processes D. Ardagna, G. Giunta, N. Ingraffia, R. Mirandola, B. Pernici, QoS-driven Web Service Selection in Autonomic Grid Environments, (GADA'06), Montpellier, France, 2006 Danilo Ardagna, Silvia Lucchini, Raffaela Mirandola, and Barbara Pernici, Web Services Composition in Autonomic Grid Environments, BPM 2006 Workshops, LNCS 4103, pp. 370–381, 2006 Negotiation If no admissible solution found

Process Tuner - loop, branch probability - local, global constraints - quality weights - process state - verified conditions - loop numb. of it. CPLEX Ranking procedure MILP problem formulation MILP additional constraints Global plan +WS ranking BPEL Engine BPEL Specification Process Annotation MAIS Registry - candidate WS Process Traslator Negotiator Module Web Service Provider (Ardagna and Pernici 2005) Service selection and process optimization

Negotiation A) Identify an admissible solution When service selection in optimization fails Negotiation to set up a contract for service provisioning (QoS) With each selected service

Introduction Automated negotiation Negotiation is faster when performed by software agents The number of potential partners naturally grows Remove emotional and psychological tricks First approaches in the field of multi-agent computing Planning problems Economic transactions (dynamic pricing, e-auctions) Lack of comprehensive approaches in SOA context Algorithm and strategies already defined Web Service based infrastructures for automated negotiation

Automated negotiation Formalization of the problem is the main issue Negotiation objectives Features of the negotiated issue/service (single- attribute vs. multi-attribute) How can features be modified? Negotiation protocol Description of players involved Format of the exchanged messages Rules for messaging exchange (e.g. auctions vs. bargaining) Negotiation states Players’ decision model Strategies used to generate offers-counteroffers Rules to accept an offer

Negotiation for web service selection Two steps Multi-party negotiation to select the best available service Direct bilateral negotiation Marco Comuzzi, Barbara Pernici: An Architecture for Flexible Web Service QoS Negotiation. EDOC 2005 Marco Comuzzi, Barbara Pernici: Negotiation Support for Web Service Selection. TES 2004 Marco Comuzzi, PhD Thesis, Politecnico di Milano, 2007

Negotiation algorithm: example Bilateral multi-attribute bargaining algorithm Offers are selected according to a compromise strategy Strategy is symmetrical x2x2 P P x1x1 x2x2 x1x1 Offer is accepted iff

Parameters Concession Pattern Controlled by parameter β in the g(t) function Function templates parameterized for quality/utility

The Negotiator architecture

Web services contracting Contract specification (WSLA language, WS-Agreement) Describe service elements touched by the contract (portTypes, operations,…) Report guarantees (SLOs), recovery actions, penalties,… Identify monitoring third parties

Contracting EB: Extra Budget available to service customers for negotiating Service providers’ utility increases when: customers have higher available Providers declares higher costs (therefore asking for higher price) Contracts remain close to the efficiency (Pareto) frontier

Flexible services Dynamic service selection and invocation Service Repair

WS-Diamond Web Services DIAgnosability, MONitoring and Diagnosis (EU FET STREP Project ) Self-healing Web service environment Ws-Diamond (UE Project) enabling to: detect anomalous situations (network/hardware failures, Web Service failures, application failures) diagnose faults from the analysis of detected failures select the most suitable recovery action perform the selected recovery actions to reconfigure the network of services Ws-Diamond aims at supporting both choreographed and orchestrated Web service environments

Fault-Error-Failure in WS- Diamond fault error failure alarms, observables, events, symptoms, faulty behaviors, discrepancies, exceptions and WS fault messages (notification) cause state

Faults and repair actions Web Service faults and misbehaviours detection Negotiation to reconfigure the system Negotiation objectives Negotiation protocols Decision models Define a flexible web service based negotiation infrastructure Centralized manager service vs. Web Service Self healing web services (i.e. P2P negotiation)

Towards WS-Diamond Contract violation is a fault Recovery actions should be included in contract specification Composition specification should be considered the nominal behaviour of the system to be monitored (diagnosis) Classical approach: the contract manager enforces the recovery actions execution WS-Diamond approach: self-healing web services do not need a centralized service manager

Faults and self-healing

Faults and repair actions Permanent and transient faults Stateful services Black box approach for interacting processes Service management approach Focus on data exchanges

Ws-Diamond: Nodes

Ws-Diamond: A Diamond- Enabled Node Recovery Selector Diagnoser Web Service Management Interface Fault Notification Repair Actions Symptoms Event Logs Other Alarms S. Modafferi, E. Mussi, B. Pernici, SH-BPEL - A Self-Healing plug-in for Ws-BPEL engines, Middleware for Service Oriented Computing (MW4SOC) Workshop, November, 2006, Melbourne, Australia

SH-BPEL: The Process Manager Management Engine Management Interface BPEL Interface Mediator Web Service Invoker Substitution Manager Web Service Retriever Mediation Service Process Manager

Ws-Diamond and Orchestration Recovery Selector Diagnoser WS-BPEL Management Interface Web Service 1 Web Service 2 Web Service N Infrastructure-level recovery actions Process-level recovery actions

WS-Diamond and Choreography Recovery Selector Diagnoser Web Service Management Interface Recovery Selector Diagnoser Web Service Management Interface Recovery Selector Diagnoser Web Service Management Interface

Case 3: Warehouse Fault Send OrderReceive Order Split Order Check Availability On Warehouse Check Availability On Supplier Calculate Cost Supply Check Availability Calculation Service Split Service CUSTOMERSHOP WAREHOUSE 1. The WAREHOUSE is declared faulty 2. The Recovery Selector stops the SHOP and the WAREHOUSE 3. The Recovery Selector substitutes the WAREHOUSE 4. The Recovery Selector redoes the check availability activity 5. The Recovery Selector redoes all the activities up to the calculate cost activity and then resumes the process

Process-Level Recovery Actions using WS-BPEL Standard recovery mechanisms Provided by the language Specified by the designer Fault handler, compensation handler, event handler Pre-Processing recovery mechanisms Based on existing WS-BPEL constructs Inserted by designers using tags Process variable modification, single task or scope retrying, alternative paths specification, return back to defined safe points Extended recovery mechanisms Realized by external (with respect to the WS-BPEL engine) recovery modules Recovery modules interact with both the WS-BPEL engine and invoked Web services Substitution, ReInvocation, Redoing

Exceptions and Recovery actions patterns Ws-BPEL provides standard patterns for managing exceptions Specific handlers are associated with a single action or with a Scope, that is, a set of actions: Fault handler, Compensation handler, Event handler We define five patterns enabling specific recovery actions: External variable settings the ability of modifying the value of process variables by means of external messages Timeout: the specification of a time deadline associated with a task Redo Pattern: the ability of redoing a single Task or an entire Scope Future alternative behaviour: the possibility of specifying alternative paths to be followed, in the prosecution of the execution, after the reception of an enabling message Rollback and conditionally re-execution of the flow: the possibility of going back in the process to a point defined as safe for redoing the same set of tasks or for performing an alternative path. S. Modafferi, E. Conforti, COOPIS 2006

Some of the new patterns… Timeout Redo Alternative pattern Future Alternate Pattern S. Modafferi, E. Conforti, COOPIS 2006

SH-BPEL Engine The purpose is the creation of a Self-Healing extension of BPEL engines (SH-BPEL) SH-BPEL allows standard, pre-processing, and extended recovery actions It is realized without modifying existing BPEL engine code It is composed of a set of interfaces and modules that enable The communication of SH-BPEL with the Diagnoser and the Repair Action Selector The communication between extended recovery modules and the traditional BPEL engine

SH-BPEL: The Architecture SH-BPEL API B-API M-APIMessage Monitor Standard BPEL Engine PM-API Process Manager E-API

Web Service Substitution: Mediator Configuration Mediation Service Warehouse 1 WSDL URBE Registry Warehouse 1 WSDL Warehouse 2 WSDL WSDL Matcher Similarity Engine Matching Engine Warehouse 2 WSDL Warehouse 1 WSDL Mapping Document

Case 3: Warehouse Fault Send OrderReceive Order Split Order Check Availability On Warehouse Check Availability On Supplier Calculate Cost Supply Check Availability Calculation Service Split Service CUSTOMERSHOP WAREHOUSE 1. The WAREHOUSE is declared faulty 2. The Recovery Selector stops the SHOP and the WAREHOUSE 3. The Recovery Selector substitutes the WAREHOUSE 4. The Recovery Selector redoes the check availability activity 5. The Recovery Selector redoes all the activities up to the calculate cost activity and then resumes the process

Demo Structure (Case 1 and Case 3) WS-BPEL Management Interface WAREHOUSE 1 SH-BPEL WSDL 1 ≠ WSDL 2 SHOP Client SH-BPEL Administrator WSDM Subscription Invocation Notification Repair WAREHOUSE 2 Stop Resume

SH-BPEL: Details SH-BPEL API allows management actions performed by external actors (diagnosers and recovery actions selectors) Sometimes it is useful to react to anomalous situations without waiting external actions The Process Manager may work in two modes: Active mode (autonomous with initial configuration) Passive mode (external commands) Recovery actions may be classified as Instance level recovery actions (on process instances) Class level recovery actions (all process instances)

Methodology for designing self-healing services Design a process on which diagnosis can be performed and repair actions applied Point of view of repair Define management actions for process Pre-defined (safe points, changable variables, replication, …) Run time (e.g. dynamic invocation/substitution, reallocation, adjustment of QoS with negotiation…) Make process more reliable/repairable Evaluate improvement of process and costs Design of exceptions Support to diagnoser logs Notification of symptoms Local diagnosis

Design for adaptivity

Our focus on data quality Focus on process design (orchestrated) Faults Typing errors Wrong databases/information systems Misalignment of data Unavailable information services (permanent/temporary) Multiple perspectives User, provider(s)

Process Analysis In the process analysis, it is important to identify: Relevant processes Actors within their roles and their requirements In this phase we analyze actors perspectives… what are the relevant aspects for the actors involved in the process?

Process Design Reparaibility and diagnosability of a process can be enabled in its design: Initial flow modification: Exceptions, support to pre-defined repair actions Service Redundancy Insertion of quality monitoring block

Actors and their requirements In an organization, different types of users access and manipulate data. We can identify three principal categories: Enterprise consumers: users that work in the organization and are involved in the process. Supplier consumers: users and organizations that collaborate with the organizations or cooperate in common activities in reaching a common goal. User-end consumers: final users that are interested to the quality of service. Clearly, each users' category is characterized by different needs and thus different requirements as regards the set of relevant service quality dimensions and the associated minimum acceptable value.

Users’ perspective definition In order to formally model the users‘ perspective, the model combines: Fuzzy Linguistic Approach Analytical Hierarchy Process method The proposed approach is composed of the following steps: Definition of the criteria (i.e. quality dimensions) that have to be evaluated and related relevance weights along the user perspective and the process objectives; Evaluation and comparison of the different alternatives (i.e. sets defined by the different users); Ranking of the different alternatives in relation to a specific business process. The most important contributions for diagnosis are: Identification of the user class that is mostly damaged for a specific fault occured in the process. Identification of the most important dimension in each step of the process C.Cappiello, P.Ficiaro, B.Pernici “HIQM: a Methodology for Information Quality Monitoring, Measurement, and Improvement”, Proceedings of QOIS ’06

Process Design: Modeling activities and insertion of monitoring blocks The Quality Monitor Block enables the detection of different anomalies in data flows: Store message logs Where it is possible, check if quality of service dimensions Conforms to specification Meets users expectations Quality Monitor Block a ik Intdata i(k-1) Intdata ik Extdata ikj Definition of a process model that consider the overlaps among databases used locally by the different process in order to detect anomalies due to missed realignments. It enables the application of process-based action such as the change of realigment frequency. C.Cappiello, B.Pernici “A methodology for information quality management in self-healing web services”, Proceedings of ICIQ ’06.

Design of run time actions “configuration” of process execution engine + provide run time mgmt actions Run time actions we can consider: the failed service: re-invocation, re- negotiation of QoS parameters, re- allocation of the service resources  The need for a registry, for a QoS annotation Other services: workaround  The need for maintaining information about relationships among services

Example of “workaround” Request: Book a flight from Brussels to Milano Linate We search among all the services that allow booking flights from Brussels to Linate We dinamically combine different services to obtain the same results  At design time we need the specification of relationships among services

Thank you! Further references

QUESTIONS?

Concluding remarks Infrastructure definition for web service automated QoS negotiation Multi-party, auction based negotiation (WS-Coordination, BPEL4WS) Bilateral negotiation framework Web Services contracting Provisionig of a single service Composition specification Contract manager service definition

Horizontal coordination Using WS- Coordination

Horizontal coordination ACTIVATION The Negotiator sends a “coordination context” specifying the kind of coordination (negotiation) that will be initiated to the ActivationPortType of each participant The coordination context is fundamental to mark messages belonging to the same conversation REGISTRATION Each participant registers to the coordination by sending a message to the RegistrationNegotiatorPortType containing: The role assumed in the negotiation A reference to its protocol-specific handler interface PROTOCOL-SPECIFIC INTERACTIONS BPEL process for service handlers orchestration

Deployment Partitioning (Baresi, Modafferi, Maurino, 2005) Distributed orchestration (Mecella, Pernici, 2005)

Execution

Distributed Orchestration Orchestration of e-Services is based on cooperative processes It needs to be carried on, controlled and monitored by organizations but such a task can not be assigned to a single organization conversely it should be moved all along the enactment in a given time instant, only one and exactly one organization is orchestrating (i.e., coordinating) the different e-Services involved in the given cooperative process case

Process partitioning Several orchestration engines Coordination activities For asynchronous coordination of planned process partitioning Synchronization Data transfer for local operations

Other issues Contracting Monitoring Certification Pricing Single service In a community/market Billing

On going work Self-healing web services WS-Diamond project

Exceptions and self-healing

Recovery actions

Abstract Service level QoS E-service ontology

WS QoS. Candidate WS

UDDI Juddi Publishing API Finding API MAIS Registry - URBE (Uddi Registry By Example) SOAP API JAVA API Web Application Service Ontology AffinityQoS ContextChannel Eclipse … Behavior

Affinity: e-service publication

Negotiation capabilities extension Bilateral bargaining defined by a relative small set of parameters Conceder algorithms (degree of concession, weights for global utility functions) Trade-off based negotiation algorithms Store parameters in WS-Policy documents

Negotiation capabilities extension 3 Price increasing Availability decreasing

MAIS – Multichannel adaptive Information Systems

Flexible web- service environment Adaptive network Adaptive hw/sw architecture Data Management (VSDB) Web applications Front-end environment Reflective architecture MAIS reference architecture

MAIS front-end components MAIS back-end components MAIS Reflective Architecture MAIS Core front-end (traditional client) Web service MAIS-enabled node MAIS front-end components MAIS Reflective Architecture MAIS Core MAIS-enabled node MAIS back-end components MAIS Reflective Architecture MAIS Core MAIS-enabled node network Non MAIS-enabled node MAIS nodes

MAIS Reflective Architecture MAIS Front-end Environment MAIS back-end flexible web- service environment text simplification location awareness tools security support very small database design Support tools User profiles interaction design Adaptive interaction generation Adaptive web application design Adaptive context aware web application Very small databases Low power architectures Mobile flexible deployment environment Front-end adaptivity tools Adaptive networks Adaptive contents generation

MAIS Front-end Environment MAIS back- end flexible web-service environment MAIS Service Registry Matchmaker Behavioral Compatibility Engine Service Onthology Domain Onthology UDDI Registry Wrapper Repositor y Semantic Publisher Negotiator Mobile Service design environment Process partitioning Support tools Process optimizer Process Orchestrator Concrete Service Invoker Wrapper Concretizator Platform Invoker Web Services Implementations Transaction Manager Recommendation Environment User KM User profiles MAIS Reflective Architecture End User/Web application

Negotiator Negotiator: handle negotiations among concrete services to establish QoS parameters Invoked when services have declared negotiable parameters and negotiation protocol (e.g. auctions for price)

Negotiator Candidate Web Services Negotiation for web service selection Bilateral QoS negotiation

03/06/ Negotiator “policies” for negotiation information: Negotiable parameters Supported negotiation protocols Negotiation process in two phases: Horizontal coordination General negotiation context Results notification Vertical coordination Interaction dependent on protocol (e.g. auction, bilateral negotiation or many to many) Rif Comuzzi

Web Services negotiation handlers Participation to the auctions is delegated to negotiation handlers Separate business (functional) logic from negotiation logic Agents may be reused by describing them as web services

Negotiator – implementation WS-Coordination for negotiation process Negotiator has two roles: Broker of messages among participants Controller of protocol compliance

Web Services contracting Related open problems Contract parameter and service QoS specification MAIS Quality Registry QoS ontologies Service composition What’s the relation between internal and external QoS? Contract enactment/enforcement frameworks Provide a description of the module interfaces (manager service, event notification format,…) Do NOT provide the rules for recovery actions and mechanisms for their enforcement (“left to domain specific applications”)

Recovery actions

Process design: Service redundancy The service redundancy approach is based on: Identification of weak points For each weak point there is the identification of alternative candidates that meet the functional requirements. Three replacement patterns are proposed Michael C. Jaeger and Hendrik Ladner, “Improving the QoS of WS Compositions based on Redundant Services” Proceedings of NWeSP’05