Configuration and Adaptation of Semantic Web Processes

1. Configuration and Adaptation of Semantic Web Processes Kunal Verma Ph.D. Thesis Defense (6/13/2006) LSDIS Lab, Dept of Computer Science, University of Georgia Advisors: John A. Miller and Amit P. Sheth Advisory Committee: Budak Arpinar, Robert Bostrom, Ling Liu

2. Outline • Motivation • Dynamic Process Configuration • Process Adaptation • Empirical Evaluation • Conclusions, Related Work and Future Agenda

3. Motivation • Evolution of business needs drives IT innovation • Initial focus on automation led to workflow technology • In order to facilitate efficient inter-organizational processes distributed computing paradigms were developed • CORBA, JMS, Web Services • The current and future needs include: • Creating highly adaptive process that react to changing conditions • Focus on real time events and data – RFID and ubiquitous devices • Have the ability to quickly collaborate with new partners • Aligning business goals and IT processes

4. Motivation “Each enterprise will measure and aspire to its own unique level of dynamism based on its individual purpose. It is about being nimble and adaptable. A fully integrated business platform can respond faster, and completely, to change. Whether it involves fulfilling a new mandate or embracing a new market opportunity. Some organizations will push the envelope, automating event-triggered responses for highly integrated closed-loop processes, setting the stage for self-optimizing systems.” Sandra Rogers, White Paper: Business Forces Driving Adoption of Service Oriented Architecture, Sponsored by: SAP AG • Current Tools focus on allowing businesses to have greater dynamism and agility • Microsoft Dynamics, IBM Websphere Business Integration, SAP Netweaver • All of these Current focus on dynamic and agility through human interaction using GUIs • All of them list SOA (WS) as a technology for realization • The future • Move focus to greater automation • Capture domain knowledge and declaratively specify criteria for process configuration (Dynamic process configuration) • Add decision making support to process execution tools for process adaptation (Process Adaptation)

5. Web Services and Semantics • Web services deployment increasing in industry • Standards based interoperability • Loosely coupled systems • Still based on manual integration • Adding semantics can take us to the next level of automation • Use ontologies for shared understanding • Move towards semi-automated integration

6. Configuration and Adaptation – Roadmap Semantic Web Services and Processes Existing WS Standards/ Infrastructure Annotation/Representation WSDL-S/SAWSDL (02-06) Semantic Web Enablers Ontologies: Specification of conceptualization. Mode of capturing concepts and their relationships, etc. OWL: Ontology Web Language SWRL: Semantic Web Rule Language WSDL Discovery Mapping WSDL-S into UDDI (02-04) UDDI Dynamic Process Configuration Composition Creating abstract BPEL Process (03-06) BPEL Process Adaptation WS-Policy, WS-Agreement Constraint Analysis Semantic Policies (04-06) and Agreements (05-06) BPEL Engines (BPWS4J, ActiveBPEL) Dynamic Execution Service Manager based Runtime Binding (03-06)

7. Configuration and Adaptation 3a. Executable Process: Virtual partners replaced by actual services 2. Process Configuration: -Service discovery -Constraint analysis 3b. Process Execution: Monitoring of processstates during execution 1. Process Creation: Abstract process with virtual partner services and process constraints 3c. Adaptation: - Event based adaptation - Find a path from error state to goal state

8. High Level Architecture • Entities • Process Manager (PM): Responsible for global process configuration • Service Manager (SM): Responsible for interaction of process with service • Configuration Module (CM): • Discovery and constraint analysis • Adaptation Module (AM): Process adaptation from exceptions/events

9. Motivating Scenario • Consider a simplified supply chain process of a computer manufacturer • Most parts are multiple sourced (overseas and internal suppliers) • Overseas goods cheaper but greater lead times • There often exist part compatibility constraints • Choosing a certain motherboard restricts choices of RAMs, processors • Must respect relationship with preferred suppliers • Suppliers characterized as preferred or secondary • Sometimes important to maintain production schedule in the presence of delayed orders

10. Dynamic Process Configuration

11. Dynamic Process Configuration Dynamic configuration Problem Find optimal partners for the process based on process constraints – cost, supply time, etc. • Conceptual Approach • Create framework to capture represent domain knowledge • Represent constraints on the domain knowledge • Ability to reason on the constraints and configure the process

12. Dynamic Process Configuration Research Challenges • Capturing functional and non-functional requirements of the Web process (Abstract process specification) • Discovering service partners based on functional requirements (Semantic Web service discovery) • Choosing optimal partners that satisfy non-functional requirements (Constraint Analysis) • K. Verma, R. Akkiraju, R. Goodwin, P. Doshi, J. Lee, On Accommodating Inter Service Dependencies in Web Process Flow, AAAI Spring Symposium on Semantic Web Services, 2004 • R. Aggarwal, K. Verma, J. A. Miller, Constraint Driven Composition in METEOR-S, SCC 2004. • K. Verma, K.Gomadam, J. Miller and A. Sheth, Configuration and Execution of Dynamic Web Processes, LSDIS Lab Technical Report, 2005.

13. Abstract Process Specification • Specify process control flow by using virtual partners • Specify Process Constraints • Capture Functional Requirements of Services using Semantic Templates

14. Process Constraints • Constraints can be specified on a partner, an activity or the process as a whole. • An objective function can also be specified e.g., minimize cost and supply-time, etc. • Two types of constraints: • Quantitative (Q) (Time < 5 sec) • Logical (L) (preferredPartner, Security, etc.)

15. Process Constraints Feature Scope Goal Value Unit Aggregation Cost (Quantitative) Process Minimize Dollars Σ Supplytime (Quantitative) Process Satisfy < 7 Days MAX Cost (Quantitative) Activity Satisfy <200000 Dollars Σ PreferredSupplier(P1) (Logical) Partner 1 Satisfy True Compatible (P1, P2) (Logical) Process Satisfy True

16. Semantic Templates Part of Rosetta Net Ontology • Semantic Templates capture the functionality of a Web service with the help of ontologies/other domain models • Find a service that sells RAM in Athens, GA. It must allow the user to return and cancel, if needed • The template can also have non-functional (QoS) requirements such as response time, security, etc. WSDL-S is used to capture semantic templates Data SemanticsFunctional SemanticsNon-Functional Semantics

17. WSDL-S Example ………… <xs:element name= "processPurchaseOrderResponse" type="xs:string wssem:modelReference="POOntology#OrderConfirmation"/> </xs:schema> </types> <interface name="PurchaseOrder"> <wssem:categoryname= “Electronics” taxonomyURI=http://www.naics.com/ taxonomyCode=”443112” /> <operation name=“order” pattern=wsdl:in-outmodelReference= "rosetta:#RequestPurchaseOrder" > <input messageLabel = ”processPurchaseOrderRequest" element="tns:processPurchaseOrderRequest"/> <output messageLabel ="processPurchaseOrderResponse" element="processPurchaseOrderResponse"/> <!—Precondition and effect are added as extensible elements on an operation> <wssem:preconditionname="ExistingAcctPrecond" wssem:modelReference="POOntology#AccountExists"> <wssem:effectname="ItemReservedEffect" wssem:modelReference="POOntology#ItemReserved"/> </operation> </interface> • Rama Akkiraju, Joel Farrell, John Miller, Meenakshi Nagarajan, Amit Sheth, and Kunal Verma, Web Service Semantics, WSDL-S W3C Member Submission • K. Sivashanmugam, Kunal Verma, Amit Sheth, John A. Miller, Adding Semantic to Web Service Standards, ICWS 2003.

18. Semantic Discovery • Finds actual services matching semantic templates • Implemented as a layer over UDDI [1] • Current implementation based on ontological representation of operations, inputs and outputs. • Returns ranked of services for each semantic template • Builds upon following previous discovery implementations • Extends matching presented in [2] to consider operations and service level metadata • Extends the approach presented “WSDL to UDDI Mapping” [3] to support operation level discovery [1] K. Verma, K. Sivashanmugam, A. Sheth, A. Patil, S. Oundhakar and John Miller, METEOR-S WSDI: A Scalable Infrastructure of Registries for Semantic Publication and Discovery of Web Services, JITM [2] M. Paolucci, T. Kawamura, T. Payne and K. Sycara, Semantic Matching of Web Services Capabilities, ISWC 2002.2 [3] Using WSDL in a UDDI Registry, Version 2.0.2 - Technical Note, http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.pdf

19. Semantic Discovery

20. Constraint Analysis • Operations Research has been used in industry for business process optimization • For process configuration our approach seeks to combine domain knowledge in ontologies with a standard optimization technique • Multi-paradigm proposed: • Integer Linear Programming for quantitative constraints • Semantic Web Rule Language and OWL for domain constraints • Discovered Services first given to ILP solver • It returns ranked sets of services • Then each set is checked for logical constraints using a SWRL reasoner • Sets not satisfying the criteria are rejected

21. Quantitative Constraint Analysis • Create a binary variable xij for each candidate service. • Set up constraints for the number of services chosen for each activity. • N(i) is the number of candidate services of activity ‘i’ and M is the number of activities.

22. Quantitative Constraint Analysis • Set the cost constraint on activity1 • Set the supply time constraint • Set up the objective function

23. Configuration – Quantitative Constraint Analysis

24. Logical Constraint Analysis • Use a SWRL reasoner to perform logical constraint analysis • Domain knowledge is captured as ontologies • Rules are created with the help of the knowledge in the ontology • Implemented using IBM’s ABLE and SNOBASE • SNOBASE stores OWL ontologies using ABLE Rule Language (ARL) • Our implementation is based on SWRL rules written in ARL • K. Verma, R. Akkiraju, R. Goodwin, Semantic Matching of Web Service Policies SDWP 2005 & Filed Patent • N. Oldham, K. Verma, A. Sheth, Semantic WS-Agreement Based Partner Selection, WWW 2006

25. Domain Ontology

26. Domain Ontology – Detailed View

27. Rules • Supplier 1 should be a preferred supplier. • “if S1 is a supplier and its supplier status is preferred then the S1 is a preferred supplier”. Supplier (?S1) and partnerStatus (?S1, “preferred”) => preferredSupplier (?S1) • Supplier 1 and supplier 2 should be compatible. • if S1 and S2 are suppliers and they supply parts P1 and P2, respectively, and the parts work with each other, then suppliers S1 and S2 are compatible for parts P1 and P2. Supplier (?S1) and supplies (?S1, ?P1) and Supplier (?S2) and supplies (?S2, ?P2) and worksWith (?P1, ?P2) => compatible (?S1, ?S2, ?P1, ?P2) RAM (?P1) and MB (?P2)and worksWithMB (?P1, ?P2) =>worksWith (?P1, ?P2)

28. Using Rules to resolve Heterogeneities Manufacturer Process Constraint: Availability is greater than 95% Supplier Policy: Mean Time to Recover equals 5 minutes Mean Time between failures equals 15 hours Rule: Availability = Mean Time Between Failures/(Mean Time Between Failures + Mean Time To Recover) Availability equals 99.4%. • K. Verma, R. Akkiraju, R. Goodwin, Semantic Matching of Web Service Policies SDWP 2005 & Filed Patent • N. Oldham, K. Verma, A. Sheth, Semantic WS-Agreement Based Partner Selection, WWW 2006

29. Configuration – Logical Constraint Analysis

30. Runtime Configuration Support • Phases • One to Many binding( Information gathering phase): Number of services bound to same service manager. Used for information gathering for constraint analysis • Binding (Constraint Analysis Phase): Constraint Analysis and binding optimal partner to each SM • One to One binding (Execution and adaptation phase): Normal process execution with optimal partner

31. Process Adaptation

32. Process Adaptation • Ability to adapt the processes from failures, unexpected events • Two kinds of failures • Failures of physical components like services, processes, network • Can replace services using dynamic configuration • Logical failures like violation of SLA constraints/Agreements such as Delay in delivery, partial fulfillment of order • Need additional decision making capabilities • K. Verma, A. Sheth, Autonomic Web Processes, ICSOC 2005 • K. Verma, P. Doshi, K. Gomadam, A. Sheth, J. Miller, Optimal Adaptation of Web Processes with Coordination Constraints, ICWS 2006.

33. Process Adaptation Adaptation Problem Optimally react to events like delays in ordered goods • Conceptual Approach • Maintain states of the process – normal states, error states, goal states • Capture costs while transitioning from anomalous states to goal state • Ability to decide optimal actions on the basis of state • K. Verma, A. Sheth, Autonomic Web Processes, ICSOC 2005 • K. Verma, P. Doshi, K. Gomadam, A. Sheth, J. Miller, Optimal Adaptation of Web Processes with Coordination Constraints, ICWS 2006.

34. Process Adaptation • Research Challenges • Creating a model to recover from failures and handle future events • Model must deal with two important factors • Uncertainty about when a failure occurs • Cost based recovery • Scenario • After order for MB and RAM are placed, they may get delayed • The manufacturer may have severe costs if assembly is halted. • It must evaluate whether it is cheaper to cancel/return and reorder or take the penalty of delay • Caveat: possible that reordered goods may be delayed too • Proposed Solution • Modeling decision making capabilities of Service Managers as Markov Decision Processes (MDPs)

35. Modeling Decision Making Process of Service Managers using MDPs Each Service Manager is controlled by a MDP SM-MDP = <S, A, PA, T, C, OC> , where • S is the set of local states of the service manager. • A is the set of actions of the service manager. The actions include invoking Web service operations and calling the configuration manager. • PA : S → A is a function that gives the permissible actions of the service manager from a particular state. • T : S × A × S → [0, 1] is the local Markovian transition function. The transition function gives the probability of ending in a state j by performing action a in state i. • C : S × A → R is the function that gives the cost of performing an action from some state of the service manager. • OC is the optimality criterion. We minimize the expected cost over a finite number of steps, N, also called the horizon.

36. Policy Computation • The optimal action at each state is represented using a policy. • In order to compute the policy, a value is associated to each state. • The value represents long term expected cost of performing the optimal action from that state and is calculated the following dynamic programming equation. The policy pi : S × N → R is then computed as: N is the number of steps to go and Gamma is the discount factor Algorithm developed by Bellman in 57

37. Generating States using preconditions and effects Flags Actions Events Use an algorithm similar to reachability analysis to generate states Not possible to generate without preconditions and effects

38. Generated State Transition Diagram DFA = { S, s1, F, T, A}

39. Costs and Probabilities • Costs of ordering taken from configuration module • From first two service sets • Optimal supplier and alternate supplier • Probability of delay and cost of returning and canceling taken from supplier policy • Can be represented using WS-Policy or WS-Agreement

40. Supplier Policy • The supplier gives a probability of 55% for delivering the goods on time. • The manufacturer can cancel or return goods at any time based on the terms given below. • If the order is delayed because of the supplier, the order can be cancelled with a 5% penalty to the manufacturer. • If the order has not been delayed, but it has not been delivered yet, it can be cancelled with a penalty of 15% to the manufacturer. • If the order has been received after a delay, it can be returned with a penalty of 10% to the manufacturer. • If the order has been received without a delay, it can be returned with a penalty of 20% to the manufacturer.

41. Costs and Probabilities

42. Handling Inter-Service dependencies • Since the RAM and Motherboard must be compatible, the actions of service managers (SMs) must be coordinated • For example, if MB delivery is delayed, and MB SM wants to cancel order and change supplier, the RAM SM must do the same • Hence, coordination must be introduced in SM-MDPs

43. Centralized Approach • State space created by Cartesian product of transition diagrams • Joint actions from each state • Transition probability created by multiplying states • Costs created by adding cost per action from each state • Compatible actions given rewards • Incompatible actions given penalties • Optimal but exponential with number of manager

44. Decentralized Approach • Simple coordination mechanism • If one service manager changes suppliers • All dependent managers must change suppliers • Low complexity but sub-optimal

45. Hybrid Approach • If the policy of some SM dictates it to change suppliers, the following actions happen: • it sends a coordinate request to PM • PM gets the current cost of changing suppliers or current optimal action by polling all SMs • It takes the cheapest action (change supplier or continue) • A bit like decentralized voting- will change suppliers if majority are delayed • It mirrors performance of centralized approach and has complexity like the decentralized approach

46. Dynamic and Adaptive Processes in Healthcare AM Figure and Table from a joint Amit Sheth, Prashant Doshi publication

47. Empirical Evaluation

48. Evaluating Dynamic Configuration • Evaluation with help of the supply chain scenario • Use the variations in currency exchange rates of China and Taiwan as the primary factor affecting supplier prices • Assume that process is dynamically configured every fortnight

49. Observations • Static binding • Configured at the first run and same partners are persisted with for all subsequent runs • Cost changes due to variations in currency • Dynamic binding • Dynamically configured with latest prices for all runs • With just ILP (Dynamic1) Always the lowest cost, logical constraints not guaranteed • With ILP and SWRL (Dynamic2) Lowest cost for partners satisfying all constraints

50. Results – Process Configuration 7.1% 15.2% 2.73% Average Cost Difference: 9.32%