Semantic Web Services Tutorial : Semantic Web Services Tutorial Michael Stollberg and Armin Haller DERI – Digital Enterprise Research Institute 3rd International Conference on Web Services (ICWS 2005) Orlando, Florida, 2005 July 11


Slide2: Agenda Part I: Introduction to Semantic Web Services Vision of Next Generation Web Technology Semantic Web Service Challenges Part II: The Web Service Modeling Ontology WSMO Aims andamp; Design Principles Top Level Element Definitions BREAK Part III: A Walkthru Example Virtual Travel Agency Example Roles, Elements, Semantic Web Service technology usage Part IV: The Web Service Execution Environment WSMX Aims andamp; Design Principles Architecture andamp; Components


Slide3: PART I: Introduction to Semantic Web Services The vision of the Semantic Web Ontologies as the basic building block Current Web Service Technologies Vision and Challenges for Semantic Web Services


The Vision: Static 500 million users more than 3 billion pages WWW URI, HTML, HTTP The Vision


The Vision: WWW URI, HTML, HTTP Serious Problems in information finding, information extracting, information representing, information interpreting and and information maintaining. Semantic Web RDF, RDF(S), OWL Static The Vision


The Vision: WWW URI, HTML, HTTP Bringing the computer back as a device for computation Semantic Web RDF, RDF(S), OWL Dynamic Web Services UDDI, WSDL, SOAP Static The Vision


The Vision: WWW URI, HTML, HTTP Bringing the web to its full potential Semantic Web RDF, RDF(S), OWL Dynamic Web Services UDDI, WSDL, SOAP Static Semantic Web Services The Vision


Slide8: The Semantic Web the next generation of the WWW information has machine-processable and machine-understandable semantics not a separate Web but an augmentation of the current one Ontologies as basic building block


Ontology Definition : Ontology Definition formal, explicit specification of a shared conzeptualization commonly accepted understanding conceptual model of a domain (ontological theory) unambiguous terminology definitions machine-readability with computational semantics


Ontology Example: Ontology Example Concept conceptual entity of the domain Property attribte describing a concept Relation relationship between concepts or properties Axiom coherency description between Concepts / Properties / Relations via logical expressions Person Student Professor Lecture isA – hierarchy (taxonomy) name email matr.-nr. research field topic lecture nr. attends holds holds(Professor, Lecture) =andgt; Lecture.topic = Professor.researchField


Slide11: Ontology Technology To make the Semantic Web working we need: Ontology Languages: expressivity reasoning support web compliance Ontology Reasoning: large scale knowledge handling fault-tolerant stable andamp; scalable inference machines Ontology Management Techniques: editing and browsing storage and retrieval versioning and evolution Support Ontology Integration Techniques: ontology mapping, alignment, merging semantic interoperability determination and … Applications


Web Services : Web Services loosely coupled, reusable components encapsulate discrete functionality distributed programmatically accessible over standard internet protocols add new level of functionality on top of the current web


The Promise of Web Services: The Promise of Web Services web-based SOA as new system design paradigm


WSDL : WSDL Web Service Description Language W3C effort, WSDL 2 final construction phase describes interface for consuming a Web Service: - Interface: operations (in- andamp; output) - Access (protocol binding) - Endpoint (location of service)


UDDI: UDDI Universal Description, Discovery, and Integration Protocol OASIS driven standardization effort Registry for Web Services: - provider - service information - technical access


SOAP: SOAP Simple Object Access Protocol W3C Recommendation XML data transport: - sender / receiver - protocol binding - communication aspects - content


Deficiencies of WS Technology: Deficiencies of WS Technology current technologies allow usage of Web Services but: only syntactical information descriptions syntactic support for discovery, composition and execution =andgt; Web Service usability, usage, and integration needs to be inspected manually no semantically marked up content / services no support for the Semantic Web =andgt; current Web Service Technology Stack failed to realize the promise of Web Services


Semantic Web Services: Semantic Web Technology + Web Service Technology Semantic Web Services =andgt; Semantic Web Services as integrated solution for realizing the vision of the next generation of the Web allow machine supported data interpretation ontologies as data model automated discovery, selection, composition, and web-based execution of services


Semantic Web Services: Semantic Web Services define exhaustive description frameworks for describing Web Services and related aspects (Web Service Description Ontologies) support ontologies as underlying data model to allow machine supported data interpretation (Semantic Web aspect) define semantically driven technologies for automation of the Web Service usage process (Web Service aspect)


Semantic Web Services: Semantic Web Services Usage Process: Publication: Make available the description of the capability of a service Discovery: Locate different services suitable for a given task Selection: Choose the most appropriate services among the available ones Composition: Combine services to achieve a goal Mediation: Solve mismatches (data, protocol, process) among the combined Execution: Invoke services following programmatic conventions


Semantic Web Services: Semantic Web Services Execution support: Monitoring: Control the execution process Compensation: Provide transactional support and undo or mitigate unwanted effects Replacement: Facilitate the substitution of services by equivalent ones Auditing: Verify that service execution occurred in the expected way


Slide22: PART II: The Web Service Modeling Ontology WSMO Aims andamp; Working Groups Design Principles Top Level Notions Ontologies Web Services Goals Mediators Comparison to OWL-S


WSMO is ..: WSMO is .. a conceptual model for Semantic Web Services: ontology of core elements for Semantic Web Services a formal description language (WSML) execution environment (WSMX) derived from and based on the Web Service Modeling Framework WSMF a SDK-Cluster Working Group (joint European research and development initiative)


WSMO Working Groups: WSMO Working Groups A Conceptual Model for SWS A Formal Language for WSMO A Rule-based Language for SWS Execution Environment for WSMO


WSMO Design Principles: Web Compliance Ontology-Based Goal-driven Strict Decoupling Centrality of Mediation Description versus Implementation Execution Semantics WSMO Design Principles


WSMO Top Level Notions: WSMO Top Level Notions Objectives that a client wants to achieve by using Web Services Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: Capability (functional) Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities WSMO D2, version 1.2, 13 April 2005 (W3C submission)


Non-Functional Properties: Non-Functional Properties every WSMO elements is described by properties that contain relevant, non-functional aspects Dublin Core Metadata Set: complete item description used for resource management Versioning Information evolution support Quality of Service Information availability, stability Other Owner, financial


Non-Functional Properties List: Non-Functional Properties List Dublin Core Metadata Contributor Coverage Creator Description Format Identifier Language Publisher Relation Rights Source Subject Title Type Quality of Service Accuracy NetworkRelatedQoS Performance Reliability Robustness Scalability Security Transactional Trust Other Financial Owner TypeOfMatch Version


WSMO Ontologies: WSMO Ontologies Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: Capability (functional) Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services


Ontology Usage & Principles : Ontologies are used as the ‘data model’ throughout WSMO all WSMO element descriptions rely on ontologies all data interchanged in Web Service usage are ontologies Semantic information processing andamp; ontology reasoning WSMO Ontology Language WSML conceptual syntax for describing WSMO elements logical language for axiomatic expressions (WSML Layering) WSMO Ontology Design Modularization: import / re-using ontologies, modular approach for ontology design De-Coupling: heterogeneity handled by OO Mediators Ontology Usage andamp; Principles


Ontology Specification: Non functional properties (see before) Imported Ontologies importing existing ontologies where no heterogeneities arise Used mediators OO Mediators (ontology import with terminology mismatch handling) Ontology Elements: Concepts set of concepts that belong to the ontology, incl. Attributes set of attributes that belong to a concept Relations define interrelations between several concepts Functions special type of relation (unary range = return value) Instances set of instances that belong to the represented ontology Axioms axiomatic expressions in ontology (logical statement) Ontology Specification


WSMO Web Services: WSMO Web Services Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: Capability (functional) Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services


WSMO Web Service Description : WSMO Web Service Description Web Service Implementation (not of interest in Web Service Description) Choreography --- Service Interfaces --- Capability functional description Advertising of Web Service Support for WS Discovery client-service interaction interface for consuming WS External Visible Behavior - Communication Structure - ‘Grounding’ realization of functionality by aggregating other Web Services functional decomposition WS composition Non-functional Properties DC + QoS + Version + financial complete item description quality aspects Web Service Management Orchestration


Capability Specification: Capability Specification Non functional properties Imported Ontologies Used mediators OO Mediator: importing ontologies with mismatch resolution WG Mediator: link to a Goal wherefore service is not usable a priori Pre-conditions What a web service expects in order to be able to provide its service. They define conditions over the input. Assumptions Conditions on the state of the world that has to hold before the Web Service can be executed Post-conditions describes the result of the Web Service in relation to the input, and conditions on it Effects Conditions on the state of the world that hold after execution of the Web Service (i.e. changes in the state of the world)


Choreography & Orchestration: Choreography andamp; Orchestration VTA example: Choreography = how to interact with the service to consume its functionality Orchestration = how service functionality is achieved by aggregating other Web Services


Choreography Aspects : Choreography Aspects External Visible Behavior those aspects of the workflow of a Web Service where Interaction is required described by workflow constructs: sequence, split, loop, parallel Communication Structure messages sent and received their order (communicative behavior for service consumption) Grounding executable communication technology for interaction choreography related errors (e.g. input wrong, message timeout, etc.) Formal Model reasoning on Web Service interfaces (service interoperability) allow mediation support on Web Service interfaces Interface for consuming Web Service


Orchestration Aspects : Orchestration Aspects decomposition of service functionality all service interaction via choreographies Control Structure for aggregation of other Web Services Web Service Business Logic 1 2 3 4


WSMO Web Service Interfaces: WSMO Web Service Interfaces service interfaces are concerned with service consumption and interaction Choreography and Orchestration as sub-concepts of Service Interface common requirements for service interface description: represent the dynamics of information interchange during service consumption and interaction support ontologies as the underlying data model appropriate communication technology for information interchange sound formal model / semantics of service interface specifications in order to allow operations on them.


Service Interface Description : Service Interface Description Ontologies as data model: all data elements interchanged are ontology instances service interface = evolving ontology Abstract State Machines (ASM) as formal framework: dynamics representation: high expressiveness andamp; low ontological commitment core principles: state-based, state definition by formal algebra, guarded transitions for state changes overcome the 'Frame Problem' further characteristics: not restricted to any specific communication technology ontology reasoning for service interoperability determination basis for declarative mediation techniques on service interfaces


Service Interface Description Model: Service Interface Description Model Vocabulary Ω: ontology schema(s) used in service interface description usage for information interchange: in, out, shared, controlled States ω(Ω): a stable status in the information space defined by attribute values of ontology instances Guarded Transition GT(ω): state transition general structure: if (condition) then (action) different for Choreography and Orchestration additional constructs: add, delete, update


Service Interface Example: Service Interface Example Ωin hasValues { concept A [ att1 ofType X att2 ofType Y] …} a memberOf A [ att1 hasValue x att2 hasValue y] a memberOf A [ att1 hasValue x, att2 hasValue y] b memberOf B [ att2 hasValue m] IF (a memberOf A [ att1 hasValue x ]) THEN (b memberOf B [ att2 hasValue m ]) State ω1 Guarded Transition GT(ω1) State ω2 Ωout hasValues { concept B [ att1 ofType W att2 ofType Z] …} Vocabulary: - Concept A in Ωin - Concept B in Ωout received ontology instance a Communication Behavior of a Web Service sent ontology instance b


Future Directions: Future Directions Ontologies as data model: - every resource description based on ontologies - every data element interchanged is ontology instance Formal description of service interfaces: - ASM-based approach - allows reasoning andamp; mediation workflow constructs as basis for describing service interfaces: - workflow based process models for describing behavior - on basis of generic workflow constructs (e.g. van der Aalst) Choreography: - interaction of services / service and client - a „choreography interface' describes the behavior of a Web Service for client-service interaction for consuming the service Orchestration: - how the functionality of a Web Service is achieved by aggregating other Web Services - extends Choreography descriptions by control andamp; data flow constructs between orchestrating WS and orchestrated WSs. Grounding: - making service interfaces executable - currently grounding to WSDL Conceptual models User language - based on UML2 activity diagrams - graphical Tool for Editing andamp; Browsing Service Interface Description


WSMO Goals : WSMO Goals Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: Capability (functional) Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services


Goals: Goals Ontological De-coupling of Requester and Provider Goal-driven Approach, derived from AI rational agent approach requester formulates objective independently ‘intelligent’ mechanisms detect suitable services for solving the Goal allows re-use of Services for different purposes Usage of Goals within Semantic Web Services A requester (human or machine) defines a Goal to be resolved Web Service discovery detects suitable Web Services for solving the Goal automatically Goal resolution management is realized in implementations


Goal Specification: Goal Specification Non functional properties Imported Ontologies Used mediators OO Mediators: importing ontologies with heterogeneity resolution GG Mediator: Goal definition by reusing an already existing goal allows definition of Goal Ontologies Requested Capability describes service functionality expected to resolve the objective defined as capability description from the requester perspective Requested Interface describes communication behaviour supported by the requester for consuming a Web Service (Choreography) Restrictions / preferences on orchestrations of acceptable Web Services


WSMO Mediators: WSMO Mediators Provide the formally specified terminology of the information used by all other components Semantic description of Web Services: Capability (functional) Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to achieve by using Web Services


Mediation : Mediation Heterogeneity … Mismatches on structural / semantic / conceptual / level Occur between different components that shall interoperate Especially in distributed andamp; open environments like the Internet Concept of Mediation (Wiederhold, 94): Mediators as components that resolve mismatches Declarative Approach: Semantic description of resources ‘Intelligent’ mechanisms that resolve mismatches independent of content Mediation cannot be fully automated (integration decision) Levels of Mediation within Semantic Web Services (WSMF): Data Level: mediate heterogeneous Data Sources Protocol Level: mediate heterogeneous Communication Patterns Process Level: mediate heterogeneous Business Processes


WSMO Mediators Overview: WSMO Mediators Overview


Mediator Structure: Mediator Structure WSMO Mediator uses a Mediation Service via Source Component Source Component Target Component 1 .. n 1 Mediation Services as a Goal directly optionally incl. Mediation


OO Mediator - Example: OO Mediator - Example OO Mediator Mediation Service Train Connection Ontology (s1) Purchase Ontology (s2) Train Ticket Purchase Ontology Mediation Services Goal: 'merge s1, s2 and s1.ticket subclassof s2.product' Discovery Merging 2 ontologies


GG Mediators: GG Mediators Aim: Support specification of Goals by re-using existing Goals Allow definition of Goal Ontologies (collection of pre-defined Goals) Terminology mismatches handled by OO Mediators Example: Goal Refinement GG Mediator Mediation Service Source Goal 'Buy a ticket' Target Goal 'Buy a Train Ticket' postcondition: 'aTicket memberof trainticket'


WG & WW Mediators: WG andamp; WW Mediators WG Mediators: link a Web Service to a Goal and resolve occurring mismatches match Web Service and Goals that do not match a priori handle terminology mismatches between Web Services and Goals broader range of Goals solvable by a Web Service WW Mediators: enable interoperability of heterogeneous Web Services support automated collaboration between Web Services OO Mediators for terminology import with data level mediation Protocol Mediation for establishing valid multi-party collaborations Process Mediation for making Business Processes interoperable


Comparison to OWL-S: Comparison to OWL-S Mapping to WSDL communication protocol (RPC, HTTP, …) marshalling/serialization transformation to and from XSD to OWL Control flow of the service Black/Grey/Glass Box view Protocol Specification Abstract Messages Capability specification General features of the Service Quality of Service Classification in Service taxonomies


Perspective: Perspective OWL-S is an ontology and a language to describe Web services Strong relation to Web Services standards rather than proposing another WS standard, OWL-S aims at enriching existing standards OWL-S is grounded in WSDL and it has been mapped into UDDI Based on the Semantic Web Ontologies provide conceptual framework to describe the domain of Web services and an inference engine to reason about the domain Ontologies are essential elements of interoperation between Web services WSMO is a conceptual model for the core elements of Semantic Web Services core elements: Ontologies, Web Services, Goals, Mediators language for semantic element description (WSML) reference implementation (WSMX) Mediation as a key element Ontologies as data model every resource description is based on ontologies every data element interchanged is an ontology instance


OWL-S and WSMO: OWL-S and WSMO OWL-S uses Profiles to express existing capabilities (advertisements) and desired capabilities (requests) WSMO separates provider (capabilities) and requester points of view (goals) OWL-S profile ≈ WSMO capability + goal + non-functional properties


OWL-S and WSMO: OWL-S and WSMO Perspective: OWL-S Process Model describes operations performed by Web Service, including consumption as well as aggregation WSMO separates Choreography and Orchestration Formal Model: OWL-S formal semantics has been developed in very different frameworks such as Situation Calculus, Petri Nets, Pi-calculus WSMO service interface description model with ASM-based formal semantics OWL-S Process Model is extended by SWRL / FLOWS both approaches are not finalized yet OWL-S Process Model  WSMO Service Interfaces


OWL-S and WSMO: OWL-S provides default mapping to WSDL clear separation between WS description and interface implementation other mappings could be used WSMO also defines a mapping to WSDL, but aims at an ontology-based grounding avoid loss of ontological descriptions throughout service usage process ‘Triple-Spaced Computing’ as innovative communication technology OWL-S Grounding  current WSMO Grounding OWL-S and WSMO


Mediation in OWL-S and WSMO: Mediation in OWL-S and WSMO OWL-S does not have an explicit notion of mediator Mediation is a by-product of the orchestration process E.g. protocol mismatches are resolved by constructing a plan that coordinates the activity of the Web services …or it results from translation axioms that are available to the Web services It is not the mission of OWL-S to generate these axioms WSMO regards mediators as key conceptual elements Different kinds of mediators: OO Mediators for ensuring semantic interoperability GG, WG mediators to link Goals and Web Services WW Mediators to establish service interoperability Reusable mediators Mediation techniques under development


Semantic Representation: Semantic Representation OWL-S and WSMO adopt a similar view on the need of ontologies and explicit semantics but they rely on different logics: OWL-S is based on OWL / SWRL OWL represent taxonomical knowledge SWRL provides inference rules FLOWS as formal model for process model WSMO is based on WSML a family of languages with a common basis for compatibility and extensions in the direction of Description Logics and Logic Programming


OWL and WSML : OWL and WSML WSML aims at overcoming deficiencies of OWL Relation between WSML and OWL+SWRL to be completed OWL Lite OWL DL OWL Full WSML Flight WSML DL WSML Core WSML Rule WSML Full Description Logics full RDF(S) support subset Description Logics Logic Programming First Order Logic


Summary: Summary


Slide62: PART III: A Walkthru Example


Virtual Travel Agency Use Case: Virtual Travel Agency Use Case James is employed in DERI Austria and wants to book a flight and a hotel for the ISWC conference the start-up company VTA provides tourism and business travel services based on Semantic Web Service technology =andgt; how does the interplay of James, VTA, and other Web Services look like?


Goal Description: Goal Description 'book flight and hotel for the ICWS 2005 for James' goal capability postcondition: get a trip reservation for this goal _'http://www.wsmo.org/examples/goals/icws2005' importsOntology {_'http://www.wsmo.org/ontologies/tripReservationOntology', …} capability postcondition definedBy ?tripReservation memberOf tr#reservation[ customer hasValue fof#james, origin hasValue loc#innsbruck, destination hasValue loc#orlando, travel hasValue ?flight, accommodation hasValue ?conferenceHotel payment hasValue tr#creditcard ] and ?flight[airline hasValue tr#staralliance] memberOf tr#flight and ?hotel[name hasValue 'Sheraton Safari Hotel'] memberOf tr#hotel .


VTA Service Description: VTA Service Description book tickets, hotels, amenities, etc. capability description (pre-state) capability VTAcapability sharedVariables {?creditCard, ?initialBalance, ?item, ?passenger} precondition definedBy ?reservationRequest[ reservationItem hasValue ?item, passenger hasValue ?passenger, payment hasValue ?creditcard, ] memberOf tr#reservationRequest and ((?item memberOf tr#trip) or (?item memberOf tr#ticket)) and ?creditCard[balance hasValue ?initialBalance] memberOf po#creditCard. assumption definedBy po#validCreditCard(?creditCard) and (?creditCard[type hasValue po#visa] or ?creditCard[type hasValue po#mastercard]).


VTA Service Description: VTA Service Description capability description (post-state) postcondition definedBy ?reservation[ reservationItem hasValue ?item, customer hasValue ?passenger, payment hasValue ?creditcard ] memberOf tr#reservation . assumption definedBy reservationPrice(?reservation, 'euro', ?tripPrice) and ?finalBalance= (?initialBalance - ?ticketPrice) and ?creditCard[po#balance hasValue ?finalBalance] .


Web Service Discovery: Web Service Discovery James Objective: „book a flight and a hotel for me for the ICWS 2005.' Service Registry WS Discoverer has searches VTA result set includes Goal definition


Semantic Web Service Discovery: Semantic Web Service Discovery find appropriate Web Service for automatically resolving a goal as the objective of a requester Aims: high precision discovery maximal automation effective discoverer architectures Requirements: infrastructure that allows storage and retrieval of information about Web services description of Web services functionality description of requests or goals algorithms for matching requesters for capabilities with the corresponding providers


Discovery Techniques : Discovery Techniques different techniques available trade-off: ease-of-provision andlt;-andgt; accuracy resource descriptions andamp; matchmaking algorithms Key Word Matching match natural language key words in resource descriptions Controlled Vocabulary ontology-based key word matching Semantic Matchmaking … what Semantic Web Services aim at Ease of provision Possible Accuracy


Matchmaking Notions & Intentions: Matchmaking Notions andamp; Intentions Exact Match: G, WS, O, M ╞ x. (G(x) andlt;=andgt; WS(x) ) PlugIn Match: G, WS, O, M ╞ x. (G(x) =andgt; WS(x) ) Subsumption Match: G, WS, O, M ╞ x. (G(x) andlt;= WS(x) ) Intersection Match: G, WS, O, M ╞ x. (G(x)  WS(x) ) Non Match: G, WS, O, M ╞ ¬x. (G(x)  WS(x) ) = G = WS Keller, U.; Lara, R.; Polleres, A. (Eds): WSMO Web Service Discovery. WSML Working Draft D5.1, 12 Nov 2004.


Discovery Approach: Discovery Approach Matchmaking Notion to be used defined for each goal capability element Basic Procedure: Goal Capability Web Service Capability Assumption Precondition Effect Postcondition Assumption Precondition Effect Postcondition Plug-In Exact Intersection Exact valid pre-state? valid post-state? abort yes no abort yes no Match


Discoverer Architecture: Discoverer Architecture Discovery as central Semantic Web Services technology Integrated Discoverer Architectures admired: Resource Repository (UDDI or other) Keyword-/ Classification-based Filtering Controlled Vocabulary Filtering Semantic Matchmaking usable Web Service efficient narrowing of search space (relevant services to be inspected) retrieve Service Descriptions invoke Web Service


Service Interfaces: Service Interfaces Behavior Interface: how entity can interact Requested Interface send request select from offer receive confirmation Goal defines VTA VTA WS ‘Trip Booking’ Capability Interface (Chor.) get request provide offer receive selection send confirmation Interface (Orch.) flight request hotel request book flight book hotel Flight WS Capability Interface (Chor.) get request provide offer receive selection send confirmation Orch. .. Hotel WS Capability Interface (Chor.) get request provide offer receive selection send confirmation Orch. .. provides Requested Capability book flight andamp; hotel Choreography: interaction between entities Orchestration: service aggregation for realizing functionality


VTA Service Description: VTA Service Description Behavior Interface Transition 'get request' to 'provide offer' choreography VTABehaviorInterface importsOntology {_'http://www.wsmo.org/ontologies/tripReservationOntology', …} vocabularyIn {reservationRequest, …} vocabularyOut {reservation, …} guardedTransitions VTABehaviorInterfaceTransitionRules if (reservationRequest memberOf tr#reservationRequest[ reservationItem hasValue tr#trip, origin hasValue loc#city, destination hasValue loc#city, passenger hasValue tr#passenger] then reservationOffer memberOf tr#reservation[ reservationItem hasValue tr#trip, reservationHolder hasValue ?reservationHolder] .


Choreography Discovery: Choreography Discovery Requested Interface send request select from offer receive confirmation Goal defines VTA VTA WS ‘Trip Booking’ Capability Interface (Chor.) get request provide offer receive selection send confirmation Interface (Orch.) flight request hotel request book flight book hotel Flight WS Capability Interface (Chor.) get request provide offer receive selection send confirmation Orch. .. Hotel WS Capability Interface (Chor.) get request provide offer receive selection send confirmation Orch. .. provides Requested Capability book flight andamp; hotel - both behavior interfaces given ('static') correct andamp; complete consumption of VTA =andgt; existence of a valid choreography? - VTA Orchestration andamp; Behavior Interfaces of aggregated WS given =andgt; existence of a valid choreography between VTA and each aggregated WS? Choreography Discovery as a central reasoning task in Service Interfaces ‘choreographies’ do not have to be described, only existence determination =andgt; choreography discovery algorithm andamp; support from WSMO model


WSMO Service Interface Description Model: WSMO Service Interface Description Model common formal model for Service Interface description ontologies as data model based on ASMs not restricted to any executable communication technology general structure: Vocabulary Ω: ontology schema(s) used in service interface description usage for information interchange: in, out, shared, controlled States ω(Ω): a stable status in the information space defined by attribute values of ontology instances Guarded Transition GT(ω): state transition general structure: if (condition) then (action) different for Choreography and Orchestration additional constructs: add, delete, update


Service Interface Example: Service Interface Example Behavior Interface of a Web Service a memberOf A [ att1 hasValue x att2 hasValue y] a memberOf A [ att1 hasValue x, att2 hasValue y] b memberOf B [ att2 hasValue m] IF (a memberOf A [ att1 hasValue x ]) THEN (b memberOf B [ att2 hasValue m ]) State ω1 Guarded Transition GT(ω1) State ω2 Vocabulary: - Concept A in Ωin - Concept B in Ωout received ontology instance a sent ontology instance b Ωin hasValues { concept A [ att1 ofType X att2 ofType Y] …} Ωout hasValues { concept B [ att1 ofType W att2 ofType Z] …}


Choreography Discovery: internal business logic of Web Service (not of interest in Service Interface Description) Choreography Discovery internal business logic of Web Service (not of interest in Service Interface Description) a valid choreography exists if: 1) Information Compatibility compatible vocabulary homogeneous ontologies 2) Communication Compatibility start state for interaction a termination state can be reached without any additional input


Information Compatibility: Information Compatibility If choreography participants have compatible vocabulary definitions: Ωin(S1) and Ωshared(S1) = Ωout(S2) and Ωshared(S2) determinable by Intersection Match from Discovery SIS1, SIS2, O, M ╞ x. (ΩS1(in U shared)(x)  ΩS2(out U shared)(x)) more complex for multi-party choreographies Prerequisite: choreography participants use homogeneous ontologies: semanticInteroperability(S1, S2, …, Sn) same ontologies in Service Interfaces, or usage of respective OO Mediators


Communication Compatibility : Communication Compatibility Definitions (for 'binary choreography' (only 2 services), more complex for multi-party choreographies) Valid Choreography State: ωx(C(S1, S2)) if informationCompatibility (ΩS1(ωx), ΩS2(ωx)) means: action in GT of S1 for reaching state ωx(S1) satisfies condition in GT of S2 for reaching state ωx(S2), or vice versa Start State: ωØ(C(S1, S2)) if ΩS1(ωØ)=Ø and ΩS2(ωØ)=Ø and  ω1(C(S1, S2)) means: if initial states for choreography participants given (empty ontology, i.e. no information interchange has happened), and there is a valid choreography state for commencing the interaction Termination State: ωT(C(S1, S2)) if ΩS1(ωT)=noAction and ΩS2(ωT)=noAction and  ωT(C(S1, S2)) means: there exist termination states for choreography participants (no action for transition to next state), and this is reachable by a sequence of valid choreography states Communication Compatibility given if there exists a start state and a termination state is reachable without additional input by a sequence of valid choreography states


Communication Compatibility Example: Communication Compatibility Example ΩS1(ωØ) = {Ø} ΩS1(ω1) = {request(out)} ΩS1(ω2a) = {offer(in), changeReq(out)} if Ø then request ΩS2(ωØ) = {Ø} ΩS2(ω1) = {request(in), offer(out)} if request then offer if cnd1(offer) then changeReq ΩS1(ω2b) = {offer(in), order(out)} if cnd2(offer) then order ΩS2(ω2a) = {changeReq(in),offer(out)} if changeReq then offer ΩS2(ω2b) = {order(in), conf(out)} if order then conf ΩS1(ω3) = {offer(in), conf(in)} if conf then Ø James’ Goal Behavior Interface VTA Behavior Interface


WW Mediators in Choreography: internal business logic of Web Service (not of interest in Service Interface Description) internal business logic of Web Service (not of interest in Service Interface Description) WW Mediators in Choreography if a choreography does not exist, then find an appropriate WW Mediator that resolves possible mismatches to establish Information Compatibility (OO Mediator usage) resolves process / protocol level mismatches in to establish Communication Compatibility Choreography WW Mediator


Orchestration: Orchestration formally described service functionality decomposition only those aspects of WS realization wherefore other WS are aggregated aggregated WS used via their behavior interface Control Structure for aggregation of other Web Services Web Service Business Logic 1 2 3 4


Orchestration Description & Validation : Orchestration Description andamp; Validation Orchestration Description: interaction behavior of 'Orchestrator' with 'orchestrated Web Services' WSMO Service Interface description model, extension of Guarded Transitions general structure: if condition then operation Operation = (Orchestrator, Web Service, Action) Orchestrator serves as client for aggregated Web Services Orchestration Validation: need to ensure that interactions with aggregated Web Service can be executed successfully =andgt; Choreography Discovery for all interaction of Orchestrator with each aggregated Web Service


Orchestration Validation Example: Orchestration Validation Example if Ø then (FWS, flightRequest) if request then offer if order then confirmation VTA Web Service Orchestration Start (VTA, FWS) Termination (VTA, FWS) if flightOffer then (HWS, hotelRequest) if selection then (FWS, flightBookingOrder) if selection, flightBookingConf then (HWS, hotelBookingOrder) Flight WS Behavior Interface if request then offer if order then confirmation Hotel WS Behavior Interface Start (VTA, HWS) Termination (VTA, HWS) Orchestration is valid if valid choreography exists for interactions between Orchestrator and each aggregated Web Service, done by choreography discovery


Service Composition and Orchestration: Service Composition and Orchestration Web Service Composition: the realization of a Web Service by dynamically composing the functionalities of other Web Services The new service is the composite service The invoked services are the component services a composite service can provide the skeleton for a Web Service (e.g. the VTA Web Service) Current Composition techniques only cover aspects for valid orchestrations partially functional Web Service composition (on capability descriptions) dynamic control and data flow construction for composite Web Service delegation of client / goal behavior to component services =andgt; Orchestration Validation needed to ensure executable Web Service aggregations


Composition System Overview(from Berardi, ESWC 2005 Semantic Web Services Tutorial) : Composition System Overview (from Berardi, ESWC 2005 Semantic Web Services Tutorial)


Conclusions: Conclusions Semantic Web Service descriptions require expertise in ontology andamp; logical modeling =andgt; tool support for users andamp; developers under development understanding of Semantic Web Service technologies what it does, and how it works which are the related descriptive information Semantic Web Service technologies aim at automation of the Web Service usage process users only define goal with tool support ‘intelligent’ SWS middleware for automated Web Service usage state of the art in technology andamp; tool development theoretical approaches are converging; standardization efforts prototypical SWS technologies existent industrial strength SWS technology suites aspired in upcoming efforts


Slide89: PART IV: The Web Service Execution Environment WSMX Aims andamp; Design Principles WSMX Development Process and Releases Components and System Architecture Components Event-based Implementation System Entry Points Execution Semantics


WSMX Introduction: WSMX Introduction Software framework for runtime binding of service requesters and service providers WSMX interprets service requester’s goal to discover matching services select (if desired) the service that best fits provide data mediation (if required) make the service invocation is based on the conceptual model provided by WSMO has formal execution semantics SO and event-based architecture based on microkernel design using technologies as J2EE, Hibernate, Spring, JMX, etc.


Design Principles: Design Principles Strong Decoupling andamp; Strong Mediation autonomous components with mediators for interoperability Interface vs. Implementation distinguish interface (= description) from implementation (=program) Peer to Peer interaction between equal partners (in terms of control) WSMO Design Principles == WSMX Design Principles == SOA Design Principles


WSMX Usage Scenario: WSMX Usage Scenario


Development Process & Releases: Development Process andamp; Releases The development process for WSMX includes: Establishing its conceptual model Defining its execution semantics Develop the architecture Design the software Building a working implementation Planned releases:


Components & System Architecture: Components andamp; System Architecture


Selected Components: Selected Components Adapters Parser Invoker Choreography andamp; Process Mediator Matchmaker Data Mediator Resource Manager


Adapters: Adapters to overcome data representation mismatches on the communication layer transforms the format of a received message into WSML compliant format based on mapping rules


Parser: Parser WSML 1.0 compliant parser Code handed over to wsmo4j initiative Validates WSML description files Compiles WSML description into internal memory model Stores WSML description persistently (using Resource Manager)


Invoker: Invoker WSMX V0.1 used the SOAP implementation from Apache AXIS Web Service interfaces were provided to WSMX as WSDL Both RPC and Document style invocations possible Input parameters for the Web Services were translated from WSML to XML using an additional XML Converter component. Network Invoker Apache AXIS XML Converter Mediated WSML Data XML Web Service SOAP


Choreography & Process Mediator: Choreography andamp; Process Mediator 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 Choreography Engine andamp; Process Mediator provides the means for runtime analyses of two choreography instances and uses mediators to compensate possible mismatches


Matchmaker: Matchmaker responsible for finding appropriate Web Services to achieve a goal (discovery) currently the built-in matchmaking is performed by simple string-based matching; advanced semantic discoverers in prototypical stage


OOMediator: OOMediator Ontology-to-ontology mediation A set of mapping rules are defined and then executed Initially rules are defined semi-automatic Create for each source instance the target instance(s)


Resource Manager: 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


Event-based Implementation: Event-based Implementation


System entry points: System entry points storeEntity(WSMOEntity):Confirmation provides an administration interface for storing any WSMO-related entities (Web Services, Goals, Ontologies) realizeGoal(Goal, OntologyInstance):Confirmation service requester expects WSMX to discover and invoke Web Service without exchanging additional messages receiveGoal(Goal, OntologyInstance, Preferences):WebService[] list of Web Services is created for given Goal requester can specify the number of Web Services to be returned receiveMessage(OntologyInstance,WebServiceID, ChoreographyID):ChoreographyID back-and-forth conversation to provide all necessary data for invocation involves execution of choreographies and process mediation between service interfaces


System Entry Points: System Entry Points


Execution Semantics: Execution Semantics Request to discover Web services.


Execution Semantics: Goal expressed in WSML is sent to WSMX System Interface Execution Semantics


Execution Semantics: Com. M. implements the interface to receive WSML goals Execution Semantics


Execution Semantics: Com. M. informs Core that Goal has been received Execution Semantics


Execution Semantics: Chor. wrapper picks up event for Chor. component Execution Semantics


Execution Semantics: New choreography Instance is created Execution Semantics


Execution Semantics: Core is notified that choreography instance has been created. Execution Semantics


Execution Semantics: WSML goal is parsed to internal format. Execution Semantics


Execution Semantics: Discovery is invoked for parsed goal. Execution Semantics


Execution Semantics: Discovery may requires ontology mediation. Execution Semantics


Execution Semantics: After data mediation, Discovery iterates, if needed through last steps until result set is finished. Execution Semantics


Execution Semantics: Selection is invoked to relax result set to finally one service. Execution Semantics


Execution Semantics: Choreography instance for goal requester is checked for next steps. Execution Semantics


Execution Semantics: Result is returned to Com. Man. to be forwarded to the service requester. Execution Semantics


Execution Semantics: Set of Web Service descriptions expressed in WSML sent to adapter. Execution Semantics


Execution Semantics: Set of Web Service descriptions expressed in requester’s own format returned to goal requester. Execution Semantics


Conclusions: Conclusions Conceptual model is WSMO (with some add-ons) End to end functionality for executing SWS Has a formal execution semantics Real implementation Open source code base at SourceForge Event-driven component architecture Developers welcome


WSMX @ Sourceforge.net: WSMX @ Sourceforge.net


Slide124: Closing, Outlook, Acknowledgements


Tutorial Wrap-up: Tutorial Wrap-up The targets of the presented tutorial were to: understand aims andamp; challenges within Semantic Web Services understand Semantic Web Service Frameworks: aims, design principles, and paradigms ontology elements andamp; description an overview of Semantic Web Service techniques: element description discovery choreography and service interoperability determination orchestration and composition present WSMX a future Web Service based IT middleware design and architecture components design =andgt; you should now be able to correctly assess emerging technologies andamp; products for Semantic Web Services and utilize these for your future work


Beyond WSMO: Beyond WSMO Although WSMO (and OWL-S) are the main initiatives on Semantic Web services, they are not the only ones: Semantic Web Services Interest Group Interest group founded at W3C to discuss issues related to Semantic Web Services (http://www.w3.org/2002/ws/swsig/) Standardization Working Group in starting phase SWSI: International initiative to push toward a standardization of SWS (http://www.swsi.org) Semantic Web services are entering the main stream UDDI is adopting OWL for semantic search WSDL 2 will contain a mapping to RDF The use of semantics is also discussed in the context of standards for WS Policies


Acknowledgements: Acknowledgements The WSMO work is funded by the European Commission under the projects DIP, Knowledge Web, SEKT, SWWS, AKT and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program. We would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this tutorial.