1. Aplicatii Web bazate pe semantica, agenti si servicii
Universitatea Politehnica Bucuresti Anul universitar , Master Adina Magda Florea

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

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

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

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

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

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
Arhitectura
Matchmaker
Register
Decomposer
Reasoner
Invoker

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 WSMO – Europa OWL-S – USA
WSMO – Europa
European Semantic Systems Initiative
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 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

22. Upper Ontology for Services
OWL-S Upper Ontology
Upper Ontology for Services
Service.owl
Profile.owl
Process.owl
Grounding.owl

23. Service Profiles Service Profile Prezentat de serviciu Reprezinta
ce ofera serviciul
Doua utilizari principale:
Reclama capabilitatilor serviciului
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

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

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

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

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

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

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

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

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

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

50. Exemple Diverse exemple de servicii atomice si compuse in OWL-S

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

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

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

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

60. 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)

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

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

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
Flight
When the service is
requested
When the service
requests

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

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

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

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

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

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

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

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

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

77. WSMO Mediators Overview

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

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

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

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

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

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

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

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

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