Role of semantics in Autonomic & Adaptive Web Services and Processes

1. Role of semantics in Autonomic & Adaptive Web Services and Processes Amit Sheth LexisNexis Ohio Eminent Scholar http://knoesis.org

2. Historical work - samples • "From Contemporary Workflow Process Automation to Adaptive and Dynamic Work Activity Coordination and Collaboration", Keynote Address at the Workshop on Workflows in Scientific and Engineering applications, Toulouse, France, September 1997. • Y. Han, A. Sheth, K. Bussler, "A Taxonomy of Adaptive Workflow Management," CSCW-98 Workshop Towards Adaptive Workflow Systems, November 14, 1998. • A. Sheth, W. Aalst, and I. Arpinar, “Processes Driving the Networked Economy,” IEEE Concurrency, 7 (3), July-September 1999, pp. 18-31. Several projects in 1990s that dealt with adaptive and dynamic workflows (ADEPT, eFlow, METEOR, WAMO, etc.)

3. Talk focus • Need a rich representational framework to capture requirements and capabilities to support adaptive and autonomic services and processes • SEMANTICS • Earlier work on adaptive and dynamic workflows/business processes • What has changed? SAWSDL became W3C Candidate Recommendation last week. http://www.w3.org/2002/ws/sawsdl/

4. Organization People Agreement About Execution Technical Non Functional Functional Data/ Info. Task/ App Ontologies to Describe Service Semantics (ontologies are about agreements) • Autonomic Web Process* • Self Healing • Agile • Self Optimizing • Self Configuring • *it’s about the business, not just computing resources • http://lsdis.cs.uga.edu/library/publications/?t=Autonomic%20Web%20Processes Strategy Layer Requirement: Only Provide customer support to gold customer Strategy Layer (Corporate Strategy and Goals) Operational Layer (Modeling Business Process to provide business services) IT Layer Requirement: If cost > $$$$, customer = gold Aspect of Agreement Execution Layer (SOA Based IT Processes and Services) METEOR-S Implementation Layer (Databases, OS, etc.) Scope of Agreement Common Sense Gen. Purpose,Broad Based Domain Industry

5. Semantics for Services Lifecycle • Data/Information Semantics • What: (Semi-)Formal definition of data in input and output messages of a web service • Why: for discovery and interoperability • How: by annotating input/output data of web services using ontologies • Model References on Messages in SAWSDL • Functional Semantics • (Semi-) Formally representing capabilities of web service • for discovery and composition of Web Services • by annotating operations of Web Services as well as provide preconditions and effects • Model References on Operations in SAWSDL • Non Functional Semantics (WS-*) • (Semi-) formally represent qualitative and quantitative measures of Web process • Non- Quantitative includes security, transactions • Quantitative includes cost, time etc. • Business constraints and inter service dependencies (Domain and application ontologies) • Via attaching Semantically Enhanced Policies and Agreements to SAWSDL interfaces. • Execution Semantics • (Semi-) Formally representing the execution or flow of a services in a process or operations in a service • for analysis (verification), validation (simulation) and execution (exception handling) of the process models • using State Machines, Petri nets, activity diagrams etc. Adding Semantics to Web Service Standards, ICWS 2003

6. SAWSDL + SemPol= Semantic Templates • SAWSDL for data and functional semantics • Semantic Policy Descriptions for non-functional semantics

7. Semantic Template in action Non-Functional Semantics Data Semantics Functional Semantics Non-Functional Semantics

8. WS-BPEL, WS-Agreement, WS-Policy (Semantic) UDDI METEOR-S (MWSDI) Composition, Configuration and Negotiation Publication / Discovery Four types of semantics in services lifecycle Development / Description / Annotation Execution, Adaptation and Mediation WSDL, WSDL-S, SAWSDL, WSMO, OWL-S METEOR-S (MWSAF) Oracle BPM, activeBPEL, WSMX http://www.ics.forth.gr/isl/essw2003/talks/seth_essw_semanticwebprocess.htm

9. BPEL, WS-Agreement, WS-Policy METEOR-S (MWSCF) (Semantic) UDDI METEOR-S (MWSDI) Composition, Configuration and Negotiation Publication / Discovery Four types of semantics in services lifecycle Execution, Adaptation and Mediation Development / Description / Annotation WSDL, WSDL-S, SAWSDL, WSMO, OWL-S METEOR-S (MWSAF) BPWS4J, activeBPEL. WSMX METEOR-S Data Semantics

10. BPEL, WS-Agreement, WS-Policy METEOR-S (MWSCF) (Semantic) UDDI METEOR-S (MWSDI) Composition, Configuration and Negotiation Publication / Discovery Four types of semantics in services lifecycle Execution, Adaptation and Mediation Development / Description / Annotation WSDL, WSDL-S, SAWSDL, WSMO, OWL-S METEOR-S (MWSAF) BPWS4J, activeBPEL, WSMX METEOR-S Functional Semantics

11. BPEL, WS-Agreement, WS-Policy METEOR-S (MWSCF) (Semantic) UDDI METEOR-S (MWSDI) Composition, Configuration and Negotiation Publication / Discovery Four types of semantics in services lifecycle Execution, Adaptation and Mediation Development / Description / Annotation WSDL, WSDL-S, SAWSDL, WSMO, OWL-S METEOR-S (MWSAF) BPWS4J, activeBPEL, WSMX METEOR-S Non Functional Semantics

12. BPEL, WS-Agreement, WS-Policy METEOR-S (MWSCF) (Semantic) UDDI METEOR-S (MWSDI) Composition, Configuration and Negotiation Publication / Discovery Four types of semantics in services lifecycle Execution, Adaptation and Mediation Development / Description / Annotation WSDL, WSDL-S, SAWSDL, WSMO, OWL-S METEOR-S (MWSAF) BPWS4J, activeBPEL, WSMX METEOR-S Execution Semantics

13. Execution Semantics Data Semantics Non-Functional Semantics Functional Semantics BPEL, WS-Agreement, WS-Policy METEOR-S (MWSCF) (Semantic) UDDI METEOR-S (MWSDI) Composition, Configuration and Negotiation Publication / Discovery Four types of semantics in services lifecycle Execution, Adaptation and Mediation Development / Description / Annotation WSDL, WSDL-S, SAWSDL, WSMO, OWL-S METEOR-S (MWSAF) BPWS4J, activeBPEL, WSMX METEOR-S

14. Approaches to modeling Data Semantics • Pre-defined agreement on all data fields • Limited flexibility, hard to integrate new suppliers in process • Use a standard like Rosetta Net/ebXML • Greater flexibility, but limited to suppliers following standard • Standard may not be expressive enough for everyone's needs • Annotate data fields with domain ontologies • Most flexible, semi-automatic transformation based on ontology mapping • Ontology can be based on domain standard, while providing more flexibility and extensibility • Data mediation can be realized using XSLT transformation, addressing data heterogeneities.

15. Capturing Data semantics using SAWSDL • Annotation on input and output messages in WSDL documents • Leaf level annotation for complex types • Schema level annotation • Example of message level annotation:

16. Representing mappings for data mediation <complexType name="POAddress" wssem:schemaMapping=”http://www.ibm.com/schemaMapping/POAddress.xsl#input-doc=doc(“POAddress.xml”)”> <all><element name="streetAddr1" type="string" /> <element name="streetAdd2" type="string" /> <element name="poBox" type="string" /><element name="city" type="string" /> <element name="zipCode" type="string" /><element name="state" type="string" /><element name="country" type="string" /><element name="recipientInstName" type="string" /> </all></complexType> Address has_StreetAddress xsd:string has_City xsd:string has_Zip xsd:string WSDL complex type element OWL ontology Mapping using XSLT: Add Meena et al, ICWS 2006 as refernece. .... <xsl:template match="/"> <POOntology:Address rdf:ID="Address1"> <POOntology:has_StreetAddress rdf:datatype="xs:string"> <xsl:value-of select="concat(POAddress/streetAddr1,POAddress/streetAddr2)"/> </POOntology:has_StreetAddress > <POOntology:has_City rdf:datatype="xs:string"> <xsl:value-of select="POAddress/city"/> </POOntology:has_City> <POOntology:has_State rdf:datatype="xs:string"> <xsl:value-of select="POAddress/state"/> </POOntology:has_State>....

17. Functional Semantics • Keyword based search in UDDI • Needs human involvement • Low precision and high recall • Port Type based search in UDDI • Requires service providers to agree on port types • Less flexible, requires total agreement on method names and data type names • Template Based Semantic Discovery • Requires ontological commitment of data types and operations • Can search on any or many aspects of description+interface • Can have complex similarity measures and be used to provide ranked results based on similarity

18. Semantic Discovery • Semantic based publication and discovery • Unlike interface and operation based publication and discovery, semantics are modeled into UDDI data structures • SAWSDL descriptions can be published and template based discovery is supported.

19. Non Functional Semantics • Business and Application constraints

20. Non Functional Semantics • Does the supplier support customer’s business constraints • e.g. cost, supply time etc. • Interaction should adhere to the entities’ policies • e.g security, transactions • In case of more suppliers, domain constraints should be satisfied • e.g. a certain supplier’s parts do not work with other supplier’s parts • Non functional semantics in a semantic template: • Template level policy: Akin to service level policy. • Operation level policy: Policy for a specific operation in the template.

21. Non Functional Semantics • Used in lifecycle • Agreement Matching • Matching syntactically heterogeneous by semantically homogeneous agreements • Dynamic Process Configuration • Configuring process based on process constraint We will demonstrate how ontology-driven semantic approach supports these capabilities.

22. SWAPS: Use of Semantics in Agreement Matching An agreement is a collection of alternatives. A={Alt1, Alt2, …, AltN} An alternative is a collection of guarantees. Alt={G1, G2, ...GN} A guarantee is defined as a collection- G={Scope, Obligated, SLO, Qualifying Condition, Business Value} There is a potential match between provider and consumer alternatives if: For all requirement of one alternative, there is a capability in other alternative, which has the same scope and the same obligation and the SLO of the capability satisfies the request. “requirement(Alt, G)” returns true if G is a requirement of Alt “capability(Alt, G)” returns true if G is an assurance of Alt “scope(G)” returns the scope of G “obligation(G)” returns the obligated party of G “satisfies(Gj, Gi)” returns true if the SLO of Gj is equivalent to or stronger than the SLO of Gi An alternative Alt1 is a suitable match for Alt2 if: ("Gi) such that Gi  Alt1  requirement(Alt1, Gi)  ($Gj) such that Gj  Alt2  capability(Alt2, Gj)  scope(Gi) = scope(Gj)  obligation(Gi) = obligation(Gj)  satisfies(Gj, Gi)

23. WS-Agreement Definition and Ontology hasGuaranteeTerm An agreement consists of a collection of Guarantee terms GuaranteeTerm hasBusinessValue hasScope A guarantee term has a scope – e.g. operation of service hasObjective hasCondition Scope BusinessValue ServiceLevelObjectivev Qualifying Condition hasReward Reward Predicate There might be business values associated with each guarantee terms. Business values include importance, confidence, penalty, and reward. e.g. Penalty 5 USD Predicate A guarantee term may have a qualifying condition for SLO’s to hold. e.g. numRequests < 100 hasPenalty A guarantee term may have collection of service level objectives e.g. responseTime < 2 seconds hasImportance Penalty Parameter Parameter Unit Importance Value ValueExpression Unit Value ValueUnit ValueExpression OWL ontology Assessment Interval Assessment Interval ValueUnit TimeInterval Count Count TimeInterval Agreement represented as an instance of ontology http://www2006.org/programme/item.php?id=5022

24. Using Semantic Agreements with SAWSDL WS-Agreement Ontology Agriculture Ontology Guarantee Time QoS Crop Scope FarmerAddr BV Price SLO Quality Obligated Predicate Split Moisture Weight Less Domain Independent Greater Domain Dependent agri:moisture less 12% obligated: less 12% Adding Semantics to Agreements: Improves Monitoring and Negotiation Improves the accuracy of matching Adding Semantics to Web Services: Enables more accurate discovery and composition. GetMoisture agri:splits less 20% GetSplits GetWeight agri:weight greater 54 lbs GetPrice Input: Address WS-Agreement agri:price equals 10 USD Merchant Service WSDL-S Merchant WS-Agreement

25. SWAPS Ontologies • WS-Agreement: individual agreements are instances of the WS-Agreement ontology • Temporal Concepts: time.owl (OWL version of DAML time http://www.isi.edu/~pan/damltime/time.owl) • Concepts: seconds, dayOfWeek, ends • Quality of Service: Max Maximilien’s QoS ontology (IBM) -> Ont-Qos • Concepts: responseTime, failurePerDay • Domain Ontology: an ontology used to represent the domain http://lsdis.cs.uga.edu/projects/meteor-s/swaps/

26. Dynamic Process Configuration 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

27. 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.

28. Autonomic Web Process Vision K. Verma, A. Sheth. Autonomic Web Processes. In Proceedings of the Third International Conference on Service-oriented Computing (ICSOC), Vision Paper (invited), LNCS 3826, Springer Verlag, 2005, pp. 1-11.

29. Extending service skeleton to handle business level exceptions

30. Technical Details to Follow • Karthik Gomadam • Creating infrastructure for dynamic configuration • Identifying events from semantic templates • Prashant Doshi • MDP based approach to adaptation in Web processes.

31. Conclusions • Four types of semantics • Data, Functional, Non-Functional and Execution Semantics. • Role played in the lifecycle of Web process • Modeling data, functional and non-functional semantics using semantic templates • Capturing the four types of semantics using SAWSDL • Vision of Autonomic Web process • Modeling service execution using service skeletons. More at http://knoesis.org