The Web Service Modelling Ontology - WSMO AIMSA 2004 – 01 Sept. 2004

The Web Service Modelling Ontology - WSMO

AIMSA 2004 – 01 Sept. 2004

Christoph Bussler, Sinuhe Arroyo, Michael Stollberg, Matthew Moran, Michal Zaremba, John Domingue, Liliana Cabral and Jos de Brujin

The Eleventh International Conference on Artificial Intelligence: Methodology, Systems, Applications - Semantic Web Challenges - AIMSA 2004, Varna, Bulgaria, September 2nd-4th, 2004

The Web Service Modelling Ontology - WSMO AIMSA 2004, 01-09-2004, Varna, Bulgaria2

Objectives of Tutorial

• Enable attendees to:– Understand aims & challenges within Semantic Web Services – Understand the main technologies of WSMO – Be able to model Web Services with WSMO – Be able to correctly assess emerging technologies & products

for Semantic Web Services – Use an implemented tool to create SWS

• Give an overview of ‘hot topics’ within the Semantic Web and Semantic Web Services

• Provide a detailed introduction into WSMO:– Design principles & paradigms – Building blocks– Technologies & implementations


Contents

• Part I: Introduction to the Semantic Web and Semantic Web Services

• Part II: Introduction to WSMO------------- break -------------

• Part III: The building blocks of WSMO• Part IV: Choreography and orchestration

------------- lunch -------------• Part V: WSMO languages: WSML• Part VI: The execution environments: WSMX and

IRS-3------------- break -------------

• Part VII: Hands on session


Use Case

• Aim: – Example to be followed throughout the tutorial

to showcase WSMO technology

• Description:– Buy a train ticket to travel from Innsbruck,

Austria to Frankfurt, Germany.

– Depart: 10 September 2004, after 06:00 – Arrival: 10 September 2004, before 18:00


WSMO Tutorial Part I

Introduction to the Semantic Web and Semantic Web Services

Sinuhe Arroyo


Part I Contents

• The Semantic Web– The general vision– Ontologies

• Semantic Web Services– Web Services– The general vision– Semantic Web Services

The Semantic Web The General Vision


The General Vision

Static

– 500 million user more than 3 billion pages

WWWURI, HTML, HTTP

Syntactic


The General Vision

WWWURI, HTML, HTTP

– Serious Problems in • Information finding• Information extracting• Information representing• Information interpreting • Information maintaining

Semantic WebRDF, RDF(S), OWL

Static

Syntactic Semantic


The General Vision

[Butler 2003]


The General Vision

“The Semantic Web is an extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation” [Berners-Lee et al. 2001]


The General Vision

• The Semantic Web:– It is the next generation of the WWW where

information has machine-processable and machine-understandable semantics

– It will bring structure to the meaningful content of Web pages

– It is not a separate Web but an augmentation of the current one, where information is given a well-defined meaning


Ontologies

• Core concept of the Semantic Web that allows the representation of data in a machine processable way

• Ontologies are introduced to provide machine-understandable semantics– “Formal, explicit specification of a shared

conceptualization” [Gruber, 1993]


Ontologies

“Represent formal and consensual

specifications of conceptualizations, which

provide a shared and common

understanding of a domain as data and

information machine-processable semantics,

which can be communicated among agents(organizations, individuals, and software)”

[Fensel, 2001]


Ontologies

• Main components of an ontology– Concepts: Basic elements of the domain tasks,

usually organized in taxonomies and containing attributes

– Instances: Represent specific elements of the concepts.

– Relations: Express relationship between concepts in the domain

– Function: Method that can be invoked on a specific instance of a concept

– Axioms: Model sentences that are always true


Ontologies

• Concept: concept ticket

origin ofType location

destination ofType location

departure ofType timeStamp

arrival ofType timeStamp

fare ofType price

• Instance: instance tInnFra memberOf ticket

origin hasValue innsbruck

destination hasValue frankfurt

departure hasValue 2004-10-10T06:00

arrival hasValue 2004-10-10T18:00

fare hasValue “EUR 100”

• Concept: concept client

name ofType xsd:string

lastName ofType xsd:string

address ofType location

• Instance: instance john memberOf client

name hasValue “John”

lastName hasValue “Domingue”

address hasValue loc1


Ontologies

• Axiom: axiom validDates

definedBy

<- ?x memberOf ticket[arrival hasValue ?y, departure hasValue ?z] and

?y < ?z.

• Relation: relation distance

from ofType location

to ofType location

amount ofType kilometers

• Function: function daysBetween

range ofType xsd:integer

instant1 ofType instant

instant2 ofType instant

definedBy

daysBetween[range

hasValue ?x, instant1 hasValue ?y, instant2

hasValue ?z]

impliedBy subTract(?x, ?y1, ?z1) and julianDayNumber(?y1,?y)

and julianDayNumber(?z1,?z).


Ontologies

• The benefits:– Ontologies define formal semantics for

information allowing information processing by a computer

– Ontologies define a real-world semantics allowing to link machine processable content with meaning for humans based on consensual terminology

– Ontologies facilitate semantic interoperability– So now human and computers can collaborate:

machine processing + human intervention

Semantic Web Services


Web Services

"Semantic differences remain the primary roadblock to smooth application integration, one which Web Services alone won't over-come. Until someone finds a way for applications to understand each other, the effect of Web services technology will be fairly limited. When I pass customer data across [the Web] in a certain format using a Web Services interface, the receiving program has to know what that format is. You have to agree on what the business objects look like. And no one has come up with a feasible way to work that out yet -- not Oracle, and not its competitors..."

Oracle Chairman and CEO Larry Ellison


Web Services

Web Services as a Software Architecture

IBM web service tutorial

“Web services are a new breed of Web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes…Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service.”


Web Services as a Software Architecture

• Web Services connect computers and devices with each other using the Internet to exchange data and combine data in new ways

• The key to Web Services is on-the-fly software creation through the use of loosely coupled, reusable software components

• Software can be delivered and paid for as fluid streams of services as opposed to packaged products

• No risks in terms on investment


New Concept for eWork and eCommerce


Numerous white papers

„Web Services, are Services accessible via the web.“



• Business services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communication devices

• The Internet will become a global common platform where organizations and individuals communicate among each other to carry out various commercial activities and to provide value-added services

• The dynamic enterprise and dynamic value chains become achievable and may be even mandatory for competitive advantage



• Large companies shrink around their core competencies into small, flexible, and highly profitable units

• Vice versa, virtual enterprises are set up on the fly reflecting current needs from the market

• eWork and eCommerce will be the two sides of the same coin


Web Services as Programming Technology

WS as programming technology

Current state of the art



• The web is organized around URIs, HTML, and HTTP

– URIs provide defined ids to refer to elements on the web

– HTML provides a standardized way to describe document structures (allowing browsers to render information for the human reader)

– HTTP defines a protocol to retrieve information from the web.

– Not surprisingly, web services require a similar infrastructure around UDDI, WSDL, and SOAP

URI HTML HTTP

UDDI WSDL SOAP




The General Vision

WWWURI, HTML, HTTP

– Bringing the computer back as a device for computation


Dynamic Web ServicesUDDI, WSDL, SOAP

Static

Syntactic Semantic


The General Vision

WWWURI, HTML, HTTP

– Bringing the web to its full potential


Dynamic Web ServicesUDDI, WSDL, SOAP

Static

Intelligent WebServices

Syntactic Semantic



Semantic Web Services =

Semantic Web Technology +

Web Service Technology



“Self-contained, self-describing, semantically marked-up software resources that can be published, discovered, composed and executed across the Web in a task driven automatic way” [Arroyo et al. 2004]



• SWS Usage Process:• Publication: Make available the description of the

capability of a service • Discovery: Locate different services suitable for a

given task • Selection: Choose the most appropriate services

among the available ones • Composition: Combine services to achieve a goal • Mediation: Solve mismatches (data, protocol,

process) among the combined • Execution: Invoke services following programmatic

conventions



• SWS Usage Process:• Execution Support

– Monitoring: Control the execution process – Compensation: Provide transactional support and undo

or mitigate unwanted effects – Replacement: Facilitate the substitution of services by

equivalent ones – Auditing: Verify that service execution occurred in the

expected way



• Semantic Web Services have the potential to become a key-enabling infrastructure for:– Knowledge Management and eWork– Enterprise Application Integration– eCommerce (B2B and B2C)

• In consequence Semantic Web Services are one of the key areas of applied computer science


WSMO Tutorial Part II

Introduction to the Web Service Modeling Ontology WSMO

Sinuhe Arroyo


Part II Contents

• WSMO and SDK-Cluster

• WSMO– Mission– Features– Design principles

• WSMO Working Group


WSMO

• WSMO is an ontology and a conceptual model for the description Semantic Web Services

• WSMO is derived from and based on the Web Service Modeling Framework WSMF

• WSMO is an SDK-Cluster working group


SDK-Cluster

• SEKT (Semantically-Enabled Knowledge Technologies)http://sekt.semanticweb.org/

• DIP (Data, Information and Process with Semantic Web Services)http://www.nextwebgeneration.org/projects/dip/

• Knowledge Webhttp://knowledgeweb.semanticweb.org/

• SDK – Clusterhttp://www.sdk-cluster.org/


SDK-Cluster

• Mission:– Strengthening European Research and Industry in Semantic

Web and Semantic Web Services

– Working towards international standardization together with US-based DAML program

– Promoting research results to industry and academia through joint dissemination

– Strengthening world-wide research and standardization in Semantic Web and Semantic Web Services field


WSMO Working Group

• Chairs:– Christoph Bussler

– Dieter Fensel

• It is open to: – All members of SEKT, DIP, Knowledge Web, SWWS,

and DERI

– Experts in the field

– If interested in joining, please send e-mail to chairs


WSMO Mission

• Create a Web Service Modelling Ontology (WSMO) for describing various aspects of Semantic Web Services

• We aim to solve the integration problem

• Provide a world-wide standard, developed together with industrial partners and other research groups, that will be aligned with different research projects


WSMO Features

• Features:– Simplicity: A solution to the integration

problem that is as simple as possible

– Completeness: Solve all aspects of the integration problem

– Executability: An execution semantic exists

as well as a reference implementation


WSMO Design Principles

• Decoupling and Mediation: – Decoupling:

• Applications should be as independent as possible• Carry communication by means of public message exchange

protocols – Mediation:

• Scalable communications should allow anybody to speak with everybody

• A mediation approach, which allows to map different business logics is taken

• Interface vs Implementation: Differentiates among the internal implementation and behaviour and the externally visible behaviour


WSMO Design Principles

• Peer-to-peer vs Client/Server: Interaction takes place among equal partners, in terms of their level of control over the other entity

• Execution semantics: Required to uniquely specify the execution behaviour at runtime. WSMO compliant implementations shall have a formal execution semantics to ensure a consistent execution model


Working Groups – General overview

WSMO WG

WSMX WGWSML WG

A Conceptual Model for SWS

A Formal Language for WSMO

A Rule-based Language for SWS

An Execution Environment for WSMO


WSMO Working Group

• Mission: – Develop an ontology for describing

Semantic Web Services– Backbone for the development of:

• Web Service Modelling Language (WSML)• Web Service Modelling Execution

Environment (WSMX)

• Web site:– http://www.wsmo.org/


Web Service Modelling Language

• Mission: – Develop a formal language for describing Semantic Web

Services and provide a rule language for the Semantic Web• Web Service Modelling Language (WSML)

– F-logic based language, for the description of Semantic Web Services based on WSMO

– Five different species: • WSML-Core, OWL-Lite based• WSML-Flight, OWL-Flight based• WSML-Rule, Logic Programming-variant of F-Logic and HiLog• WSML-OWL, WSML syntax + OWL semantics• WSML-Full, a full First-Order Logic

• Web site: – http://www.wsmo.org/wsml/


Web Service Modelling Execution Environment

• Mission: – Develop an architecture for working with Semantic

Web Services• Web Service Modelling Execution Environment

(WSMX).– A reference implementation of an execution environment for

WSMO– Test-bed for WSMO to demonstrate the viability of using

WSMO for dynamic interoperation of Semantic Web Services

• Web site:

– http://www.wsmx.org/


WSMO Tutorial Part III

Building Blocks of WSMO

Michael Stollberg


Part III Contents

• WSMO Top Level Notions• WSMO Design

– Web Compatibility – Non-functional Properties

• Description of WSMO Components – Ontologies – Goals – Web Services– Mediators


Top Level Notions

Provide the formally specified terminologyof the information used by all other components

Semantic description of Web Services: - Capability (functional)- Interfaces (usage)

Objectives that a client may havewhen consulting a Web Service

Connectors between components with mediation facilities for handling heterogeneities


WSMO Types

• WSMO Standard (D2): • Defines the basic notions (minimal aspects)• Unambiguously specifies the description elements for basic notions• Defines a general framework for Semantic Web Services:

– Not development of specific solutions – Open for different technical realizations

• WSMO Full (D12): • Extends WSMO Standard to a fully-fletched SWS-framework • Special attention to B2B perspective • Under construction, current version: 0.1

We present WSMO Standard (D2, v1.0, 16th August 2004)see also handout


Web Compatibility

1. Namespaces Namespaces are defined & used as in XML: - A namespace defines a space of coherent vocabulary (does not import vocabulary) - Referenced by a qualified names (= brief reference by pre-fix)

2. Identifier • As in the Web, every WSMO resource / element is uniquely identified • Applying concept of URI (Uniform Resource Identifier) from WWW• Other Identifiers (everything that is not an URI): Literal, Variable, Anonymous ID

3. Datatypes • Primitive Datatypes according to XML Schema (String, Boolean, Integer, Float) • Basic Operators: = != < > <= >=


Non-Functional Properties

• Every WSMO elements is described by properties that contain relevant, non-functional aspects of the item

• used for management and element overall description

Core Properties: - Consist of the Dublin Core Metadata Element Set

plus version (evolution support)- W3C-recommendations for description type

mandatory: identifier publisher date type version

others are optional, but recommended


Core Properties - Exampleontology <http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/dt.wsml>

nonFunctionalProperties dc:title "Date and Time Ontology" dc:creator "DERI International" dc:subject "Date", "Time", "Date and Time Algebra" dc:description "generic representation of data and time including basic algebra" dc:publisher "DERI International" dc:contributor "Holger Lausen", "Axel Polleres", "Ruben Lara" dc:date 2004-06-28 dc:type http://www.wsmo.org/2004/d2/v0.3/20040329/#ontos dc:format "text/plain" dc:language "en-US" dc:relation <http://www.isi.edu/~pan/damltime/time-entry.owl>, <http://www.w3.org/TR/xmlschema-2/> dc:coverage "World" dc:rights <http://www.deri.org/privacy.html> version 1.21

Identifier(mandatory)

see definition in D2, sect. 2.5.1


WSMO Ontologies






Ontologies

• Ontologies are used as the ‘data model’ throughout WSMO – All data used in WSMO element descriptions rely on ontologies – Semantic information processing & ontology reasoning

• WSMO Ontology Language WSML– Well-defined semantics (standard model theory, minimal model

semantics) – Compact syntax (human readable)

• WSMO Ontology Design – Modularization: import / re-using ontologies, modular

approach for ontology design – De-Coupling: heterogeneity handled by OO Mediators


• Non functional properties (see before)• Imported Ontologies importing existing ontologies

where no heterogeneities arise • Used mediators: OO Mediators (ontology import

with terminology mismatch handling)

• ‘Standard’ Ontology Notions: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

ontologyAxioms axiomatic expressions in ontology (logical statement)

• Logical Expressions: – major element for unambiguous specifications in axioms– Logical Language: WSML

WSMO Standard

Ontology Specification


ontology <http://www.wsmo.org/2004/d3/d3.2/v0.1/20040628/resources/loc.wsml>

namespace ...

non-functional-properties ... import-ontologies comment: none

usedMediators ooMediator <http://www.wsmo.org/.../owlFactbookMediator.wsml> ooMediator <http://www.wsmo.org /.../owlAddressMediator.wsml>

WSMO Standard

Ontology Example neck line from Location Ontology (WSMO D3.2, Listing 4)

WSMO top level component type and Identifier (mandatory)

Ontology Import / OO Mediator Usage

Core Properties

Namespaces


Ontology Example neck line from Location Ontology (WSMO D3.2, Listing 4)

Concept Specification Instance

Specification

Axiom Specification

concept <city> subconceptOf <location> nonFunctionalProperties dc:description “City” state ofType state population ofType Integer extension ofType Integer zipcodes ofType set String

instance <innsbruck> memberOf <city> name hasvalue ‘Innsbruck’ country hasvalue austria

axiom lessThanDistance nonFunctionalProperties dc:description "Computes -less than- for a distance" definedBy "?D1 < ?D2 <- ?D1.kilometers < ?D2.kilometers."


WSMO Goals






Goals• De-coupling of Request and Service

Goal-driven Approach, derived from AI rational agent approach- Requester formulates objective independent / without regard to services

for resolution- ‘Intelligent’ mechanisms detect suitable services for solving the Goal- Allows re-use of Services for different purposed

• Usage of Goals within Semantic Web Services– A Requester, that is an agent (human or machine), defines a Goal to

be resolved – Web Service Discovery detects suitable Web Services for solving the

Goal automatically

• WSMO Goals – Define the objective / desire only, no Input for Service – Goal resolution process is left to WSMO-implementations (can be different

solutions)


Goal Specification• Non functional properties • Imported Ontologies• Used mediators

– OO Mediators: for importing ontologies with integration– GG Mediator:

• Goal definition by reusing an already existing goal• Allows specification of Goal Ontologies

• Post-conditions Describe the state of the information space that is desired.

- The result expected from execution a Web Service- Expressed as an axiom (unambiguous, based on ontology)

• Effects Describe the state of the world that is desired.

- Expected changes in the world that shall hold after a service execution

- Expressed as an axiom (unambiguous, based on ontology)


Goal Specification - Example

neck line from Goal for buying a ticket for a trip (WSMO D3.2, Listing 5)

Goal Postcondition „I want information about an itinerary

for some trip for some passenger“

postcondition axiom buyATicketForItinerary nonFunctionalProperties dc:description “defines the desire expressed in the Goal" definedBy ?someItinerary memberOf tc:itinerary[ ?trip hasValue someTrip memberOf tc:trip, ?passenger hasValue _# memberOf loc:person ].


WSMO Standard

WSMO Web Services






WSMO Standard

WSMO Web Services Description

• Web Service specific non-Functional Properties

• Capability: functional description (WHAT)– Describes constrained input / output, and conditions for service

usage – Each Web Service has 1 Capability

• Interfaces: usage interface & composition (HOW)– 2 operational views:

• Choreography: how to consume the Web Service • Orchestration: realization of Web Service functionality

by aggregation of other Web Services

– A Web Service can have multiple Interfaces


Web Service Specific Properties

• Quality Aspects and other non-functional information of Web Services:

Accuracy RobustnessAvailability ScalabilityFinancial SecurityNetwork-related QoS Transactional Performance Trust Reliability

• Used for service selection (sub-step of Web Service Discovery)

• A lot of related research / techniques that can be incorporated


Web Service Description

• Non functional properties – Core Properties – Web Service specific Properties

• Imported Ontologies • Used mediators

– OO Mediator: importing ontologies as terminology definition

• Capability

• Interfaces – Choreography– Orchestration


webservice <http://www.wsmo.org/2004/d3/d3.2/v0.1/20040719/resources/ws.wsml>

namespace ... nonFunctionalProperties dc:title “ÖBB Online Ticket Booking Web Service” dc:subject pc:traintrip, po:trade dc:type <http://www.wsmo.org/2004/d2/#webservice>

import-ontologies <http://www.wsmo.org/ontologies/trainConnection>, <http://www.wsmo.org/ontologies/purchase>, … used-mediators capability ... interface choreography <http://www.wsmo.org/2004/d3/d3.2/v0.1/20040719/resources/ws-chor.wsml> orchestration <http://www.wsmo.org/2004/d3/d3.2/v0.1/20040719/resources/ws-orch.wsml>

WSMO Standard

Web Service Description – Example neck line from Web Service for buying train tickets (WSMO D3.2, Listing 7)

WSMO element type and Identifier (mandatory)

no Mediators (only imported ontologies)

non-functional properties(only some)

used ontologies (import ALL domain Knowledge needed)

Capability (see following slides) links to Web Service Interface descriptions


WS Capability Specification• Non functional properties • Imported Ontologies • Used mediators

– OO Mediator: importing ontologies as terminology definition – WG Mediator: link to a Goal that is solved by the Web Service

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


WS Capability – Example

neck line from Web Service for buying train tickets (WSMO D3.2, Listing 7)

Precondition (expected Input: Buyer Information and the desired Trip with constraints)

precondition nonFunctionalProperties dc:description "input with constraints, needed: Buyer, Traintrip with constraints" definedBy ?Buyer memberOf po:buyer and ?Trip memberOf tc:trainTrip[ tc:start hasValue ?Start, tc:end hasValue ?End, tc:departure hasValue ?Departure ] and (?Start.locatedIn = austria or ?Start.locatedIn = germany) and (?End.locatedIn = austria or ?End.locatedIn = germany) and ?Departure > currentDate().




Assumption (a valid, i.e. not expired credit card)

assumption nonFunctionalProperties … definedBy ?CreditCard member-of po:creditCard and (currentDate.date.year < ?CreditCard.expirydate.expyearr or (currentDate.date.monthOfYear =< ?CreditCard.expirydate.expmonth and currentDate.date.year = ?CreditCard.expirydate.expyear)).


WSMO Standard



Postcondition (returns a train trip with constraints)

postcondition nonFunctionalProperties dc:description "the output of the service with constraints” definedBy ?outputItinerary member-of tc:itinerary[ ?trip member-of tc:trainTrip[ tc:start hasvalue ?Start, tc:end hasvalue ?End, tc:departure hasvalue ?Departure ] and ?passenger hasValue _# memberOf loc:person and (?Start.locatedIn = austria or ?Start.locatedIn = germany) and (?End.locatedIn = austria or ?End.locatedIn = germany) and ?Departure > currentDate().


WSMO Standard



Effect (a trade (= contract of purchase) is created)

effect nonFunctionalProperties dc:description "a trade for the train trip of the postcondition." definedBy ?someTrade memberOf po:trade[ ?po:items hasValues aTicket[

itinerary hasValue outputitinerary ] and ?po:payment hasValue AcceptedPayment memberOf po:creditCard ].


Web Service InterfacesWeb Service Description

Service User

other Web Services


Interfaces• Non functional properties • Import Ontologies• Used mediators

OO Mediators: importing ontologies as terminology definitions • Choreography

Behavioral Interface for the service requester to consume the Web Service• Orchestration

Describes a service makes use of other web service or goals in order to achieve it's capability.

Choreography and Orchestration are addressed in Part IV of the Tutorial in more detail


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

• Aim:– Realization of mediation technologies for SWS – Principle of De-coupling for handling complexity & heterogeneity

• WSMO Mediators:WSMO components are never allowed to touch each other without a mediator in-between.

• Types of WSMO Mediators:

OO Mediators import ontologies & resolving heterogeneities

GG Mediators connect Goals & resolve mismatches

WG Mediators link Web Service and Goal & resolve mismatches

WW Mediators connect several Web Services for collaboration


WSMO Mediators Overview


WSMO 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


WSMO Mediator Specification

• Non functional properties • Import Ontology • Source components

Entity / entities to be integrated (any WSMO top level component)

• Target component Entity that applies the integrated source components (any WSMO top level

component)

• Mediation Service links to mediation service that resolves mismatches– as a Goal: specifies desired mediation (e.g. mapping

rules) – as a Web Services: uses specific Mediation Web Service directly– as a WW Mediator: links to specific Mediation Service +

heterogeneity handling


WSMO OO Mediators

• Aim:– Data Level Mediation for Semantic Web Services – OO Mediators are used in all other WSMO Mediators for data

level mediation

• OO Mediation Techniques:– Ontology Integration as related research field – Data Lifting & Lowering

• OO Mediator efforts:– Mapping Language for Ontology Integration under development – OO Mediator Architectures under development in different

WSMO-related efforts (WSMX, DIP, SEKT)


WSMO 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


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


WSMO WG Mediators

• Aim:– Link a Web Service to a Goal and resolve occuring mismatches

Broader range of Goals solvable by a Web Service

• Related to Service Discovery & Usage: – Handling of partial matches within Web Service Discovery

– Handle terminology mismatches between Web Services and Goals

– Mediate between requested and provided Input to Web Service


WG Mediator Example

WG MediatorTrain Connec-tion Ontology

Purchase Ontology

Goal “buy a train ticket”

Goal:“aTicket memberof trainticket”

mediate between a Web Service and Goal with a narrower desire

Web Service “sell flight and train tickets”

Mediation Service

usedMediatorimports

Train Ticket Purchase Ontology

imports

OO Mediator(from above)

sources target


WSMO WW Mediators

• Aim:– Enable interoperability of heterogeneous Web Services Support automated collaboration between Web Services

– Related to Web Service Interfaces (not fully specified yet)

• WW Mediators support all 3 Mediation Levels:

– OO Mediators for terminology import with data level mediation

– Protocol Mediation for establishing valid multi-party collaborations

– Process Mediation for making Business Processes interoperable


WSMO Tutorial Part IV

Choreography & Orchestration in WSMO

Michael Stollberg


Part IV Contents

• Choreography and Orchestration: Differences and Interrelation

• Choreography in WSMO: – Objectives, Approach, and Aspects – WSMO Choreography Description Language– WSMO Choreography Abstract Model

• Orchestration in WSMO: – Objectives, Approach, and Aspects– Web Service Composition in WSMO


WSMO Web Services – Recall

Web ServiceImplementation(not of interest in Web Service Description)

Choreography Orchestration

Capability

functional description

WS

WS

- Advertising of Web Service- Support for WS Discovery

Behavior Interface for consuming WS- Messages - External Visible Behavior- ‘Grounding’

Realization of WS functionality by using other Web Services - Functional decomposition - WS Composition


Choreography <-> Orchestration

• Choreography– Specifies the Behavior Interface for Service

Consumption

– A Service User (Client) has to support this for consuming a Web Service

• Orchestration– Specifies how the functionality of a Web Service is

achieved by aggregating other Web Services

– Support for Service Provider to specify Composed Web Services


Example: A Virtual Travel Agency

– A Virtual Travel Agency VTA provides an end-user eTourism services VTA, here for booking international train tickets online

– VTA Service User, i.e. the Customer applies the Choreography of VTA

– VTA functionality is aggregated by composing other Web Services from different Service Providers: TimeTable, Payment, Delivery

• TimeTable : time table service for international train connections

• Payment: online payment service

• Delivery: delivery service

[contracting between VTA and other Service provides not of interest]

Use Case taken from WSMO D3.2 – Use Case and Testing


Example: Use Case Overview

Customer

TimeTable

Payment

Delivery

uses & aggregates

Service Provider

Service Provider

provides

Contract

Contract

how does the interplay of the Customer, VTA, and the other Web Services look like?

VTA


Step1: Goal Definition and Web Service Discovery

Customer

Goal: „I want to buy a train ticket from Innsbruck to Frankfurt on 17th July 2004, departure later than 6 p.m.“

Service Registry

WS Discoverer

creates

searches

VTA result set including


Orchestration

Composition

VTA Web Service Interfaces (simplified)

Choreography

invocation

connection choice

contract of purchase

payment & delivery

request: buyer information, itinerary

set of valid itinerariesitinerary

input not valid

no valid connection

purchase proposition

option selection OR accept OR not accept

payment informationrequest payment information

payment information incorrect

internal

connection choice TimeTable

Payment

Delivery

P

P

successful purchase

payment & delivery


Service Usage I: “Invocation”

CustomerInvocation Message

incl. Input-Information (Buyer, Itinerary)

VTA CI

Choreography Side Orchestration Side


CI

Service Usage II: “Connection Choice”

Customer

VTA

TimeTableP

REQ: valid itineraries

RES: set of itineraries

INF: set of itineraries

INF: itineraries CI

time Choreography Side Orchestration Side


Service Usage III: “Contract of Purchase”

Customer

INF: Purchase Proposition

incl. all purchase contract information

VTA CI

Choreography Side Orchestration Side

INF: Purchase Offer Acceptance

INF: Proposition Option Selection

repeat until acceptance

time


CI

Service Usage IV: “Payment & Delivery”

CustomerVTA

Payment

PREQ: payment

incl. item, creditcard

RES: payment OK

REQ: creditcard info

RES: creditcard info

CI

time Choreography Side Orchestration Side

ERR: creditcard invalidERR: creditcard invalid

Delivery

REQ: delivery

incl. item, ship-address

ACK: delivery OK CI

INF: successful purchase


Choreography <-> Orchestration

Choreography = Behavior Interface for Service Consumption • All Web Service – Client Interaction happens on Choreography Side

• Choreography consists of messages & their order (= process), errors, and communication technology

Orchestration = Aggregating other WS into functionality • Allows re-use of other Web Services to realize a Web Service

functionality

• Proxies: – Placeholders for used Web Services– Deal with the Choreography of used Web Services

• Web Services used to achieve for 1 subtask in the Orchestration can be composed


WSMO Choreography

“Interface of Web Service for client-service interaction when consuming the Web Service”

Aspects:

1) WS Choreography Interface: Behavior Interface of single Web Services– External visible behavior – Communication structure

2) Choreography: multi party collaboration – Multi party interaction protocols – Communication structure

3) Choreography Mediation: establish valid Choreographies – Mediate between heterogeneous Choreography Interfaces of Web

Services that shall collaborate to achieve a common goal – Protocol level + process level mediation


WSMO ChoreographyObjectives & Requirements

description support: • Language for WSMO Choreography Interfaces • Language for WSMO Choreographies • Semantically driven & unambiguous

expressiveness & formal foundation: • Sufficient modeling constructs for behavior • Formal foundation (for mediation support)

other requirements:• Should support / be compatible to “standards” • Should allow modularization & re-use


WSMO Choreography Interfaces

External Visible Behavior– Those aspects of the workflow of a Web Service

where User Interaction is required – Described as a process

Communication Structure – Messages sent and received – Their order (messages are related to activities)

Choreography Interface Errors– Choreography Interface related Errors (e.g. input

wrong, message timeout, etc.)


WSMO Choreography Interface Description Language

choreographyInterface process WorkflowPattern activity name CommunicationPattern message type

direction content failure type action

under construction


WSMO Choreography Interface Formal Model

• Formalization needed to allow operations / mediation on WSMO Choreography Interfaces

• Formal Basis: Abstract State Machines (ASM)– ASM consists of Constants and Transition Rules; all Transition Rules

are executed simultaneously according to conditions – Generic, expressive technology to model behavior – Overcome the ‘Frame Problem’

• Usage: – A general ASM defines the formal semantics of the WSMO

Choreography Interfaces Description Language – CI Specifications are mapped into ASM representation to allow

protocol level mediation operations


Choreography & Mediation

Aim: support collaboration of multiple Web Services

Future Work:• Language and Formal Model for multi-party Choreographies

– Specification of Global Interaction Protocols – related: WS-CDL Web Service Choreography Description Language

(W3C WS Choreography Working Group)

• Protocol and Process Mediation Facilities – formal model for operations on Choreography Interfaces – related: Process Algebra, PI Calculus, Petri Nets

WS2

WS3

WS1

1.2.

4.3.


WSMO Orchestration

“Achieve Web Service Functionality by aggregation of other Web Services”

Aspects:

1) Orchestration Language– decomposition of Web Service Functionality– Control structure for aggregation of Web Services

2) Web Service Composition– Combine Web Services into higher-level functionality – Resolve mismatches occuring between composed Web Services

3) Proxy Technology– Placeholders for used Web Services – Facility for applying the Choreography of used Web Services

under construction


WSMO Orchestration Language

decomposition of the Web Service functionality into sub-functionalities

Proxies as placeholders for used Web Services

Control Structure for aggregation of other Web Services


Web Service Composition

• Aim: compose Web Services into higher-level functionalities

• Requirements: – Detect existing Web Services to be composed – Determine suitable execution order of composed Web Services– Handle mismatches between composed Web Services

• Several Web Service Composition technologies are existing, mainly relying on AI Planning Technologies

• complementary technology to WSMO Orchestration– WSMO Orchestration allocates Web Service Composition in overall

framework & defines requirements for composition technologies – WSMO does not standardize Web Service Composition, but is open to

several composition technologies


WSMO Orchestration Proxy Technology

• Aim: – Placeholder in WSMO Orchestration description – Handles Choreography Interfaces of aggregated Web Services

• Structure: – Specifies the pre & post state of Web Services used in Orchestration – Handle usage of aggregated Web Services

• Invocation • Usage of Choreography Interfaces / Choreography

– Supports usage of composed Web Services

• complementary technology to WSMO Orchestration– WSMO Orchestration defines requirements for Proxy Technology – WSMO does not standardize Proxy Technology, but is open to realizations

that support the requirements


WSMO Tutorial Part V

WSML: The WSMO Language

Jos de Brujin


Part V Contents

• Introduction to WSML• Rationale of WSML• Syntaxes for WSML• WSML Variants

– WSML-Core– WSML-Flight– WSML-OWL– WSML-Full

• Conclusions


Web Service Modeling Language

• Four elements of WSMO:– Ontologies– Goals– Web Services– Mediators

• WSML provides a formal grounding for the conceptual elements of WSMO, based on:– Description Logics– Rule Languages– First-Order Logic


Rationale of WSML

• Provide a Web Service Modeling Language based on the WSMO conceptual model– Concrete syntax– Semantics

• Provide a Rule Language for the Semantic Web• Many current Semantic Web languages have

– Undesirable computational properties– Unintuitive conceptual modeling features– Inappropriate language layering

• RDFS/OWL• OWL Lite/DL/Full• OWL/SWRL


Syntaxes for WSML• Human-readable syntax

– Part of WSMO-Standard• WSMO-Standard defines intuitive semantics

– Modular syntax• WSMO-syntax functions as “umbrella”• Modules for different WSML variants

– Syntax:• Inspired by OIL/OWL and F-Logic• Conceptual syntax• Logical Expression Syntax

– Semantics is fixed in WSML variants• XML syntax

– Based on human-readable syntax• OWL/RDF syntax

– Based on human-readable syntax


Variants of WSML


Variants of WSML (contd.)

• WSML-Core– Based on the intersection of Description Logics and

Datalog– Semantics defined through OWL Lite-

– Has (frame-based) conceptual syntax and logical expression syntax

• WSML-Flight– Based on OWL Flight

• Basic meta-class facility• Constraints• Non-monotonic features (default negation)

– “Fixes” some of the mistakes in OWL, such as unintuitive modeling constructs

– Preferred ontology modeling language


Variants of WSML (contd.)

• WSML-Rule– Based on Logic Programming with default negation

and F-Logic/HiLog syntactical extensions– Preferred goal/web service modeling language

• WSML-OWL– Based on species of OWL

• WSML-Full– Combining FOL with minimal models and non-

monotonicity


WSML Conceptual Syntax for Ontologies

• Ontologies• Namespaces• Imported Ontologies• Used Mediators

• Concepts• Relations• Functions

– Special kind of relation• Instances

– Explicitly defined in ontology– Retrieved from external instance store

• Axioms

Extra-Logical declarations

Logical Declarations

No

n-F

un

ctio

nal

Pro

per

ties


WSML Logical Expressions

• Frame- and first-order-based concrete syntax (BNF Grammar in D2, Appendix B)

• Elements:– Function symbols (e.g. f())– Molecules (e.g. Human subClassOf Animal, John memberOf Human,

John[name hasValue ‘John Smith’]).– Predicates (e.g. distance(to:?x, from:?y, distance:?z))– Logical connectives (or, and, not, <-, <->, ->, forall, exists)

• Example:?x memberOf Human <-> ?x memberOf Animal and ?x memberOf

LegalAgent.


WSML Goals and Web Services

• Goal / Web Service assumptions/effects and pre/post-conditions are defined through WSML logical expressions

• Logical expressions rely on ontologies


WSML-Core

• Allows conceptual modeling of ontologies• Based on OWL Lite- (a subset of OWL Lite, for which a

translation exists to Datalog)– Efficient query answering– Allows to take advantage from optimization techniques

developed in database research– Many existing implementations (e.g. XSB, OntoBroker, SWI-

Prolog, KAON, DLV)– Import/export OWL ontologies

• Expressive enough for most current ontologies• Can be used for limited goal/web service modeling• Unintuitive semantics for attribute descriptions


concept ticket origin ofType location destination ofType location departure ofType timeStamp arrival ofType timeStamp fare ofType price definedBy ?x memberOf ticket impliedBy ?x[origin hasValues ?y, destination hasValues ?z, fare hasValues ?y].

Logical Expression Syntax

Conceptual Syntax

WSML-Core - Example


WSML-Core - Syntax

• Conceptual syntax is slight restriction of WSML (e.g. only binary relations allowed)– Small extensions to cover epistemology of

OWL Lite- (e.g. transitive, symmetric, inverse properties)

• Logical expression syntax is big restriction of WSML– Only patterns that can be translates to OWL

Lite-


WSML-Core - Semantics

• Defined through a translation to OWL Lite- Abstract Syntax

• OWL Abstract Syntax & Semantics document provides direct model-theoretic semantics

• WSML-Core semantics falls in intersection Description Logics and Datalog


WSML-Flight

• Based on OWL Flight– Extends OWL Full- (Datalog subset of OWL Full)– Adds UNA– Adds constraints– Adds non-monotonic features

• Is an extension of WSML-Core– Adds limited support for nominals– Meta-modeling– Intuitive semantics for attributes– Extensive datatype support, based on datatype groups [Pan &

Horrocks, 2004]

• Limited support for Goal and Web Service descriptions


concept ticket origin ofType location destination ofType location departure ofType xsd:dateTime arrival ofType xsd:dateTime fare ofType price axiom validDates definedBy <- ?x memberOf ticket[arrival hasValue ?y, departure hasValue ?z] and ?y < ?z.

Logical Expression Syntax

Conceptual Syntax

WSML-Flight - Example


WSML-Rule

• Based on Logic Programming-variant of F-Logic and HiLog

• Minimal model semantics

• Implements default negation

• Allows unrestricted use of function symbols

• Full support for goal/web service modeling


effect ticket definedBy (itinerary(?Req)[from hasValue ?From, to hasValue ?To] impliedBy ?Input = search(?Req, ?From memberOf (france or germany), ?To memberOf austria)) and (ticket(?Req)[confirmation hasValue ?Num, from hasValue ?From, to hasValue ?To, date hasValue ?Date] impliedBy ?Input = contract(?Req,?From,?To,?Date,_CCard) and generateConfNumber(?Num)). Logical Expression Syntax

WSML-Rule - Example


WSML-OWL

• WSML syntax – OWL semantics• Three species:

– Lite– DL– (restricted subset of) Full

• (to be developed)• OWL epistemology:

– Complete class definitions– Range/cardinality restrictions


Conceptual Syntax

WSML-OWL - Example

completeConcept ticket origin ofType (all,some) location destination ofType (all,some) location departure ofType (some) xsd:dateTime arrival ofType xsd:dateTime fare ofType (some, <=1) price relation origin subRelationOf hasLocation functional relation destination subRelationOf hasLocation functional


WSML-Full

• Based on a combination of First-Order Logic and minimal model semantics and default negation

• Unifies rule language with first-order based language (e.g. OWL)

• For now only theoretical language


WSML Summary

• Formal languages for WSML• Variants:

– WSML-Core– WSML-Flight– WSML-Rule– (WSML-OWL)– (WSML-Full)

• Modular, Frame-based• Conceptual syntax vs. Logical Expressions• Syntaxes:

– Human readable– XML– OWL/RDF


WSMO Tutorial Part VI

The Execution Environment WSMX

Matthew Moran, Michal Zaremba, John Domingue

and Liliana Cabral


WSMO Tutorial

WSMX Web Services Modeling Execution Environment


Agenda

• Overview of WSMX• Review of use case• WSMX walk-through• Conceptual model• Execution semantics• Executing SWS with WSMX• Data mediation• Architecture• Implementation• What next – how to get involved


WSMX Overview

• Execution environment for Semantic Web Services• A reference implementation for WSMO• Service oriented and event-based architecture• Decouples service providers and requesters• Dynamic discovery based on Goal-Capability matching• Mediation

– Data– Process– Protocol


Review Tutorial Use Case

• Goal: – Buy a train ticket to travel from Innsbruck, Austria to

Frankfurt, Germany.– Depart: 10 September 2004, after 06:00 – Arrival: 10 September 2004, before 18:00

• Steps:– Find Web Services with capability for selling train

tickets– Select best web service having this capability– Mediate the Goal (Requester Details) to Provider

format– Invoke the Web Service to buy the ticket


Control

Data

WSMX Walk Through

MediatorListener


Control

Data

Requester Details - XML

WSMX Walk Through

MediatorListener


Control

Data

WSML Message[Goal: Postconditions Effects Inputs]

WSMX Walk Through

MediatorListener


Control

Data

WSMLMessage

WSMX Walk Through

MediatorListener


Control

Data

WSMLMessage

MsgID Payload State

99 <xml> NEW

WSMX Walk Through

MediatorListener


Control

Data

MessageUUID

WSMX Walk Through

MediatorListener


Control

Data

MessageUUID

WSMX Walk Through

MediatorListener


Control

Data

WSMX Walk Through

MediatorListener


Control

Data

MediatorListener

WSMX Walk Through


NewMessage ID

Control

Data

MediatorListener

WSMX Walk Through


NewEvent

EventID Type State MsgID

1 WSML Msg CREATED 99

Control

Data

MediatorListener

WSMX Walk Through


NewEvent


1 WSML Msg CREATED 99

Control

Data

EventID State Component

1 UNLOCKED NONE

MediatorListener

WSMX Walk Through


Control

Data

EventEvent

MediatorListener

WSMX Walk Through


Control

Data

Event

MediatorListener

WSMX Walk Through


Control

Data

Event forWSML Message

MediatorListener

WSMX Walk Through


WSMX V1 ArchitectureControl

Data


1 WSML Msg BeforeParse 99

EventID State Component

1 LOCKED PARSER

MediatorListener


Control

Data

MessageID

MediatorListener

WSMX Walk Through


Control

Data

WSMLMessage

MediatorListener

WSMX Walk Through


Control

Data

ParsedMessage

MediatorListener

WSMX Walk Through


Control

Data


1 WSML Msg AfterParse 99

MediatorListener

WSMX Walk Through


Control

Data


1 WSML Msg AfterParse 99

2 NON_MEDIATED_OBJECT CREATED 99

MediatorListener

WSMX Walk Through


Control

Data


1 WSML Msg CONSUMED 99

2 NON_MEDIATED_OBJECT CREATED 99

MediatorListener

WSMX Walk Through


Control

Data

Event forParsed Message

MediatorListener

WSMX Walk Through


Control

Data



2 NON_MEDIATED_OBJECT BEFORE_MATCHMAKING 99

MediatorListener

WSMX Walk Through


Control

Data

WSMX Goalfrom MessageID

MediatorListener

WSMX Walk Through


Control

Data

WSMXGoal

MediatorListener

WSMX Walk Through


Control

Data

AllWebServices

MediatorListener

WSMX Walk Through


Control

Data

MatchingWebServices

MediatorListener

WSMX Walk Through


Control

Data

MatchingWebServices

MediatorListener

WSMX Walk Through


Control

Data



2 NON_MEDIATED_OBJECT AFTER_MATCHMAKING 99

MediatorListener

WSMX Walk Through


Control

Data

Event forSelector

MediatorListener

WSMX Walk Through


Control

Data

MediatorListener



2 NON_MEDIATED_OBJECT BEFORE_SELECTION 99

WSMX Walk Through


Control

Data

MediatorListener

Web Servicesmatching Goal

and Preferencesfor Goal

(via MessageID)

WSMX Walk Through


Control

Data

MediatorListener

Web Services&

Preferences

WSMX Walk Through


Control

Data

MediatorListener

SelectedWebService

WSMX Walk Through


Control

Data

MediatorListener

SelectedWebService

WSMX Walk Through


Control

Data

MediatorListener



2 NON_MEDIATED_OBJECT AFTER_SELECTION 99

WSMX Walk Through


Control

Data

Event forMediator

MediatorListener

WSMX Walk Through


Control

Data

MediatorListener



2 NON_MEDIATED_OBJECT BEFORE_MEDIATION 99

WSMX Walk Through


Control

Data

MediatorListener

Goal

SelectedWeb Service

WSMX Walk Through


Control

Data

MediatorListener

Goal-OntologyID,WS-OntologyID,

Goal-Payload

WSMX Walk Through


Control

Data

MediatorListener

Mapping rulesbased on goal & WS ontologies

WSMX Walk Through


Control

Data

MediatorListener

Mapping rules& Data to be

Mediated

WSMX Walk Through


Control

Data

MediatorListener

Mediated Datain Flora Syntax

WSMX Walk Through


Control

Data

MediatorListener

Mediated Datain Flora Syntax

WSMX Walk Through


Control

Data

MediatorListener

Mediated Datain XML Syntax

WSMX Walk Through


Control

Data

MediatorListener


WSMX Walk Through


Control

Data

MediatorListener


WSMX Walk Through


Control

Data

MediatorListener



2 NON_MEDIATED_OBJECT CONSUMED 99

3 MEDIATED_OBJECT CREATED 99

WSMX Walk Through


Control

Data

MediatorListener

Event forInvocation

WSMX Walk Through


Control

Data

MediatorListener




3 MEDIATED_OBJECT BEFORE_INVOCATION 99

WSMX Walk Through


Control

Data

MediatorListener

Mediated Data(via MessageID)

Selected WS(via MessageID)

WSMX Walk Through


Control

Data

MediatorListener

Selected WS& Mediated Data

WSMX Walk Through


Control

Data

MediatorListener

Mediated Datain WS Invocation

WSMX Walk Through


Control

Data

MediatorListener




3 MEDIATED_OBJECT AFTER_INVOCATION 99

WSMX Walk Through


Control

Data

MediatorListener




3 MEDIATED_OBJECT CONSUMED 99

WSMX Walk Through


Walk Through Summary

• Event based and service oriented

• WSML as external data representation

• Self contained components with well defined interfaces

• Integration of logical reasoning engine

• End to end– Accept requester goal invoke provider

service

</ WSMX Walk Through >


Conceptual Model – WSMX-O


Execution Semantics

• What is it?– Description of the operation of a system using a formal language

• What are the benefits?– Precise system description based on a formal mathematical

language– Can run simulations to test for potential problems

• Live-lock • Dead-lock or • Unreachable states in the system

• Petri-Nets– Petri Nets have a formal semantics– Allow simulations – test for deadlocks etc.– Other metodologies – Abstract State Machines, UML …


Execution Semantics

• Example: PetriNet for Mediation in WSMX


WSMX Use Case

• Goal: – Buy a train ticket to travel from Innsbruck, Austria to Frankfurt,

Germany.

– Depart: 10 September 2004, after 06:00 – Arrival: 10 September 2004, before 18:00

• Steps:– Find Web Services with capability for selling train tickets– Select best web service having this capability– Mediate the Goal (Requester Details) to Provider format– Invoke the Web Service by sending PO to the Provider


Executing SW Services

Challenges:• Web service discovery• Service selection• Mediation• Executing SWS

– Simple: Single web service– Complex: Composing web services

• Choreography (to come)• Orchestration (to come)


SWS Execution (simple)

DeutsheBahn

Travel Agent

www.Last-Minute.com

goal:buy_trainticket capability: sell_trainticket

WS

invocationengine

?

you need matching on choreography, capability, etc…

you need selection onprice, reliability, etc…

capability: sell_public_transport


SWS Execution (complex)

Airline

TrainOperator

goal:book_holiday

WS

invocationengine Tour

Operator

Hotel

capability:

sell_flight

capability:sell_train_ticket

capability:provide_accomodation

goal:book_flight

goal:book_hotelgoal:book_train

now you also need decomposition

and what to do when something goes wrong?

capability:provide_hotel_booking


Data Mediation

• Ontology to ontology mediation• A set of mapping rules are provided and then

executed• Initially rules defined manually, later semi-

automatic• Create for each source instance the target

instance(s)


Simple Data Mediation

• Address1– Street and number

• Street• Number

– Locality– Country– ZIP

• Axioms:zip_number[value => integer]

local[str => street, number => integer]

address1[str_no => local, loc => locality,

country => country, zip => zip_number]

• Address0– Street– Number– Locality– State, province or county– Country– ZIP Code

• Axioms:zip_code[value => string].

address0[str => street, no => positive_int,

loc => locality, county => county,

country => country, zip => zip_code].

Ontology1, Address1 < -- > Ontology0, Address0


Overview on WSMX Mediation

Execution Environment

(WSMX)

Business Partner

Information Systemcommunicate

Mediator Component

Ontology 1

uses

has source

Ontology 2

has target

uses


Overview on WSMX Mediation

Data Base

Mapping Rules Creator

Rules Execution Environment

MappingsMappings

Mapping Rules

Source Instance

Target Instance

Source Ontology

Target Ontology


Current WSMX Architecture


Implementation

• Event based service oriented architecture• Current status

– Code base established – available at SourceForge– Data mediation component implemented– Other component interfaces defined and partially

implemented

• Main technologies used– Apache Tomcat and Apache Axis– Database – mySQL – Eclipse IDE and Ant as build tool


WSMX Summary

• WSMX is a reference implementation for WSMO – http://www.wsmx.org

• Conceptual Model is WSMX-O• Has a defined execution semantics• Will provide the functionality of B2B & EAI

application integration server• Has an event driven service oriented

architecture• Developers welcome – code at SourceForge


WSMX Next Steps

• Choreography and orchestration

• Business process execution

• Web service composition

• Process and protocol mediation

• Suggestions and participation always welcome


IRS-3: A framework and platform for building semantic web services


The Internet Reasoning Service is an infrastructure for publishing, locating, executing and composing semantic web services, organized according to the WSMO framework


Design Principles

• Compatible with WSMO

• Tight integration

• Open

• Inspectable

• Backward compatible

• OWL-S import

• Research platform for semantic web services


Features of IRS-3 (1/2)

• Based on Soap messaging standard

• Provides Java API for client applications

• Provides built-in brokering and service discovery support

• Provides capability-centred service invocation


Features of IRS-3 (2/2)• Publishing support for variety of platforms

– Java, Lisp, Web Applications, Java Web Services

• Enables publication of ‘standard code’ – Provides clever wrappers automatically, which turn code

into web services– One-click publishing of web services

• Integrated with standard Web Services world– Published code appears as

• Semantic web service to IRS• ‘Ordinary’ web service to web service world


IRS-3 Server

Domain Models

Web Service Specifications+ Registry of Implementors

Goal Specifications+ SOAP Binding

IRS Publisher

S O

A P

IRS Client

SOAP

IRS Publisher

IRS Publisher

IRS Publisher

Lisp

Java

Java WS

IRS-3 Framework


LispWeb Server

IRS-III Architecture

IRS-III Server

WS Publisher Registry

OCML

WSMO Library

OWL(-S) HandlerOWL(-S)

Browser

Invocation Client

Publishing Clients

SOAP Handler

SOAP

Publishing Platforms

Web Service

Java Code

Web Application

SOAPBrowserHandler

PublisherHandler

InvocationHandler

Java

API

WSMX


Publishing Platform Architecture

IRS-III Publishing PlatformHTTP Server

SOAP Handler

ServiceRegistrar

ServiceInvoker

WS Service Registry

IRS-III Server

Invocation Client

SOAP

SOAP

Publishing Clients

SOAP

Web Service 1Web Service 2

Web Service 3


IRS-III/WSMO differences

• Underlying language OCML

• Goals have inputs and outputs

• IRS-III broker finds applicable web services via mediators

– Used mediator within WS capability

– Mediator source = goal

• Web services have inputs and outputs ‘inherited’ from goal descriptions

• Web service selected via assumption (in capability)


IRS-III Demo


European Currency Assumption

(kappa (?goal) (or (= (wsmo-role-value ?goal 'has_source_currency) pound) (= (wsmo-role-value ?goal 'has_source_currency) euro)))


Valid Relations

• Classes are unary relations – e.g. (currency ?x)

• Slots are binary relations – e.g. (is-capital-of ?x ?y)

• Standard relations in base (OCML toplevel) ontology

=, ==, <, >, member


WSMO Tutorial Part VII

Hands-On Session

Matthew Moran, Michal Zaremba, John Domingue

and Liliana Cabral


Tutorial Setup

IRS Server (3000)

Domain Models

Web Service Specifications+ Registry of Implementors

Goal Specifications+ SOAP Binding

Travel Services

(3001)

IRS Client

IRS Web Service Publisher

IRS Knowledge Model Browser & Editor

WSMX


European Travel Scenario


European Travel Demo


Travel Related Knowledge Models


Key Classes and Relations

Is-in-country <city> <country> e.g.

(is-in-country berlin germany) -> true


IRS-III Hands On Task

• Create goal, get service and mediator descriptions in IRS-3 (european-travel-service-descriptions) to support a person booking a train ticket between 2 european cities at a specific time and date

• Your descriptions should choose a specific service depending on the start and end locations and the type of traveller. Use the assumption slot to do this

• Publish available lisp functions against your descriptions

• Invoke the web services


Available (Lisp) Services

• Multiply service

• European timetable service

• Train booking services– Germany, France, England, Austria– Student– Business

• Universal time mediator


Available Functions (1/3)get-train-times paris london (18 4 2004)"Timetable of trains from PARIS to LONDON on 18, 4, 2004 5:18…23:36"

book-english-train-journey christoph milton-keynes london (20 33 25 15 9 2004)"British Rail: CHRISTOPH is booked on the 476 going from MILTON-KEYNES to

LONDON at NIL:NIL, 15, SEPTEMBER 2004.The price is 179 Euros."

book-french-train-journey sinuhe paris lyon (3 4 6 18 8 2004)"SNCF: SINUHE is booked on the 593 going from PARIS to LYON at 6:12, 18,

AUGUST 2004.The price is 25 Euros."


Available Functions (2/3)

book-german-train-journey christoph berlin frankfurt 3305020023"German Rail (Die Bahn): CHRISTOPH is booked on the 362 going from

BERLIN to FRANKFURT at 14:47, 24, SEPTEMBER 2004.The price is 35 Euros."

book-austrian-train-journey sinuhe vienna innsbruck 3304686609"Austrian Rail (OBB): SINUHE is booked on the 681 going from VIENNA to

INNSBRUCK at 17:43, 20, SEPTEMBER 2004.The price is 36 Euros."

multiply 100 7700


Available Functions (3/3)

book-student-european-train-journey john london nice (3 4 6 18 8 2004)"European Student Rail Travel: JOHN is booked on the 408 going from

LONDON to NICE at 6:44, 18, AUGUST 2004.The price is 86 Euros."

book-business-european-train-journey liliana paris innsbruck (3 4 6 18 8 2004)"Business Europe: LILIANA is booked on the 461 going from PARIS to

INNSBRUCK at 6:12, 18, AUGUST 2004.The price is 325 Euros.“

mediate-time (christoph berlin frankfurt innsbruck (9 30 17 20 9 2004))(CHRISTOPH BERLIN FRANKFURT INNSBRUCK 3304686609)


Tips

• Order matters for input roles– Input roles in goal must match order of arguments to function

• Need to specify both input roles and output role• Be careful with soap binding

– sexpr as default– String for one line output – Use xml for multiple line output

• Input roles ‘inherited’ for web services • Slots names can not be the same as class names• Goal <-> web service linking mediator in the capability

used mediators


WSMX Example

buy-english-train-journey

buyTicket (christoph milton-keynes london

15/9/2004)


References

• [Arroyo et al. 2004] Arroyo, S., Lara, R., Gomez, J. M., Berka, D., Ding, Y. and Fensel, D: "Semantic Aspects of Web Services" in Practical Handbook of Internet Computing. Munindar P. Singh, editor. Chapman Hall and CRC Press, Baton Rouge. 2004.

• [Berners-Lee et al. 2001] Tim Berners-Lee, James Hendler, and Ora Lassila, “The Semantic Web”. Scientific American, 284(5):34-43, 2001.

• [Chen et al., 1993] Chen, W., Kifer, M., and Warren, D. S. (1993). HILOG: A foundation for higher-order logic programming. Journal of Logic Programming, 15(3):187-230.

• [Fensel, 2001] Dieter Fensel, “Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce”, Springer-Verlag, Berlin, 2001.

• [Gruber, 1993] Thomas R. Gruber, “A Translation Approach to Portable Ontology Specifications”, Knowledge Acquisition, 5:199-220, 1993.

• [Grosof et al., 2003] Grosof, B. N., Horrocks, I., Volz, R., and Decker, S. (2003). Description logic programs: Combining logic programs with description logic. In Proc. Intl. Conf. on the World Wide Web (WWW-2003), Budapest, Hungary.


References

• [Kifer et al., 1995] Kifer, M., Lausen, G., and Wu, J. (1995). Logical foundations of object-oriented and frame-based languages. JACM, 42(4):741-843.

• [Pan and Horrocks, 2004] Pan, J. Z. and Horrocks, I. (2004). OWL-E: Extending OWL with expressive datatype expressions. IMG Technical Report IMG/2004/KR-SW-01/v1.0, Victoria University of Manchester. Available from http://dl-web.man.ac.uk/Doc/IMGTR-OWL-E.pdf.

• OWL-- - http://www.wsmo.org/2004/d20/d20.1/• OWL Flight – http://www.wsmo.org/2004/d20/d20.3/• [Volz, 2004] Volz, R. (2004). Web Ontology Reasoning with Logic

Databases. PhD thesis, AIFB, Karlsruhe.• WSML-Core – http://www.wsmo.org/2004/d16/d16.7/• [WSMO Standard] Roman, D.; Lausen, H.; Keller, U. (eds.): Web

Service Modeling Ontology - Standard (WSMO - Standard) v 1.0, WSMO Working Draft D2, 16 August 2004.


References

• [WSMO Choreography] Roman, D.; Stollberg, M.; Vasiliu, L.; Bussler, C.:(eds.): Choreography in WSMO, WSMO Working Draft D14, 17 August 2004.

• [WSMO Orchestration] Roman, D.; Vasiliu, L.; Bussler, C.: (eds.): Orchestration in WSMO, WSMO Working Draft D15, 29 May 2004.

• [WSMO Use Case] Stollberg, M.; Lausen, H.; Polleres, A.; Lara, R. (ed.): WSMO Use Case Modeling and Testing, WSMO Working Draft D3.2, 19 July 2004.


Acknowledgement

The work is funded by the European Commission under the projects DIP, Knowledge Web, SEKT, SWWS, AKT and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate program.

We would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this tutorial.


Wrap-up

• Enabled to:– understand aims & challenges within Semantic Web Services – understand the main technologies of WSMO – be able to model Web Services with WSMO – be able to correctly assess emerging technologies & products for

Semantic Web Services – Use and implemented tool to create SWS

• Given an overview of ‘hot topics’ within the Semantic Web and Semantic Web Services

• Provided a detailed introduction into WSMO:– design principles & paradigms – building blocks of WSMO – technologies & WSMO implementations

</ WSMO Tutorial >

Documents

The Web Service Modelling Ontology - WSMO AIMSA 2004 – 01 Sept. 2004