Your SlideShare is downloading. ×
© Copyright 2010 Dieter Fensel and Srdjan Komazec
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

© Copyright 2010 Dieter Fensel and Srdjan Komazec

561
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
561
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Semantic Web Services Web Service Execution Environment (WSMX) © Copyright 2010 Dieter Fensel and Srdjan Komazec 1
  • 2. Where are we? # Title 1 Introduction 2 Web Science 3 Service Science 4 Web services 5 Web2.0 services 6 Semantic Web 7 Web Service Modeling Ontology (WSMO) 8 Web Service Modeling Language (WSML) 9 Web Service Execution Environment (WSMX) 10 OWL-S and others 11 Light-weight Annotations 12 Applications 13 Mobile Services 2
  • 3. Outline • Motivation • Technical solution – Overview • Introduction • Relation to the WSMO and WSML • Design principles • Lifecycle – Conceptual Model • Architecture • Components • System entry points – Behavioral Model • Execution semantics • Illustration by larger example • Extensions • Summary • References 3
  • 4. Motivation 4
  • 5. Motivation How SESA emerged? • Service Orientation in information systems – Service-Oriented Computing (SOC) • Services as the fundamental elements for the development of rapid, low-cost, and easily integrable enterprise applications, – Service-Oriented Architecture (SOA) • SOC can be abstractly implemented by SOA, • From function to object to service, • SOA requirements: loose coupling, implementation neutrality, flexible configuration, long lifetime, granularity and teams. • Existing technologies and SOA solutions are… – … difficult to scale without a proper degree of automation, – … partial solution to interoperability. • Semantically Enabled Service Oriented Architecture (SESA) represents SOA empowered by adding semantics as a means to deal with heterogeneity and mechanization of service usage. 5
  • 6. Motivation What is SESA? • Application of SESA offers a scalable integration, more adaptive to changes – service offerings and required capabilities are described by semantically rich and formal service models, – exchanged data is also semantically described, and – reasoning provides total or partial automation of tasks. • A SESA implementation should build a layer on top of the existing technologies (e.g. Web Services). Web Service Execution Environment (WSMX) is an implementation of SESA. 6
  • 7. Motivation SESA Architecture Fensel, D.; Kerrigan, M.; Zaremba, M. (Eds): Implementing Semantic Web Services: The SESA Framework. Springer 2008. 7
  • 8. Motivation WSMX Goals • Middleware for Semantic Web Services – Allows service providers to focus on their business, • Reference implementation for WSMO – Eat our own cake, • Environment for goal based discovery and invocation – Run-time binding of service requesters and providers, • Provide a flexible Service Oriented Architecture – Add, update, remove components at run-time as needed, • Keep open-source to encourage participation – Developers are free to use in their own code, and • Define formal execution semantics – Unambiguous model of system behaviour. 8
  • 9. Technical Solution Overview 9
  • 10. Overview Introduction WSMX is… • … is comprehensive software framework for runtime binding of service requesters and service providers, • … interprets service requester’s goal to – discover matching services, – select (if desired) the service that best fits, – provide data/process mediation (if required), and – make the service invocation, • … is reference implementation for WSMO, • … has a formal execution semantics, and • … is service oriented, event-based and has pluggable architecture – Open source implementation available through Source Forge, – based on microkernel design using technologies such as JMX. 10
  • 11. Overview Relation to WSMO and WSML Conceptual Model & Axiomatization for SWS STI2 CMS WG SEE TC Formal Language for WSMO Execution Environment for WSMO Ontology & Rule Language for the Semantic Web 11
  • 12. Overview Design principles • Service-oriented principle – Service reusability, loose coupling, abstraction, composability, autonomy, discoverability, • Semantic Principle – Rich and formal description of information and behavioral models enabling automation of certain tasks by means of logical reasoning, • Problem-solving principle – Goal-based discovery and invocation of services, and • Distributed principle – Executing process across a number of components/services over the network, thus promoting scalability and quality of process. 12
  • 13. Overview Lifecycle WSMX aims to support the complete Semantic Web Service lifecycle: 1) Discovery - determines usable services for a request, 2) Composition - combine services to achieve a goal, 3) Selection - chooses most appropriate service among the available ones, 4) Mediation- solves mismatches (data, protocol, process) hampering interoperation, 5) Choreography – interactions and processes between the service providers and clients, 6) Grounding – lifting and lowering between the semantic and syntactic data representations, and 7) Invocation - invokes Web service following programmatic conventions. 13
  • 14. Technical Solution Conceptual Model - Architecture 14
  • 15. Conceptual Model Architecture 15
  • 16. Conceptual Model Architecture • WSMX architectural components are divided into three layers – Execution Management layer • Responsible for managing all other components and interactions between them, • Components are orchestrated in the form of Execution Semantics (explained in upcoming slides). – Broker layer • Represented by a number of broker services each dedicated to accomplish different tasks in SWS lifecycle. – Base layer • Provides support to various upper level components by providing storage services, as well as parsing and reasoning. • WSMX provides different entry points in order to enable users to consume the offered functionality 16
  • 17. Technical Solution Conceptual Model – WSMX Components Core Management 17
  • 18. Conceptual Model – WSMX Components Core Management • Core Management is a kernel of WSMX with the following objectives – It realizes the overall operational semantics in order to achieve the functional semantics of its client-side interface – It orchestrates the functionality of the middleware components into a coherent process in an orderly and consistent fashion called Execution Semantics (see later) – It ensures the proper inter-component communication through publishing and subscribing to the data as sets of triples over triple space or directly in the synchronous communication manner 18
  • 19. Technical Solution Conceptual Model – WSMX Components Communication Manager and Invoker 19
  • 20. WSMX Components Communication Manager and Invoker • Responsible for interaction with services and entities that are external to WSMX. • Should be open to support as many transport and messaging protocols as possible (transparently to WSMX). • WSMX uses – The SOAP implementation from Apache AXIS, and – The Apache Web Service Invocation Framework (WSIF) . • Both RPC and Document style invocations possible SOAP XML Web Mediated Grounding Invoker Apache AXIS Service WSML Data Network 20
  • 21. Technical Solution Conceptual Model – WSMX Components Grounding 21
  • 22. WSMX Components Grounding • WSMO service descriptions are grounded to WSDL by the means of XSLT lifting and lowering Jacek Kopecký et al. D24.2v0.1. WSMO Grounding, WSMO Working Draft 27 April 2007. http://wsmo.org/TR/d24/d24.2/v0.1 22
  • 23. WSMX Components Grounding - Example <shipmentOrderResponse xmlns="http://www.example.org/muller/"> <pickupDate>2009-01-03T06:04:31.747+01:00</pickupDate> Web Service Invocation Response <price>65.06</price> </shipmentOrderResponse> <xsl:stylesheet version="2.0" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:p="http://www.wsmo.org/sws-challenge/ShipmentOntologyProcess#" xmlns:muller="http://www.example.org/muller/" exclude-result-prefixes="#all" xmlns:helper="java:ie.deri.wsmx.commons.Helper"> <xsl:output method="xml" omit-xml-declaration="yes"/> <xsl:template match="/muller:invokePriceResponse"> <xsl:variable name="randomId" select="helper:getRandomId()"/> <rdf:RDF> <rdf:Description about="http://example.com/testresponse{$randomId}"> <rdf:type rdf:resource="http://www.wsmo.org/sws-challenge/ShipmentOntologyProcess#PriceQuoteResp"/> <p:price rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal"><xsl:value-of select="number(./muller:price)"/></p:price> </rdf:Description> </rdf:RDF> </xsl:template> </xsl:stylesheet> Lifting transformation instance http://example.com/testresponse{1234567 memberOf http://www.wsmo.org/sws-challenge/ShipmentOntologyProcess#PriceQuoteResp price hasValue 65.06 Data represented as ontology and ontology instance 23
  • 24. Technical Solution Conceptual Model – WSMX Components Discovery 24
  • 25. Conceptual Model – WSMX Components Discovery • Responsible for finding appropriate Web Services capable of fulfilling a goal • Different techniques available – trade-off: ease-of-provision vs. accuracy – resource descriptions & matchmaking algorithms Key Word Matching Possible Accuracy Ease of provision - match natural language key words in resource descriptions, Controlled Vocabulary - ontology-based key word matching, and Semantic Matchmaking - what Semantic Web Services aim at. 25
  • 26. Conceptual Model – WSMX Components Discovery – Key Word Matching • Allows for a fast filtering and ranking of the huge number of available services rather quickly. • Nonfunctional properties from the Dublin Core namespace (e.g. dc#description) are candidates for indexing and querying. • Dictionaries of synonyms (WordNet) can be used to discover more services. wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-rule" namespace {_"http://www.wsmo.org/sws-challenge/WSMuller#", dc _"http://purl.org/dc/elements/1.1#"} webService WSMuller nfp dc#title hasValue "Muller Web Service" dc#description hasValue "We ship to Africa, North America, Europe, Asia (all countries)." dc#contributor hasValue "Maciej Zaremba, Matt Moran, Tomas Vitvar, Thomas Haselwanter" endnfp capability WSMullerCapability ... 26
  • 27. Conceptual Model – WSMX Components Discovery – Simple Semantic Descriptions =G = WS Exact Match: G, WS, O, M ╞ x. (G(x) <=> WS(x) ) PlugIn Match: G, WS, O, M ╞ x. (G(x) => WS(x) ) Subsumption Match: G, WS, O, M ╞ x. (G(x) <= WS(x) ) Intersection Match: G, WS, O, M ╞ x. (G(x)  WS(x) ) X Non Match: G, WS, O, M ╞ ¬x. (G(x)  WS(x) ) Keller, U.; Lara, R.; Polleres, A. (Eds): WSMO Web Service Discovery. WSML Working Draft D5.1, 12 Nov 2004. 27
  • 28. Conceptual Model – WSMX Components Discovery – Simple Semantic Descriptions - Example Generic goals Specific goals Domain knowledge Web services Lara, R., Lausen, H (Eds): WSMO Discovery Engine. WSML Working Draft D5.2, 26 Nov 2004. 28
  • 29. Conceptual Model – WSMX Components Discovery – Simple Semantic Descriptions - Example • Exact match • Plug-in match • Subsumption match • Intersection match 29
  • 30. Technical Solution Conceptual Model – WSMX Components Ranking and Selection 30
  • 31. Conceptual Model – WSMX Components Ranking and Selection • One service which best satisfies the user preferences is selected from the candidate services returned by the service discovery. • Selection – determines best candidate out of discovered WS, • Ranking – determines a priority list of discovered WS. • The process is run after “functional” discovery • Criteria: – Quality of Service (security, robustness, availability), – Context (regional, business / social communities), – Preferences and policies, – Financial criteria, – … 31
  • 32. Conceptual Model – WSMX Components Ranking and Selection • Ontologies for specifying QoS (http://www.wsmo.org/ontologies/nfp) – set of 17 ontologies (i.e. locative, temporal, availability, price, trust, security, etc.) – provide the terminology needed to specify QoS aspects of services • The data required for ranking and selection can be attached through the non-functional aspects of SWS • The example defines the value of price for the Web Service consumption as a WSML logical expression which needs to be evaluated. • If the client is older than 60 or less than 100 years old the predefined absolute price is taken which must be less or equal to 10. 32
  • 33. Conceptual Model – WSMX Components Ranking and Selection • Service Ranking – Based on order theory which defines notions of total order, partial order and ranking. – WSMX uses Multicriteria ranking – considers multiple nonfunctional properties • Service Selection – User specifies selection criteria in terms of nonfunctional properties such as SLA, QoS, etc. Those can be obtained from goal description. – Service defines nonfunctional property values are directly provided or computed/collected by a monitoring tool. 33
  • 34. Conceptual Model – WSMX Components Ranking and Selection – Example namespace {pref _"http://www.wsmo.org/ontologies/nfp/preferenceOntology#"} webService TestService1 nfp WS1 pref#Obligation hasValue 10 pref#Discount hasValue 120 pref#AverageInvocationTime hasValue 230 endnfp namespace {pref _"http://www.wsmo.org/ontologies/nfp/preferenceOntology#"} webService TestService2 nfp WS2 pref#Obligation hasValue 12 pref#Discount hasValue 130 pref#AverageInvocationTime hasValue 150 endnfp namespace {pref _"http://www.wsmo.org/ontologies/nfp/preferenceOntology#"} goal TestGoal nfp dc#title hasValue "TestGoal” pref#order hasValue pref#descending pref#preferencesNFPs hasValue {prefObligation, prefDiscount, prefAverageInvocationTime} endnfp instance prefObligation memberOf pref#Preference Goal pref#nonFunctionalProperty hasValue pref#Obligation pref#interestValue hasValue 0.1 instance prefDiscount memberOf pref#Preference pref#nonFunctionalProperty hasValue pref#Discount pref#interestValue hasValue 0.6 instance prefAverageInvocationTime memberOf pref#Preference pref#nonFunctionalProperty hasValue pref#AverageInvocationTime pref#interestValue hasValue 0.3 34
  • 35. Technical Solution Conceptual Model – WSMX Components Data Mediation 35
  • 36. Conceptual Model – WSMX Components Data Mediation • Ontology-to-ontology mediation • A set of mapping rules are defined and then executed – Ontology Mapping Language • Initially rules are defined semi-automatic • Create for each source instance the target instance(s) Source Target Ontology Ontology Source Target Instance Instance Data Mediation Mappings Mappings Design-time Component Run-time Component Storage Fensel, D.; Kerrigan, M.; Zaremba, M. (Eds): Implementing Semantic Web Services: The SESA Framework. Springer 2008. 36
  • 37. Conceptual Model – WSMX Components Data Mediation Design-time Run-time – Inputs – Main Mediation Scenario: • Source Ontology and Target Instance Transformation Ontology – Inputs – Features • Incoming data – Source ontology instances • Graphical interface • Set of mechanism towards semi- – Features automatic creation of mappings • Completely automatic process • Capturing the semantic • Grounding of the abstract relationships identified in the mappings to a concrete language process – WSML • Storing these mappings in a • Uses reasoner to evaluate the persistent storage mapping rules – Output – Outputs • Abstract representation of the • Mediated data mappings – Target ontology instances 37
  • 38. Conceptual Model – WSMX Components Data Mediation - Example wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-flight" wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml- namespace { _"http://deri.org/iswc2005tutorial/ontologies/travel1#"} flight" namespace { ontology travel1 _"http://deri.org/iswc2005tutorial/ontologies/travel2#"} concept ticket ontology travel2 type ofType _string departure_city ofType _string concept travelVoucher departure_code ofType _string type ofType _string arrival_city ofType _string bearer ofType name arrival_code ofType _string departure_date ofType date toFrom ofType tripPoints arrival_date ofType date departureDate ofType date departure_time ofType time arrivalDate ofType date arrival_time ofType time departureTime ofType time issuing_terms ofType terms arrivalTime ofType time firstName ofType _string terms ofType payment lastName ofType _string deliveryDate ofType date ... ... Source ontology Destination ontology 38
  • 39. Conceptual Model – WSMX Components Data Mediation – Example – WSMT Mappings 39
  • 40. Conceptual Model – WSMX Components Data Mediation - Example <Alignment> <dc:identifier rdf:resource="m2"/> <onto1> <formalism name="WSML" uri="http://www.wsmo.org/wsml"/><uri>http://deri.org/iswc2005tutorial/ontologies/travel1#travel1</uri> </onto1> <onto2> <formalism name="WSML" uri="http://www.wsmo.org/wsml"/><uri>http://deri.org/iswc2005tutorial/ontologies/travel2#travel2</uri> </onto2> <map> … <Cell id="http://deri.org/iswc2005tutorial/ontologies/travel1#tickethttp://deri.org/iswc2005tutorial/ontologies/travel2#travelVoucher"> <entity1> <Class rdf:about="http://deri.org/iswc2005tutorial/ontologies/travel1#ticket"></Class> </entity1> <entity2> <Class rdf:about="http://deri.org/iswc2005tutorial/ontologies/travel2#travelVoucher"></Class> </entity2> <measure>1.0</measure> <relation>ClassMapping</relation> </Cell> … </map> </Alignment> Mapping between two concepts 40
  • 41. Conceptual Model – WSMX Components Data Mediation - Example wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml- wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml- flight" flight" namespace { namespace { _"http://deri.org/iswc2005tutorial/ontologies/travel1#”} _"http://deri.org/iswc2005tutorial/ontologies/travel2#"} ontology travel1 ontology travel2 instance my_ticket_input memberOf ticket instance expected_travelVoucher memberOf travelVoucher type hasValue "flight" departureDate hasValue expected_departureDate firstName hasValue "Adrian" terms hasValue expected_payment lastName hasValue "Mocan" arrivalDate hasValue expected_arrivalDate arrival_date hasValue my_arrival_date bearer hasValue expected_name departure_date hasValue my_departure_date departureTime hasValue expected_departureTime arrival_time hasValue my_arrival_time arrivalTime hasValue expected_arrivalTime departure_time hasValue my_departure_time type hasValue "flight" departure_city hasValue "Innsbruck" departure_code hasValue "INN" arrival_city hasValue "Rome" arrival_code hasValue "RO" issuing_terms hasValue my_terms Source instances Destination instances 41
  • 42. Technical Solution Conceptual Model – WSMX Components Process Mediation 42
  • 43. Conceptual Model – WSMX Components Process Mediation* • Requester and provider have their own communication patterns • Only if the two match precisely, a direct communication may take place • At design time equivalences between the choreographies’ conceptual descriptions is determined and stored as set of rules • The Process Mediator provides the means for runtime analyses of two choreography instances and uses mediators to compensate possible mismatches * Not implemented yet! 43
  • 44. Conceptual Model – WSMX Components Process Mediation A PM Business Business Partner1 B B Partner2 A PM B Business Business Partner1 B A Partner2 PM A Business A and B Business Partner1 B Partner2 A PM Business A and B Business Partner1 B Partner2 A PM A Business Business Partner1 AckA Partner2 Fensel, D.; Kerrigan, M.; Zaremba, M. (Eds): Implementing Semantic Web Services: The SESA Framework. Springer 2008. 44
  • 45. Conceptual Model – WSMX Components Process Mediation - Example • Not a priori compatible behavior interfaces for communication & information interchange • Partially resolvable by “process mediation patterns” Figure taken from Emilia Cimpian, D13.7 v0.1 Process Mediation in WSMX, WSMX Working Draft 08 July 2005 45
  • 46. Conceptual Model – WSMX Components Process Mediation - Example 46
  • 47. Technical Solution Conceptual Model – WSMX Components Choreography 47
  • 48. Conceptual Model – WSMX Components Choreography • Requester and provider have their own observable communication patterns – Choreography part of WSMO • Choreography instances are loaded for the requester and provider – Both requester and provider have their own WSMO descriptions • Abstract State Machines (ASM)-based Choreography Engine – Evaluation of transition rules • prepares the available data – Sends data to the Process Mediator • filters, changes or replaces data – Receives data from PM and forwards it to the Communication manager • data to be finally sent to the communication partner 48
  • 49. Conceptual Model – WSMX Components Choreography – Abstract State Machines • The model used to express typical characteristics of a choreography must be compliant to the following features: – Abstract – hides away any details regarding the underlying message exchange protocols and message formats, – State-based – the interactions are described in the form of updates on a state of the choreography, – Expressive – allows describing features such as sequences of message interactions and branching, and – Ontology Reliance – ontologies are used as the underlying data model for message exchanges. • The abstract state model chosen to address the requirements is inspired by the Abstract State Machines (ASM) methodology. 49
  • 50. Conceptual Model – WSMX Components Choreography – Abstract State Machines • The choreography model consists primarily of – state signature – defines ontology which is used by the choreography, – set of transition rules – express the interaction steps in the choreography and also the updates over the state. • State signature allows to define – Set of imported ontologies – Set of modes which are associated with the concepts and/or relations. • Modes can be of the following types: – static – extension of the concept/relation cannot be changed, – in - extension of the concept/relation can only be changed by the client and read by the choreography instance; grounding mechanism must be provided. – out - extension of the concept/relation can only be changed by the the choreography instance and read by the client; grounding mechanism must be provided. – shared - extension of the concept/relation can be changed and read by both choreography instance and client; grounding mechanism must be provided, and – controlled - extension of the concept/relation is changed and read only by the choreography instance. 50
  • 51. Conceptual Model – WSMX Components Choreography – Abstract State Machines • Transition rules define actual behavior of the choreography. • The rules can take the form of – if Condition then Rules endIf – if the condition holds executes the updates. – forall Variables with Condition do Rules endForall - simultaneous execution of updates for each binding of a variable satisfying a given condition. – choose Variables with Condition do Rules endChoose - executes an update with an arbitrary binding of a variable chosen among those satisfying the selection condition. , where – condition (guard) - is an arbitrary logical expression as defined by WSML, – rules - may take the form of Updates, whose execution is to be understood as changing (or defining, if there was none) instances in an ontology • add – adds new instances in the state ontology, • delete – deletes instances from the state ontology, and • update – updates instances in the state ontology. 51
  • 52. WSMX Components Choreography - Example choreography WSMullerShipmentOrderChoreography stateSignature WSMullerShipmentOrderStateSignature … in sop#ShipmentOrderReq withGrounding { _"http://sws- challenge.org/shipper/v2/muller.wsdl#wsdl.interfaceMessageReference(muller/ShipmentOrder/in0)"} in so#ContactInfo in so#ShipmentDate in so#Package in so#Address out sop#ShipmentOrderResp transitionRules WSMullerShipmentOrderTransitionRules forall {?request} with (?request memberOf sop#ShipmentOrderReq) do add(_#1 memberOf sop#ShipmentOrderResp) delete(?request memberOf sop#ShipmentOrderReq) endForall <shipmentOrderReq(soi#MoonContactInfo, soi#shipmentDate1, package, soi#SzyslakContactInfo), package(1, 7.0, 6.0, 4.0, 1.0), S1 shipmentDate1(“2009-01-21T13:00:00.046Z”, "2009-01-22T13:00:00.046Z")> <shipmentOrderResp(“2009-01-21T15:00:00.046Z”, 65.03), package(1, 7.0, 6.0, 4.0, 1.0), S2 shipmentDate1(“2009-01-21T13:00:00.046Z”, "2009-01-22T13:00:00.046Z")> 52
  • 53. Technical Solution Conceptual Model – WSMX Components Resource Manager 53
  • 54. Conceptual Model – WSMX Components Resource Manager • Stores internal memory model to a data store • Decouples storage mechanism from the rest of WSMX • Data model is compliant to WSMO API • Independent of any specific data store implementation i.e. database and storage mechanism • Maintains six repositories to store – WSMO top level entities, i.e. • Goals, • Web Service descriptions, • Mediators, and • Ontologies. – Event data and intermediate messages – WSDL descriptions 54
  • 55. Technical Solution Conceptual Model – WSMX Components Reasoners 55
  • 56. Conceptual Model – WSMX Components Reasoners • Different components within WSMX necessitate efficient and different reasoning functionality: – Discovery • Simple ontological reasoning and query answering as well as logical entailment between preconditions and postconditions of SWS and Goals • Both description logic-based and logic programming–based reasoning is required. – Selection • Evaluation of the logical rules that are used to model the non-functional properties of services • Logic programming–based reasoning is required. – Data mediation • Ontology mapping rules, source instances and source and target schema information are loaded into the reasoning space where rules are evaluated in order to produce target instances. • Logic programming–based reasoning is required. – Process Mediation • Reasoning is used to check whether messages are expected at the certain phase of the communication. • Evaluation of transition rules is required. • Different reasoning functionality is provided to WSMX through WSML2Reasoning framework. 56
  • 57. Conceptual Model – WSMX Components Reasoners - WSML2Reasoner Framework • Represents a generic, flexible architecture for reasoning with the different variants of the WSML family. • Instead of implementing new reasoners it uses existing reasoner implementations for WSML through a wrapper that 1) maps WSML expressions into a common (shared) knowledge representation format (different formats for the rule-based and description logic based WSML variants), and 2) maps the expressions via specific adapters into the appropriate syntaxes of concrete reasoning engines. • People can use their specific existing reasoner of choice and can exploit already developed, proven and tested reasoning systems. 57
  • 58. Conceptual Model – WSMX Components Reasoners - WSML2Reasoner Framework Fensel, D.; Kerrigan, M.; Zaremba, M. (Eds): Implementing Semantic Web Services: The SESA Framework. Springer 2008. 58
  • 59. Conceptual Model – WSMX Components Reasoners - WSML2Reasoner Framework • Reasoning with rule-Based WSML – Covers WSML-Core, WSML-Flight, and WSML-Rule • Supported through semantics-preserving syntactic transformation of WSML ontologies to Datalog programs with (in)equality and integrity constrains. – Axiomatization – conversion of conceptual elements into appropriate axioms, – Normalization – reduction of complexity by bringing the expressions closer to the simple syntactic form of literals in Datalog rules – Lloyd-Topor transformation – flattening of the remaining complex WSML logical expressions in order to produce simple rules (single head and conjunctive – possibly negated - body literals). – Datalog rule generation – All WSML logical expressions are transformed into a Datalog program • Supported reasoning tasks – Query answering, ontology consistency, entailment, retrieval 59
  • 60. Conceptual Model – WSMX Components Reasoners - WSML2Reasoner Framework • Reasoning WSML-DL • Supported through semantics-preserving syntactic transformation of WSML-DL ontologies to OWL-DL ontologies. – Relations to attributes – replacing relations, subrelations, and relation instances by attributes and axioms, – Axiomatization - conversion of conceptual elements into appropriate axioms, – Implication reduction rules – replacing equivalences and right implications in logical expressions by left implications, – Inverse implication reduction rules – replace conjunctions on the left side and disjunctions on the right side of an inverse implication by left implications, – Molecule decomposition rules – replace complex molecules inside logical expressions by conjunctions of cimple ones, and – OWL API transformation – each logical expression is translated into the corresponding OWL descriptions • Supported reasoning tasks – Knowledge base consistency, concept satisfiability, concept subsumption, instance checking, realization, instance retrieval 60
  • 61. Technical Solution Conceptual Model – Entry Points 61
  • 62. Conceptual Model – Entry Points • Represent input ports to which messages can be sent for initiating specific execution semantics. • Published as SOAP Endpoints – getWebServices(WSMLDocument): Web Services • A service requester wishes to discover a list of SWS fulfilling its requirements provided by as a goal description using WSML. • A set of WSML Web Service descriptions whose capability matches the goal is returned. – invokeWebService(WSMLDocument, Context): Context • Used to invoke already known Semantic Web Service by relying on data provided in the form of WSML ontology and conversation context. – achieveGoal(WSMLDocument): Context • A service requester wishes to use WSMX for all aspects of goal-based service invocation (discovery, mediation, invocation) by providing both goal and data in the single WSML document. • Processing of the message is identified by the conversation context . 62
  • 63. Technical Solution Behavioral Model 63
  • 64. Behavioral Model Execution Semantics • Execution Semantics is a formal description of the operational behavior of the system in terms of computational steps • The benefits of having behavioral models are in – Greater flexibility in SESA implementations, – Foundations for model testing, – Executable representation, and – Improved model understanding among humans. • Mandatory execution semantics – Goal-Based Web Service Discovery – Web Service Invocation – Goal-Based Service Execution 64
  • 65. Behavioral Model Execution Semantics – Goal-based discovery Fensel, D.; Kerrigan, M.; Zaremba, M. (Eds): Implementing Semantic Web Services: The SESA Framework. Springer 2008. 65
  • 66. Behavioral Model Execution Semantics – Goal-based discovery • Input – Service requester wishes to discover a list of SWS fulfilling its requirements provides them as a goal description using WSML. • Output – A set of WSML Web Service description whose capability matches the goal is returned. • Process 1. Message containing WSML goal is received and passed to the communication manager, which takes care of message persistence. 2. The goal is sent to discovery activity which evaluates whether a WSML Web service from the repository is capable of fulfilling the goal. It may need data mediation as its internal step. 3. The selection activity may be triggered to determine which of the discovered services to return to the service requester. 4. WSML Web service description is returned in a form of message to the requester by relying on the Communication Manager facilities. 66
  • 67. Behavioral Model Execution Semantics – Web Service Invocation Fensel, D.; Kerrigan, M.; Zaremba, M. (Eds): Implementing Semantic Web Services: The SESA Framework. Springer 2008. 67
  • 68. Behavioral Model Execution Semantics – Web Service Invocation • Input – As input the requester is providing WSML content (Web service + data) and conversation context (if known!!! The first message is sent without it, but it is returned as output of the invocation). • Output – Results of the Web Service invocation (and possibly conversational context) • Process 1. Communication Manager unpacks the content and retrieves Web service and data. 2. Data mediation may be required in cases where heterogeneities exists (this step can internally use reasoner) 3. Process mediation has all the required data to commence (matching the message patterns and data types offered by SWS and required by the goal). This is a process of aligning of input data instances so that they can be understood by the Choreography. 4. The choreography activity is commencing (determines which messages to send on the basis of choreography descriptions - ASM). 5. Grounding is taking place in order to transform those instances to the format required by the invoked service. 6. Invocation takes place 68
  • 69. Behavioral Model Execution Semantics – Goal-based Service Execution Fensel, D.; Kerrigan, M.; Zaremba, M. (Eds): Implementing Semantic Web Services: The SESA Framework. Springer 2008. 69
  • 70. Behavioral Model Execution Semantics – Goal-based Service Execution • Service requester wishes to employ the complete SWS lifecycle, i.e., all aspects of goal-based service invocation (discovery, mediation, invocation) • Input – Requester provides both the goal and the input data descriptions in a single WSML document. • Output – Results of the Web Service invocation (if any). • Operation 1. Execute the Goal-based Web Service discovery execution semantics 2. In case of more than one result run the selection process in order to determine the Web Service which is the most appropriate for the execution (based on non-functional properties and employed selection mechanisms) 3. Execute the Web Service Invocation execution semantics 70
  • 71. Illustration by a Larger Example 71
  • 72. Illustration by larger example Scenario description • The goal is to discover a suitable solution for the transportation of a package with defined size and weight • Candidate Web Services have different constraints regarding the transportation destinations, package size and weight acceptance, as well as pricing schemas • For more information visit: – http://sws-challenge.org/wiki/index.php/Scenario:_Shipment_Discovery 72
  • 73. Illustration by larger example Goal description I want to have my package shipped from CA, USA to Tunis, Africa size (7/6/4), weight 1 lbs, the cheaper the better. wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-flight" goal GoalA1 ontology GoalRequest capability GoalA1Capability postcondition instance shipmentOrderReq memberOf sop#ShipmentOrderReq definedBy sop#from hasValue soi#MoonContactInfo ( ?x[sop#price hasValue ?price] memberOf sop#shipmentDate hasValue soi#shipmentDate1 sop#PriceQuoteResp sop#package hasValue package and sop#isShipped(shipmentOrderReq) ). sop#to hasValue soi#SzyslakContactInfo interface GoalA1Interface instance package memberOf so#Package choreography GoalA1Choreography so#quantity hasValue 1 stateSignature GoalA1StateSignature so#length hasValue 7.0 so#width hasValue 6.0 in sop#ShipmentOrderReq so#height hasValue 4.0 out sop#ShipmentOrderResp so#weight hasValue 1.0 transitionRules GoalA1TransitionRules instance shipmentDate1 memberOf so#ShipmentDate so#earliest hasValue "2009-01-21T13:00:00.046Z" forall {?request} with so#latest hasValue "2009-01-22T13:00:00.046Z" (?request memberOf sop#ShipmentOrderReq) do add(_#1 memberOf sop#ShipmentOrderResp) endForall 73
  • 74. Illustration by larger example AchieveGoal execution semantics 74
  • 75. Illustration by larger example AchieveGoal execution semantics Goal expressed in WSML is sent to the WSMX Entry Point 75
  • 76. Illustration by larger example AchieveGoal execution semantics Communication Manager instantiates AchieveGoal Execution Semantics 76
  • 77. Illustration by larger example AchieveGoal execution semantics Discovery is employed in order to find suitable Web Service Africa ($85.03/13 lbs), ... Max 50 lbs. Price = $85.03 Africa, ... Max 50 lbs. Price on request only. PriceReq Price ($65.03) Web Service may be invoked in order to discover service availability Ships only to US ($10/1.5 lb). Cannot be used for Africa. Discovery consults appropriate ontologies and Web Service descriptions 77
  • 78. Illustration by larger example AchieveGoal execution semantics List of candidate Web Services is ranked and best” solution is selected 78
  • 79. Illustration by larger example AchieveGoal execution semantics Requester and provider choreographies are instantiated and processed Invocation of Web Service occurs 79
  • 80. Illustration by larger example AchieveGoal execution semantics – choreography exec choreography WSMullerShipmentOrderChoreography stateSignature WSMullerShipmentOrderStateSignature … in sop#ShipmentOrderReq withGrounding { _"http://sws- challenge.org/shipper/v2/muller.wsdl#wsdl.interfaceMessageReference(muller/ShipmentOrder/in0)"} in so#ContactInfo in so#ShipmentDate in so#Package in so#Address out sop#ShipmentOrderResp transitionRules WSMullerShipmentOrderTransitionRules forall {?request} with (?request memberOf sop#ShipmentOrderReq) do add(_#1 memberOf sop#ShipmentOrderResp) delete(?request memberOf sop#ShipmentOrderReq) endForall <shipmentOrderReq(soi#MoonContactInfo, soi#shipmentDate1, package, soi#SzyslakContactInfo), package(1, 7.0, 6.0, 4.0, 1.0), S1 shipmentDate1(“2009-01-21T13:00:00.046Z”, "2009-01-22T13:00:00.046Z")> <shipmentOrderResp(“2009-01-21T15:00:00.046Z”, 65.03), package(1, 7.0, 6.0, 4.0, 1.0), S2 shipmentDate1(“2009-01-21T13:00:00.046Z”, "2009-01-22T13:00:00.046Z")> 80
  • 81. Illustration by larger example AchieveGoal execution semantics Result is returned to the client in the form of WSML message 81
  • 82. Possible Extensions 82
  • 83. Possible Extensions Extensions under current development are marked with yellow boxes. 83
  • 84. Possible Extensions Discovery • Discovery component has undergone a set of smaller improvements: – Instead of full Semantic Web Service descriptions the results are returned in the form of WG mediators. – Caching of the discovery results, i.e., WG mediators. • WG mediators are allowing us to – Connect Goal descriptions with the Semantic Web Service descriptions, – Attach discovery (e.g., type of match) and ranking results (e.g., fitness of the service). • Caching of the results enables reductions of the computational time required for discovery when the same Goal is issues multiple times over the same set of SWS descriptions. 84
  • 85. Possible Extensions Monitoring and Complex Event Processing • WSMX can be viewed as a vibrant events producer – events related to the broker services execution, – events related to the external Web Service invocations, – events related to the progress of processed execution semantics. • The events represent a rich source of knowledge which can facilitate profiling, optimization and reliability of the environment. • The monitoring and complex event processing subsystem exhibits following behavior – WSMX components have been instrumented to emit appropriate semantically- described events in regard to the computational process progress, – RDF-based CEP engine detects occurrences of specified event patterns and executes the appropriate actions de- fined for the detected event (e.g. update of the aggregated statistical measures, notification of the administrator about the successive operation failures) 85
  • 86. Possible Extensions Notification Broker • Notification Broker enables asynchronous communication within WSMX • The broker provides following functionality – registering and storing user goal-descriptions and related results, and – notifying subscribed users of the related results. • The broker currently supports the subscription to the goal-based Web Service discovery through a new entry point which fires the execution semantics responsible for – checking for the existing (and not expired) user subscriptions, – executing for each subscribed goal the discovery process, and – once new services have been matched with respect to the previous subscriptions these newly discovered services are notified to the users. • The notification can employ two communication channels – Email notification, and – Web Service invocation. 86
  • 87. Possible Extensions Orchestration • Orchestration Engine features are – support of the dataflow in a manner consistent with WSMO/L, and – Adoption of the explicit concept of performance, and introduction of a new type of mediator to mediate between performances. • Orchestration Engine solves following issues – mediation in any connection, including dataflow, between heterogeneous components; – extraction and aggregation in the consumption and production of messages according to the WSML grounding approach – execution of service discovery and service invocation within composed services. 87
  • 88. Summary 88
  • 89. Summary • Clear separation of SWS, SESA, SEE and WSMX notions. • WSMX is reference implementation of WSMO. • WSMX contributes to solving scalability issues by automating various service-related tasks. • WSMX consists of various components dedicated to solving particular steps in the overall service life cycle orchestrated by Core Management. • Execution semantics is a formal description of the operational behavior of the system in terms of computational steps 89
  • 90. References 90
  • 91. References • Mandatory reading – Dieter Fensel, Mick Kerrigan, Michal Zaremba (Eds.), Implementing Semantic Web Services: The SESA Framework. Springer-Verlag, 2008. • Chapters 4,5, and 6. • Optional reading – Charles Petrie, Tiziana Margaria, Holger Lausen, Michal Zaremba (Eds.), Semantic Web Services Challenge: Results from the First Year. Springer-Verlag, 2008 • Online resources: – http://see.sti-innsbruck.at – http://sws-challenge.org 91
  • 92. Next Lecture # Title 1 Introduction 2 Web Science 3 Service Science 4 Web services 5 Web2.0 services 6 Semantic Web 7 Web Service Modeling Ontology (WSMO) 8 Web Service Modeling Language (WSML) 9 Web Service Execution Environment (WSMX) 10 OWL-S and others 11 Light-weight Annotations 12 Applications 13 Mobile Services 92
  • 93. Questions? 93