Presentation is loading. Please wait.

Presentation is loading. Please wait.

Aplicatii Web bazate pe semantica, agenti si servicii Universitatea Politehnica Bucuresti Anul universitar 2008-2009, Master Adina Magda Florea

Similar presentations


Presentation on theme: "Aplicatii Web bazate pe semantica, agenti si servicii Universitatea Politehnica Bucuresti Anul universitar 2008-2009, Master Adina Magda Florea"— Presentation transcript:

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

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

3 Standarde pentru servicii Web Sematic Web Services

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

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

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

7 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

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

9 2. Infrastructura SWS Activitati/utilizare Arhitectura Ontologia serviciului PublicationDiscoverySelection Composition Mediation Execution RegisterDecomposerReasonerInvoker Matchmaker Post-condition inputoutput Pre-conditionCostAtomic service Composite service Suport executie Monitoring Compensation Replacement Auditing Nivel Business Nivel fizic Nivel conceptual

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

11 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

12 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

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

14 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

15 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

16 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

17 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 RegisterDecomposerReasonerInvoker Matchmaker Arhitectura

18 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

19 3. Ontologii pentru SWS 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.

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

21 OWL-S Upper Ontology 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 Specificarea capabilitatilor SWS Caracteristici generale ale SWS Calitatea serviciului Clasificare in taxonomii de servicii

22 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

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

24 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

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

26 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

27

28

29

30 Process Model 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

31 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

32 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

33 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

34 Exemplu de proces correctLoginInfo(AccName,Password) loggedIn(AccName,Password) Inputs / Outputs Result Condition Effect Output Constraints Precondition

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

36 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

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

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

39 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

40 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

41 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

42 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

43

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

45 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

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

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

48 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: Esential: informatia care se schima si informatia din ontologii este aceeasi Permite reprezentarea oricarui serviciu web in OWL-S

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

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

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

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

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

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

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

56 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

57 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

58 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

59 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 Usage & Principles

60 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 Axiomsaxiomatic expressions in ontology (logical statement) Ontology Specification

61 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

62 WSMO Web Service Description Web Service Implementation (not of interest in Web Service Description) Choreography --- Service Interfaces --- Capability functional description WS - 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 WS Orchestration

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

64 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 Error Date, Time Flight Error When the service is requested When the service requests

65 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

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

67 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: 1. represent the dynamics of information interchange during service consumption and interaction 2. support ontologies as the underlying data model 3. appropriate communication technology for information interchange 4. sound formal model / semantics of service interface specifications in order to allow operations on them.

68 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

69 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

70 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

71 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 & 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 & 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 & Browsing Service Interface Description

72 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

73 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

74 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

75 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

76 Mediation Heterogeneity … 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): (1) Data Level: mediate heterogeneous Data Sources (2) Protocol Level: mediate heterogeneous Communication Patterns (3) Process Level: mediate heterogeneous Business Processes

77 WSMO Mediators Overview

78 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

79 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

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

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

82 3.3 OWL-S and WSMO Elemente comune si diferente

83 Outline Perspectives Relation of Ontology Elements Interoperability and Mediation Semantic Representation

84 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

85 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

86 OWL-S and WSMO 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 OWL-S profile ≈ WSMO capability + goal + non-functional properties

87 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

88 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

89 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

90 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

91 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

92 OWL vs 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

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

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


Download ppt "Aplicatii Web bazate pe semantica, agenti si servicii Universitatea Politehnica Bucuresti Anul universitar 2008-2009, Master Adina Magda Florea"

Similar presentations


Ads by Google