1 / 73

METEOR-S: investigations on semantics empowerment of processes

METEOR-S: investigations on semantics empowerment of processes. Amit Sheth LSDIS Lab , Dept of Computer Science, University of Georgia with the METEOR-S team; special thanks: Kunal Verma, Meena Nagarajan. Motivation. Evolution of business needs drives IT innovation

Download Presentation

METEOR-S: investigations on semantics empowerment of processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. METEOR-S: investigations on semantics empowerment of processes Amit Sheth LSDIS Lab, Dept of Computer Science, University of Georgia with the METEOR-S team; special thanks: Kunal Verma, Meena Nagarajan

  2. Motivation • Evolution of business needs drives IT innovation • Initial focus on automation led to workflow technology • The current and future needs include: • Aligning business goals and IT processes • Streamlining business processes • Having ability to quickly work with new partners • Creating adaptive process that react to changing conditions • Three of the enablers for realizing these goals: • Interoperability (with Semantic Annotation) • Dynamic process configuration • Process Adaptation

  3. Research RoadMap Semantic and Autonomic Web Processes The Future Self Configuration Self Healing Self Optimization Self Protection Our Current Focus: METEOR-S: Applying Semantics to Complete Web Process Lifecycle Semantic Web Processes Annotation/Representation Discovery Composition Execution/Adaptation Semantic Web Technologies(OWL, SWRL, RDF) Web Services Standards (WSDL, UDDI, BPEL) Standards in WS and Semantic Web

  4. Outline • Interoperability and WSDL-S • Work by Meena Nagarajan, Kunal Verma, with IBM • Dynamic Process Configuration • Work by Kunal, Karthik Gomadam • Process Adaptation • Work by Kunal, Prashant Doshi • Some Results • Conclusions

  5. Interoperability and WSDL-S

  6. Interoperability in Web services • Impediments beyond semantic composition of Web services • Message level heterogeneities between communicating Web services

  7. Message level Heterogeneities • Syntactic - differences in the language used for representing the elements • Model/Representational - differences in the underlying models (database, ontologies) or their representations (relational, object-oriented, RDF, OWL) • Structural - differences in the types, structures of the elements • Semantic - where the same real world entity is represented using different terms (or structures) or vice versa Resolved by the XML based environment WSDL-S; Semi-automatic solution

  8. Matching • Mapping • A lot of early work on heterogeneous database integration is still quite useful

  9. WSDL-S • Offer an evolutionary and compatible upgrade of existing Web services standards • Externalize the semantic domain models • agnostic to ontology representation languages • reuse of existing domain models • allows annotation using multiple ontologies (same or different domain) • updating tools around WSDL is relatively easier

  10. Semantic annotations on WSDL elements

  11. Using WSDL-S to interoperate • modelReference to establish a semantic association • schemaMapping to resolve structural heterogeneities beyond a semantic match semantic match <wsdl:types> (...) <complexType name=“Address"> <sequence> <element name=“StreetAd1“ type="xsd:string"/> <element name=“StreetAd2" type="xsd:string"/> ........... </sequence> </complexType> (...) </wsdl:types> Address hasStreetAddress StreetAddress hasCity xsd:string hasZip xsd:string WSDL complex type element OWL ontology

  12. Using WSDL-S to interoperate • Associate mappings using the 'schemaMapping' attribute on Web service message (input and output) elements. • Use mappings as follows

  13. Implementation using AXIS2 • Data mediation implemented as module+handler in Axis2 • Validation of our philosophical choice (reusing existing WS infrastructure) • Heterogeneous Web service messages intercepted at AXIS and transformed to facilitate interoperation Nagrajan et al: Semantic Interoperability in Web services - Challenges and Experiences

  14. WSDL-S - Use Cases and Standardization Activity • International Bank Use Case • Agriculture Produce Market Committee (APMC India Use Case) • Bioinformatics Use Case

  15. International Bank Use Case • This bank is considering moving to SOA based architecture • They feel WSDL has following shortcomings • Schema level • Unable to define well known restrictions: email, credit card number • Unable to define detail description for enumerations: SPD for Summary Plan Description • WSDL operation level • pre-conditions and post-conditions of a service operation • restrictions on elements / complexTypes that are operation specific (e.g. customerId in CustomerType must be null for AddCustomer; but it's mandatory for GetCustomer)

  16. A search service is defined to search by either personal name or commercial name. The search engine would return at least one element of names, or a SOAP fault Use Case Details

  17. Adding Contracts to WSDL • In the use case, it’s expressed as the following: • A name has to be provided. • If it’s a personal name, either last name or personal name must exist. • If it’s a commercial name, either corporate name or stock ticker must exist. • Either at least one or no more than 100 names would be returned, or an error “not found” will occur.

  18. Some of the Preconditions These conditions can be represented as preconditions in WSDL-S

  19. Current Agri-Marketing scenario in India Buyers Agriculture Produce Market Committee Seller: Farmer Brokers associated With APMC

  20. Current Agri-Marketing scenario in India • A farmer can sell his produce to either Agriculture Produce Market Committeesor Brokers associated with APMC’s. • APMC’s sell the produce either by retail or in open markets. • Research is underway in creating SOA based architectures to realize the buyer seller interactions as services.

  21. Current Agri-Marketing scenario in India • Farmers use kiosks to interact with the buyer services • Farmers need to locate the right APMC for their products • Some APMC’s may not have refrigeration making them unsuitable for fresh vegetables, diary products etc. • Farmers might want to get paid in cash the same day whilst some APMC’s may not be willing to do so. • Farmers use the web based interface to then sell their produce to the APMC.

  22. Why WSDL-S? • Uses semantics to provide richer descriptions of the services offered by APMC’s. • An APMC buys wheat, potatoes, fresh meat and dairy products. The APMC can use WSDL-S to represent this information in his service description. • Allows for capturing policies such as “Refrigeration is free for 2 business days” or “Same day payment will be issued in cash” • Various APMC’s have varying data definitions. It is hard to create a client that can interoperate, due to heterogeneities that are present. WSDL-S help address them by mediation.

  23. Using WSDL-S in Bioinformatics • ProPreO - Experimental Proteomics Process Ontology (CCRC / LSDIS) <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="urn:ngp" …… xmlns:wssem="http://www.ibm.com/xmlns/WebServices/WSSemantics" xmlns:ProPreO="http://lsdis.cs.uga.edu/ontologies/ProPreO.owl" > <wsdl:types> <schema targetNamespace="urn:ngp" xmlns="http://www.w3.org/2001/XMLSchema"> …… </schema> </wsdl:types> <wsdl:message name="replaceCharacterRequest" wssem:modelReference="ProPreO#peptide_sequence"> <wsdl:part name="in0" type="soapenc:string"/> <wsdl:part name="in1" type="soapenc:string"/> <wsdl:part name="in2" type="soapenc:string"/> </wsdl:message> ...... data sequence peptide_sequence Excerpt: Bio-informatics Web service WSDLS Excerpt: ProPreO – process ontology CCRC – Complex Carbohydrate Research Center www.ccrc.uga.eduProPreO - http://lsdis.cs.uga.edu/projects/glycomics/propreo/

  24. Dynamic Process Configuration

  25. Sample Supply Chain Scenario • Consider a simplified supply chain process of a computer manufacturer • Most parts are multiple sourced • Overseas goods cheaper but greater lead times than internal/local suppliers • Need to deal with 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

  26. Dynamic Process Configuration Dynamic configuration Problem Find optimal partners for the process based on process constraints @ run time– 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 • Proposed Solution • Use of ontologies to represent domain knowledge • Use semantic knowledge captured in ontologies across the process lifecycle • A multi-paradigm constraint analysis based approach to handle quantitative and logical constraints

  27. Dynamic Process Configuration • Dynamic Process Configuration • Finding optimal partners for a process based on service and process constraints • 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)

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

  29. Abstract Process Specification • 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. • Specify process control flow by using virtual partners • Capture Functional Requirements of Services using Semantic Templates • Specify Process Constraints

  30. 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. Sample Semantic Template Service Level MetaData IndustryCategory = NAICS:Electronics ProductCategory = DUNS:RAM Location = Athens, GA Semantically Defined Operations Operation1 = Rosetta#requestPurchaseOrder Input = Rosetta#PurchaseOrderDetails Output = Rosetta#PurchaseConfirmation ResponseTime < 5s Operation2 = Rosetta#CancelOrder … Operation3 = Rosetta#ReturnProduct ….. Data SemanticsFunctional SemanticsNon-Functional Semantics *WSDL-S is used to capture semantic templates

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

  32. Process Constraints • Constraints can be specified at an appropriate level: an activity (operation of a partner), a partner, 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.)

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

  34. Constraint Analysis • Multi-paradigm approach used • ILP for quantitative constraints • SWRL for logical 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 Verma et al: Semantics-enabled Configuration of Web Processes

  35. Configuration Architecture

  36. Semantic Discovery • Finds actual services matching semantic templates • Implemented as a layer over UDDI • 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 [1] to consider operations and service level metadata • Extends the approach presented “WSDL to UDDI Mapping” [2] to support operation level discovery [1] M. Paolucci, T. Kawamura, T. Payne and K. Sycara, Semantic Matching of Web Services Capabilities, ISWC 2002. [2] 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

  37. Quantitative Constraint Analysis • A service is used (1) or not used (0) • Create a binary variable xij for each candidate service. • Set up constraints such that one service is chosen for each activity. • N(i) is the number of candidate services of activity ‘i’ and M is the number of activities.

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

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

  40. Domain Ontology

  41. 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)

  42. Configuration Example Discovery Results After SWRL After ILP

  43. Implementation Details • 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 • Infrastructure • Implemented as modules in Axis 2.0 • Phases • Pre-binding • Number of services bound to same service manager. Used for information gathering for constraint analysis • Binding • Constraint Analysis and binding optimal partner to each SM • Post-binding • Normal process execution with optimal partner

  44. Runtime Configuration Example

  45. Incorporating Configuration support in Axis 2.0

  46. Process Adaptation

  47. Process Adaptation Adaptation Problem Optimally react to events like delays in ordered goods • Proposed Solution • Use of stochastic decision making framework to deduce optimal actions • Conceptual Approach • Maintain state of the process • Capture costs while transitioning from abnormal states to goal state(s) • Ability to decide optimal actions on the basis of state

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

  49. Revisiting the Supply Chain Scenario • After order for the parts are placed, they may get delayed • The manufacturer may have severe costs (losses) 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

  50. 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 • Proposed Solution • Use a stochastic decision making framework to deal with such failures • Currently we use Markov Decision Processes

More Related