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

Aplicatii Web bazate pe semantica, agenti si servicii

Universitatea Politehnica BucurestiAnul universitar 2008-2009, MasterAdina Magda Florea

http://turing.cs.pub.ro/webs_078

Servicii Web Servicii Web SemanticeSemantice

Web Semantic si Servicii Web Semantice

Infrastructura SWS Ontologii pentru SWS: OWL-S si WSMO

Standarde pentru servicii Web

BPEL4WSOWL-S Service

Model

ebXMLCPA

Process and workfloworchestrations

QoS: Servicedescriptions and bindings

Contracts andagreements

XLANG

WSCL

WSDLebXML

CPP

ebXMLBPSS

XML, DTD, and XML Schema

HTTP, FTP, SMTP, SIP, etc.

SOAPebXML

messaging

OWL

UDDIebXML

Registries

WSCLWSCI

WS-Coordination

WS-AtomicTransaction and WS-BusinessActivity

OWL-S ServiceGrounding

OWL-S ServiceProfile

BTP

BPML

Discovery

Messaging

Transport

QoS: Conversations

QoS: Choreography

QoS: Transactions

Encoding

WS-Policy

WS-Security

WS-ReliableMessaging

PSL

RDF

Sematic Web Services

WWWURI, HTML, HTTP

Probleme legate de: regasirea informatiei, extragerea informatiei, reprezentarea

informatiei, interpretarea

informatiei actualizarea informatiei

Semantic WebRDF, RDF(S), OWL

Static

1. Evolutie

WWWURI, HTML, HTTP


Dinamic Web ServicesUDDI, WSDL, SOAP

Static

Evolutie

WWWURI, HTML, HTTP

Intregul potential al web-ului


Dynamic Web ServicesUDDI, WSDL, SOAP

Static

Semantic WebServices

Evolutie

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

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, compuneresi executie a WS

2. Infrastructura SWS

Activitati/utilizare

Arhitectura

Ontologia serviciului

Publication Discovery Selection

Composition

Mediation

Execution

Register Decomposer Reasoner Invoker

Matchmaker

Post-conditioninput output

Pre-condition Cost Atomic service

Composite service

Suport executie• Monitoring• Compensation• Replacement• Auditing

Nivel Business

Nivel fizic

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

Register Decomposer Reasoner Invoker

MatchmakerArhitectura

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

OWL-S – USA http://www.w3.org/Submission/OWL-S/

WSMO – EuropaEuropean Semantic Systems Initiativehttp://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.

http://www.w3.org/Submission/OWL-S/

http://www.essi-cluster.org/about-essi/essi-home/

3.1 OWL-S

Upper Ontology

Service Profile

Process Model

Service Grounding

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

OWL-S Upper Ontology

Upper Ontology for Serviceshttp://www.daml.org/services/owl-s/1.0/

Service.owl Profile.owl Process.owl Grounding.owl

http://www.daml.org/services/owl-s/1.0/

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

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 ProfileCapabilitati 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 ProfileProprietati 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 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<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> <expr:SWRL-Condition> loggedIn(AccName,Password) </expr:SWRL-Condition> </process:hasEffect>

</process:Result> </process:hasResult></process:AtomicProcess>

Inputs / Outputs

Result

Condition

Effect

OutputConstraints

Precondition

Ontologia proceselor

Process

Atomic

Simple

CompositeOfera abstractizare, incapsulare etc.

Defineste workflowal unui proces compus

Poate fi invocatprin grounding

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 definesc1. Fluxul de control

Specifica relatiile temporale intre executia diverselor sub-procese

2. Fluxul de dateSpecifica modul in care datele produse de un proces sunt transferate unui alt proces

Exemplu de proces compus

SequenceBookFlight

DepartArrive

FlightsAirline

Airline Flight

Perform

Get FlightsFlight

Perform

Select Flight

Flights

Legaturi flux de controlSpecifica ordinea executiei

Legaturi flux de dateSpecifica transferul de

date

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

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

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

SequenceBookFlight

DepartArrive

FlightsAirline

Airline Flight

Perform

Get FlightsFlight

Perform

Select Flight

Flights

Get Flights OpDepartArrive

Flights

WSDL

AirlineFlight

Select Flight op

Flights

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

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

A Rule-based Language for SWS

Execution Environment for WSMO

Web Compliance Ontology-Based Strict Decoupling Centrality of Mediation Ontological Role Separation Description versus

Implementation Execution Semantics

WSMO Design Principles

WSMO Top Level Notions

Objectives that a client wants toachieve by using Web Services

Provide the formally specified terminologyof 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 ListDublin Core Metadata

Contributor Coverage Creator Description Format Identifier Language Publisher Relation Rights Source Subject Title Type

Quality of Service Accuracy NetworkRelatedQoSPerformanceReliability RobustnessScalability Security Transactional Trust

Other Financial Owner TypeOfMatch Version

WSMO Ontologies





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

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 conceptRelations define interrelations between several conceptsFunctions 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 Service Description

Web ServiceImplementation(not of interest in Web Service Description)

Choreography --- Service Interfaces ---

Capability

functional description

WS

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

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

VTAService

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

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

- decomposition of service functionality

- all service interaction via choreographies

Control Structure for aggregation of other Web Services

WS

Web S

ervice Business Logic

1

2

3

4

WS

State in Orchestration

Control Flow

Data Flow

Service Interaction

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

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

Ω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

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

WSMO 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

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





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

WSMO Mediators Overview

Mediator Structure

WSMO Mediator

uses a Mediation Service via

Source Component

Source Component

TargetComponent 1 .. n

1

Mediation Services

- as a Goal - directly- optionally incl. Mediation

OO Mediator - Example

OO MediatorMediation Service

Train ConnectionOntology (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

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

Source Goal“Buy a ticket”

Target Goal “Buy a Train Ticket”

postcondition: “aTicket memberof trainticket”

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

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

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

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

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

Top Related