Aplicatii Web bazate pe semantica, agenti si servicii http://turing.cs.pub.ro/webs_078 Universitatea Politehnica Bucuresti Anul universitar 2008-2009, Master Adina Magda Florea

Servicii Web Semantice Web Semantic si Servicii Web Semantice Infrastructura SWS Ontologii pentru SWS: OWL-S si WSMO

Standarde pentru servicii Web Sematic Web Services

1. Evolutie WWW Semantic Web Static Probleme legate de: regasirea informatiei, extragerea informatiei, reprezentarea informatiei, interpretarea informatiei actualizarea informatiei WWW URI, HTML, HTTP Semantic Web RDF, RDF(S), OWL Static

Evolutie Web Services WWW Semantic Web Dinamic Static UDDI, WSDL, SOAP URI, HTML, HTTP Semantic Web RDF, RDF(S), OWL Static

Evolutie Semantic Web Services Web Services WWW Semantic Web Dynamic Intregul potential al web-ului Semantic Web Services Web Services UDDI, WSDL, SOAP Dynamic WWW URI, HTML, HTTP Semantic Web RDF, RDF(S), OWL Static

Limitari ale WS curente Tehnologiile curente (WSDL, SOAP, UDDI) permit utilizarea WS dar: descrieri ale informatiei la nivel sintactic suport exclusiv sintactic pentru descoperire, compunere si executie => utilizarea si integrarea WS trebuie sa fie irealizata manual nu exista marcare semntica a continutului serviciilor nu exista suport pentru Web Semantic

Servicii Web Semantice Tehnologia Web Semantic + Tehnologia WS permite interpretarea semantica automata a datelor folosirea ontologiilor ca model al datelor permite descoperire, selectie, compunere si executie a WS  Servicii Web Semantice ca solutie integrata pentru realizarea noii generatii a Web

2. Infrastructura SWS Activitati/utilizare Arhitectura Suport executie Monitoring Compensation Replacement Auditing Activitati/utilizare Composition Execution Publication Discovery Selection Mediation Nivel Business Arhitectura Activitatile utilizator definesc cerintele functionale pe care trebuie sa le posede un framework pentru SWS Arhitectura SWS defineste componentele necesare pentru realizarea acestor activitati Ontologia serviciului combina toate modelele conceptuale legate de descrierea unui SWS si reprezinta modelul de cunostinte al informatiei ce descrie si indica modul de folosire a serviciului. Matchmaker Register Decomposer Reasoner Invoker Nivel fizic Ontologia serviciului input output Pre-condition Cost Atomic service Composite service Post-condition Nivel conceptual

Infrastructura SWS Activitatile/utilizarea definesc cerintele functionale pe care trebuie sa le posede un framework pentru SWS Arhitectura SWS defineste componentele necesare pentru realizarea acestor activitati Ontologia serviciului combina modelele conceptuale legate de descrierea unui SWS si reprezinta modelul de cunostinte al informatiei ce descrie serviciul si indica modul de folosire a serviciului.

2.1 Activitati SWS este vazut ca un obiect dintr-un scenariu a unei aplicatii de business Publication: permite accesul la descrierea unui serviciu Discovery: Localizarea diferitelor servicii pentru un anumit task Selection: Alege cel mai potrivit serviciu dintre mai multe disponibile Composition: Combina mai multe servicii pentru satisfacerea unui scop Mediation: Rezolva nepotriviri (date, protocol, procese) intre servicii compuse Invocation / Execution: Invoca serviciile folosind conventii specifice

Activitati Publication SWS: Publicarea unui SWS permite descoperirea serviciilor pe baza scopului sau a capacitatilor serviciului Ontologia serviciului este inregistrata intr-un registru semantic (semantic registry) Ontologia serviciului separa informatia utilizata pentru matching in timpul descoperirii de cea utilizata de serviciu la invocare. Ontologia serviciului trebuie legata si de o ontologie a domeniului. Discovery SWS: Matchmaking semantic intre descrierea serviciului cerut si descrierea publicata a serviciului Registrul semantic se inspecteaza ca urmare a cererilor; acestea pot contine nume, input, output, preconditii dar si alte atribute. Matching-ul poate fi facut si la nivelul task-urilor sau scopurilor care se doresc. Matching-ul poate fi bazat pe anumite criterii cum ar fi mostenirea relatiilor de tipuri

Activitati Categorii de "Matching semantic": Exact = iesirile cerute sunt la fel cu cele ale SWS Plug-in = iesirile cerute sunt subsumate de cele ale SWS Ex: un serviciu care ofera toate tipurile de vehicule este un "plug-in match" pentru o cerere de tipuri de masini (sacrifica precizia ceruta) Subsumeaza = iesirile cerute subsumeaza cele ale SWS Ex: un serviciu care ofera informatii despre masini este un "subsuming match" pentru o cerere care se refera la tipuri de vehicule (sacrifica nivelul de detaliu cerut)

Activitati Selection SWS: Necesara daca exista mai multe servicii potrivite cererii. Se pot folosi atribute ne-functionale: cost, calitate In mediu agenti – negociere Composition SWS: Compunere (coreografie) – SWS compus definit in terenii unor servicii mai simple. Workflow – poate fi definit in ontologia serviciului folosind structuri de control Aceasta descriere poate fi ancorata intr-o descriere sintactica, de ex WSBPEL Compunere dinamica la cerere

Activitati Invocation / Execution SWS: Invocarea unui SWS implica un numar de pasi, odata ce s-au obtinut intrarile necesare. Ontologia serviciului si ontologia domeniului asociate serviciului sunt instantiate Intrarile sunt validate fata de tipurile din ontologie Sercviciul este invocat = workflow-ul este executat prin grounding-ul specificat

Suportul executiei Monitoring: Controlul procesului de executie Compensation: Ofera suport pentru tranzactii si anularea efectelor nedorite in caz de esec Replacement: Faciliteaza substitutia serviciilor cu servicii echivalente Auditing: Verifica ca executia serviciului a avut loc conform specificatiilor

2.2 Arhitectura Reasoner = utilizat in timpul tuturor activitatilor; ofera suport pentru interpretarea descrierilor semantice si a cererilor semantice. Register = ofera meacnismele de publicare si localizare a serviciilor + crearea si editarea de servicii Matchmaker = mediaza intre cererea de serviciu si registrul semantic in timpul descoperirii si selectiei Decomposer = executa modelul compozitional Invoker = mediaza intre cerere si ofertanat sau cerere si decomposer Arhitectura Matchmaker Register Decomposer Reasoner Invoker

2.3 Ontologia serviciului Ontologia serviciului reprezinta capacitatile serviciului si restrictiile care se aplica utilizarii acestuia. Ontologia serviciului integreaza cunostintele definite prin informatii la nivelul standardelor de servicii (WSDL, UDDI) cu cunostinte specifice domeniului: caracteristici functionale: inputs, output, pre-conditions, post-conditions; caracteristici nefunctionale: category, cost, quality of service; informatii legate de ofertantul de serviciu: company name, address informatii legate de taskul de executat sau de scopul dorit cunostinte ale domeniului, de ex tipul intrarilor

3. Ontologii pentru SWS WSMO – Europa OWL-S – USA http://www.w3.org/Submission/OWL-S/ WSMO – Europa European Semantic Systems Initiative http://www.essi-cluster.org/about-essi/essi-home/ WSMX (Web Service Modelling eXecution environment) – implementarea de referinta a WSMO (Web Service Modelling Ontology) Un mediu de executie pentru integrarea aplicatiilor de business WSML (Web Service Modelling Language) – limbajul intern al WSMX Specificatiile WSMO si WSML + mediul WSMX - ESSI cluster.

3.1 OWL-S Upper Ontology Service Profile Process Model Service Grounding

OWL-S Upper Ontology Specificarea capabilitatilor SWS Caracteristici generale ale SWS Calitatea serviciului Clasificare in taxonomii de servicii Maparea la WSDL protocolul de comunicare (RPC, HTTP, …) serializare transformare din/in XSD in/din OWL Fluxul de control al serviciului Black/Grey/Glass Box view Specificarea protocolului Mesaje abstracte

Upper Ontology for Services OWL-S Upper Ontology Upper Ontology for Services http://www.daml.org/services/owl-s/1.0/ Service.owl Profile.owl Process.owl Grounding.owl

Service Profiles Service Profile Prezentat de serviciu Reprezinta ce ofera serviciul Doua utilizari principale: Reclama capabilitatilor serviciului Cerere de servicii cu anumite capabilitati

OWL-S Profile Descrie serviciul Web Ce capabilitati ofera: Ce transformari realizeaza serviciul Tipul serviciului Caracteristici generale cum ar fi: Cine ofera serviciul Cerinte de securitate Calitatea serviciului Rolul de baza: sa asiste descoperirea Permite cautarea pe baza de capabilitati Permite selectia pe baza cerintelor utilizatorului Profilul nu specifica utilizarea/invocarea

OWL-S Service Profile Capabilitati serviciu Preconditions Conditiile care trebuie indeplinite inainte de invocarea serviciului Inputs Multimea de intrari pe care utilizatorul trebuie sa le furnizeze pentru a invoca serviciul Outputs Rezultatele pe care utilizatorul se asteapta sa le obtina dupa ce se finalizeaza interactiunea cu ofertantul de serviciu Effects Multimea de asertiuni care sunt adevarate daca serviciul este invocat cu succes IOPE (Inputs, Outputs, Preconditions, Effects) – specifica functionalitatea procesului Service type Ce tip de serviciu se ofera (eg vanzare, distributie) Product Produsul asociat serviciului (eg calatorii, carti, piese auto)

OWL-S Service Profile Proprietati suplimentare Security Parameters Capabilitatile de securitate ale serviciului (eg suporta X509 Encryption) Specifica cerintele de securitate ale serviciului (eg clientul trebuie sa fie capabil sa ofere X509 Encryption) Nivelul de calitate Ce nivel de calitate ofera serviciul? Descrierea cu ajutorul taxonomiilor standard de business Cum se clasifica serviciul in taxonomii standard cum ar fi: UNSPSC (The United Nations Standard Products and Services Code – classification of products and services) NAICS (North American Industry Classification System - definitions for each industry) Aceste proprietati nu sunt exhaustive; se pot adauga noi proprietati folosind ontologii existente

Process Model Process Model Permite Descrie modul in care lucreaza serviciul: procesele interne ale serviciului Specifica protocolul de interactiune al serviciului Specifica mesaje abstracte: tipul ontologic al informatiei transmise Permite Invocarea serviciului Compunerea serviciilor Monitorizarea interactiunilor

Perspective asupra Process Model Trei perspective asupra unui WS Glass Box: Serviciul Web expune intreaga structura interna Care parti sunt executate de catre ofertant, care sunt subcontractate, etc Black Box: Modelul WS nu expune nimic despre modul intern in care functioneaza serviciul Specifica numai ce date primeste si ce date ofera Grey Box: WS expune selectiv parti ale Process Model, unele parti fiind ascunse

Definirea proceselor Procesul este caracterizat de urmatorii parametrii Inputs: intrarile necesare procesului Preconditions: conditiile necesare procesului pentru a functiona corect Outputs: informatia care rezulta prin (si este intoarsa de) executia procesului Results: un proces poate avea rezultate diferite in functie de diverse conditii Condition: in ce conditii se obtine rezultatul Constraints on Outputs Effects: schimbari asupra lumii ce rezulta ca efect al executiei procesului

Motivatia pentru Results Un proces se poate termina in stari exceptionale: Compania de carti de credit nu face debitarea cardului Cartea nu mai este in stoc Expedierea bunurilor este impiedicata Rezultatele permit modelarea efectelor nedeterministe a unui serviciu Web Conditiile specifica cand se produce un anumit efect Fiecare efect este caracterizat de o multime de restrictii asupra iesirilor o multime de consecinte

Exemplu de proces Inputs / Outputs Precondition Condition Result <process:AtomicProcess rdf:ID="LogIn"> <process:hasInput rdf:resource="#AcctName"/> <process:hasInput rdf:resource="#Password"/> <process:hasOutput rdf:resource="#Ack"/> <process:hasPrecondition isMember(AccName)/> <process:hasResult> <process:Result> <process:inCondition> <expr:SWRL-Condition> correctLoginInfo(AccName,Password) </expr:SWRL-Condition> </process:inCondition> <process:withOutput rdf:resource=“#Ack“> <valueType rdr:resource=“#LoginAcceptMsg”> </process:withOutput> <process:hasEffect> loggedIn(AccName,Password) </process:hasEffect> </process:Result> </process:hasResult> </process:AtomicProcess> Inputs / Outputs Precondition Condition Result Output Constraints Effect

Ontologia proceselor Process Atomic Simple Composite Poate fi invocat prin grounding Ofera abstractizare, incapsulare etc. Composite Defineste workflow al unui proces compus

Organizarea modelului de proces Process Model este descris ca o structura arborescenta Procesele compuse sunt noduri interne Procesele simple si atomice sunt frunze Procesele simple reprezinta o abstractizare a proceselor care nu sunt specificate a proceselor care pot fi exprimate in diferite moduri Procesele atomice corespund actiunilor de baza pe care le executa serviciul Web Ascund detaliile despre cum se implementeaza procesul Corespund operatiilor WSDL

Procese compuse Procesele compuse specifica modul in care mai multe procese lucreaza impreuna pentru realizarea unei functii complexe Procesele compuse definesc Fluxul de control Specifica relatiile temporale intre executia diverselor sub-procese Fluxul de date Specifica modul in care datele produse de un proces sunt transferate unui alt proces

Exemplu de proces compus Legaturi flux de control Specifica ordinea executiei Sequence BookFlight Airline Flight Legaturi flux de date Specifica transferul de date Perform Perform Airline Select Flight Get Flights Flights Flights Flight Depart Arrive Perform Specifica executia unui proces

Perform Perform ofera un mecanism de invocare specifica contextul executiei procesului fluxul de date de intrare fluxul de date de iesire Separarea intre definirea si invocarea unui proces Definitia specifica procesul I/P/R Perform specifica cand se invoca procesul si cu ce parametrii

Fluxul de control Procesele pot fi inlantuite pentru a forma un workflow OWL-S ofera urmatoarele structuri de control Sequence/Any-Order: reprezinta o lista de procese care sunt executate in secventa sau in ordine arbitrara Conditionals: instructiuni if-then-else Loops: instructiuni while si repeat-until Multithreading and synchronization: divizeaza (split) procesul in mai multe fire de executie si creaza puncte de rendezvous (joint) Non-deterministic choices: selecteaza arbitrar un proces dintr-o multime de procese

Fluxul de date Fluxul de date permite transferul informatiei de la un proces la altul. OutputInput: Informatia produsa de un proces este transferata altui proces in aceeasi structura de control Input Input: Informata primita de un proces compus este transferata sub-proceselor OutputOutput: Informatia produsa de un sub-proces este transferata unui super-proces

Process Model: rezumat Modelul serviciului descrie Multimea de procese care definesc operatiile executate de un WS Fluxul de control care descrie inlantuirea temporala a proceselor Fluxul de date care descrie transferul informatiei intre sub-procese

Service Grounding Service Grounding Ofera o specificare a informatiei de acces la un serviciu Service Model + Grounding ofera tot ceea ce este necesar pentru utilizarea serviciului Utilizeaza WSDL pentru a defini structura mesajelor si nivelul de legare fizica Specifica: protocoalele de comunicare, mecanismele de transport, limbajele de comunicare, etc.

Motivatia pentru Service Grounding Ofera o specificare a informatiei prin care se poate accesa serviciul Service Model + Grounding ofera tot ceea ce este necesar pentru a utiliza un serviciu Descrierea serviciului este destinat in special pentru a efectua rationamente asupra serviciului Decide ce informatii sa se trimita si ce informatii se vor primi Service Grounding este destinat in specail schimbului de mesaje Genereaza mesaje de iesire si primeste mesaje de intrare Mapeaza XML Schema la concepte OWL Utilizeaza WSDL pentru definirea structurii mesajelor si a nivelului de legare fizica

Mapare OWL-S / WSDL 1.1 Operatiile corespund la Atomic Processes Mesajele de Input/Output corespund la Inputs/Outputs a proceselor

Exemplu de Grounding Sequence Perform Perform Select Flight BookFlight Airline Flight Perform Perform Airline Select Flight Get Flights Flights Flights Flight Depart Arrive Arrive Get Flights Op Select Flight op Depart Flights Flights Flight Airline WSDL

Rezultatul utilizarii Grounding Mecanismul de invocare pentru OWL-S Invocare bazata pe WSDL Diversele tipuri invocare din WSDL pot fi folosite in OWL-S Separare clara intre descrierea serviciului si invocare / implementare Descrierea serviciului este necesara pentru a rationa despre serviciu a decide cum este utilizat decide ce informatie si cum se transmite si se primeste Implementarea serviciului poate fi bazata pe SOAP si tipuri XML Schema Definition (XSD) Esential: informatia care se schima si informatia din ontologii este aceeasi Permite reprezentarea oricarui serviciu web in OWL-S

Exemple http://www.daml.org/services/owl-s/1.0/examples.html Profile Hierarchy A Profile-based class hierarchy of service categories: ProfileHierarchy.owl Profile-based Class Hierarchies (HTML) - explanatory remarks for ProfileHierarchy.owl. Congo.com (fictitious B2C site) CongoService.owl - Service instance CongoProfile.owl –Profile CongoProcess.owl - Process model (main file) CongoProcessDataFlow.owl - Process model data flow (argument bindings) CongoGrounding.owl - Grounding instances CongoGrounding.wsdl - WSDL definitions for grounding

Exemple Diverse exemple de servicii atomice si compuse in OWL-S http://www.mindswap.org/2004/owl-s/services.shtml

3.2 WSMO WSMO aims & objectives Design Principles Top Level Notions Ontologies Web Services Goals Mediators

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 A Conceptual Model for SWS A Formal Language for WSMO Execution Environment for WSMO A Rule-based Language for SWS

WSMO Design Principles Web Compliance Ontology-Based Strict Decoupling Centrality of Mediation Ontological Role Separation Description versus Implementation Execution Semantics

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

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 & 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 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)

WSMO Web Services 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 Web Service Description complete item description quality aspects Web Service Management Advertising of Web Service Support for WS Discovery Non-functional Properties DC + QoS + Version + financial Capability functional description 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 Web Service Implementation (not of interest in Web Service Description) WS WS WS Choreography --- Service Interfaces --- Orchestration

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 VTA example: Choreography = how to interact with the service to consume its functionality Orchestration = how service functionality is achieved by aggregating other Web Services VTA Service Date Time Flight, Hotel Error Confirmation Hotel Service Flight Service Date, Time Hotel Flight When the service is requested When the service requests

Interface for consuming Web Service Choreography Aspects Interface for consuming Web Service 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

Orchestration Aspects Control Structure for aggregation of other Web Services State in Orchestration Control Flow Data Flow Service Interaction 1 WS Web Service Business Logic 3 2 decomposition of service functionality all service interaction via choreographies WS 4

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 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 & 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 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

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

Future Directions 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 & data flow constructs between orchestrating WS and orchestrated WSs. Conceptual models User language - based on UML2 activity diagrams - graphical Tool for Editing & Browsing Service Interface Description 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) Formal description of service interfaces: - ASM-based approach - allows reasoning & mediation Ontologies as data model: - every resource description based on ontologies - every data element interchanged is ontology instance Grounding: - making service interfaces executable - currently grounding to WSDL

WSMO Goals 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

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 definition by reusing an already existing goal 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 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

Mediation Heterogeneity … Concept of Mediation (Wiederhold, 94): Mismatches on structural / semantic / conceptual / level Occur between different components that shall interoperate Especially in distributed & 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

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

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

GG Mediators Aim: Example: Goal Refinement 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 Mediators: WW 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

3.3 OWL-S and WSMO Elemente comune si diferente

Outline Perspectives Relation of Ontology Elements Interoperability and Mediation Semantic Representation

OWL-S Perspective OWL-S is an ontology and a language to describe Web services guiding lines for the development of OWL-S 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 Build upon 30 years of AI research on Knowledge Representation and Planning

WSMO Perspective WSMO is a conceptual model for the core elements of Semantic Web Services core elements: Ontologies, Web Services, Goals, Mediators ontology for precise, unambiguous, element description language for semantic element description (WSML) reference implementation (WSMX) Focus on solving the integration problem Mediation as a key element Ontologies as data model every resource description is based on ontologies every data element interchanged is an ontology instance Based on Knowledge Engineering and B2B Integration experience

OWL-S and WSMO Request OWL-S profile ≈ WSMO capability + goal + non-functional properties Request OWL-S uses Profiles to express existing capabilities (advertisements) and desired capabilities (requests) WSMO separates provider (capabilities) and requester points of view (goals) Conceptually, OWL-S requested profile and WSMO goal are not exactly the same Requested service profile vs requester objectives

both approaches are not finalized yet OWL-S and WSMO OWL-S Process Model  WSMO Service Interfaces 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 Grounding  current WSMO Grounding OWL-S and WSMO OWL-S Grounding  current WSMO Grounding 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

Mediation and Interoperation Interaction of Web services is bound to produce many forms of mismatch Data mismatch: the interacting parties do not agree on the data format that they are using Ontology mismatch: the interacting parties refer to different ontologies Protocols mismatch: the interacting parties expect information at different times Goals Mismatch: the interacting parties attempt to achieve very different goals Interpretations Mismatch: The interacting parties interpret the same information in very different ways These mismatches need to be reconciled for the interoperation to succeed. Mediators are the components that reconcile these mismatches

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 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 vs WSML WSML aims at overcoming deficiencies of OWL OWL Full WSML Full full RDF(S) support First Order Logic WSML Rule OWL DL WSML DL WSML Flight Description Logics Description Logics OWL Lite WSML Core Logic Programming subset WSML aims at overcoming deficiencies of OWL Relation between WSML and OWL+SWRL to be completed

3.4 Instrumente OWL-S Plug-in OWL-S pentru Protégé OWL-S IDE (CMU) WSMO WSMX = Web Service Execution Environment

Slide-urile despre WSMO includ o parte din cele prezentate la Sematic Web Service Tutorial, ESWC 2005, Heraklion, Grecia