European Integrated Project John Domingue and Barry Norton, The Open University Frank Leymann,...

European Integrated Project

John Domingue and Barry Norton, The Open University Frank Leymann, University Of Stuttgart

Semantic Web Services

Motivation

SUPER is an ambitious project “Boil the Ocean”

Effort required for a common vision/vocabulary 50-60 researchers Heterogeneous groups

Super has a sophisticated conceptual foundation Semantic Web Services

WSMO/WSML/WSMXDIP Project

Business Process Management BPEL

Semantic Web Overview Web Services Overview (Frank) Semantic Web Services: Problem and Vision Background projects Web Services Modelling Ontology (WSMO) Web Services Modelling Language (WSML) Web Services Execution Environment (WSMX) Overview of IRS-III WSMO Studio Hands on Session Summary

Contents


The Semantic Web in a Nutshell

Need for Semantics

Combining Heterogeneous Data Sources

Machine Readable Web Pages

CV

name

education

work

private

< >

< >

< >

< >

< >

< >

< >

<>

<>

<>

...

Machine Readable Web Pages

Ontology Definition

formal, explicit specification of a shared conceptualization

commonly accepted understanding

conceptual model of a domain

(ontological theory)

unambiguous definition of all concepts, attributes

and relationships

machine-readability

Complete Coherent Supporting use, reuse and interoperability


Web Services in a Nutshell


Semantic Web Services Problem and Vision

Problems with Web Services Today

Descriptions are syntactic All tasks associated with web services application

development have to be carried out by humans: discovery, selection, mediation, composition and invocation

Problems of scalability

SWS Vision

Web(URI, HTML, HTTP)

Web Services(UDDI, WSDL, SOAP)

Semantic Web(RDF, OWL)

Semantic Web Services

Dynamic

Static

Syntax Semantics

Semantic Web Services Definition

Semantic Web Technology Machine readable data Ontological basis

Applied to

Web Services Technology Reusable computational resources

To automate all aspects of application development through reuse

Aspects of Semantic Web Services

Comprehensive description frameworks for describing Web Services and related aspects

Web Service Description Ontologies

Use of domain dependent support ontologies to facilitate automatic data interpretation

Semantic Web aspect

Development of semantic web technologies to automate the Web Service usage process

Web Service aspect

The Web Service Usage Process

Design/Development Create and publish Web service descriptions

Discovery Find usable services for a request

Composition Combine services to achieve a given request

Selection Choose most appropriate service among candidates

Mediation Resolve mismatches between components

Execution Invoke Web service following prescribed constraints

Web Service Execution Support

Monitoring Managing the execution process

Compensation Provision of transactional support and ‘undo’ over composed Web service

invocations

Replacement Facilitate the substitution of services by functionally equivalent stand-ins

Auditing Verify that service execution occurred as expected


Background Projects

DIP

Data, Information and Process Integration with Semantic Web Services (DIP)

DIP's mission is to make Semantic Web Services a reality, providing an infrastructure (i.e. an architecture and tools) that will revolutionize data and process integration in eWork and eCommerce as the Web did it for human information access.

Project Cost 16.30 million Euro

Project Funding 10.10 million Euro

Start Date Start: January 1st 2004 End: December 31st 2006

http://dip.semanticweb.org

DIP Overview

Client

Services

DIP and ESSI

+ + +

=

Raise level of impactPrevent repetition of work

ESSI Working Groups

WSMO WG

WSMX WGWSML WG

A Conceptual Model for SWS

A Formal Language for WSMO

A Rule-based Language for SW

An Execution Environment for WSMO

http://www.wsmo.org/


Web Service Modelling Ontology (WSMO)

WSMO is

An ESSI-Cluster Working Group (joint European research and development initiative)

A conceptual model for Semantic Web Services : Ontology of core elements for Semantic Web Services Has associated formal description language (WSML), and Execution environments (WSMX and IRS-III)

… derived from and based on the Web Service Modeling Framework WSMF

WSMO Design Principles

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

WSMO 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 wants toachieve by using Web Services

Connectors between components with mediation facilities for handling heterogeneities

Non-Functional Properties

Dublin Core Metadata Set: Complete item description Used for resource management

Versioning Information Evolution support

Quality of Service Information Availability, stability

Other Owner, financial

Non-Functional Properties

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

Quality of Service Accuracy NetworkRelatedQoSPerformanceReliability RobustnessScalability Security Transactional Trust

Other Financial Owner TypeOfMatch Version

Ontology Usage & Principles

Ontologies are used as the ‘data model’ throughout WSMO all WSMO element descriptions rely on ontologies all data interchanged in Web Service usage are ontologies Semantic information processing & ontology reasoning

WSMO Ontology Language WSML conceptual syntax for describing WSMO elements logical language for axiomatic expressions (WSML Layering)

WSMO Ontology Design Modularization: import / re-using ontologies, modular approach for

ontology design De-Coupling: heterogeneity handled by OO Mediators

Ontology Specification

Non functional properties See previous

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

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)

Capability Specification

Non functional properties

Imported Ontologies

Used mediators OO Mediator: importing ontologies with mismatch resolution WG Mediator: link to a Goal when the 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)

WSMO Web Service Description

Web ServiceImplementation(not of interest in Web Service Description)

Choreography --- Service Interfaces ---

Capability

functional description

WS

WS

- Advertising of Web Service- Support for WS Discovery

client-service interaction interface for consuming WS - External Visible Behavior- Communication Structure - ‘Grounding’

realization of functionality by aggregating other Web Services - functional decomposition - WS composition

Non-functional Properties

DC + QoS + Version + financial

- complete item description- quality aspects - Web Service Management

WS

Orchestration

VTA

VTA WS ‘Trip Booking’

Capability

provides

Chor.Interf.

Flight Request

Hotel Request

Book Flight

Book Hotel

if hotel = Ø flight.arrivaltime = hotel.arrivaltime

flight information

if flight = Ø

hotel information

process (control + data flow) of goals

Orchestration Definition

VTA

VTA WS ‘Trip Booking’

Capability

provides

Chor.Interf.

Flight Request

Hotel Request

Book Flight

Book Hotel

if hotel = Ø

if flight = Ø

process (control + data flow) between “states” + communication behavior of orchestrating Web Service

Flight WS

Capability

Interface (Chor.)1) get request2) provide offer 3) receive selection4) send confirmation

Orch. ..

Hotel WS

Capability

Interface (Chor.)1) get request2) provide offer 3) receive selection4) send confirmation

Orch. ..

flight request

avaiable flights

hotel request

avaiable hotels

book request booking confirmation

book request

booking confirmation

Runtime Orchestration

Service Interface Description

Ontologies as data model: all data elements interchanged are ontology instances

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

Further characteristics: not restricted to any specific communication technology ontology reasoning for service interoperability determination basis for declarative mediation techniques on service interfaces

Service Interface Description Model

Vocabulary Ω: ontology schema(s) used in service interface description Mode definitions: 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 actions for Choreography and Orchestration

Service Interface Example

Ωin hasValues concept A [ att1 ofType X att2 ofType Y]…

a memberOf A [ att1 hasValue x att2 hasValue y]

a memberOf A [ att1 hasValue x, att2 hasValue y]

b memberOf B [ att2 hasValue m]

IF (a memberOf A [ att1 hasValue x ])THEN (b memberOf B [ att2 hasValue m ])

State ω1 Guarded Transition GT(ω1) State ω2

Ωout hasValues concept B [ att1 ofType W att2 ofType Z]…

Vocabulary: - Concept A in Ωin - Concept B in Ωout

received ontology instance a

Communication Behavior of a Web Service

sent ontology instance b

Goals

Ontological De-coupling of Requester and Provider Derived from task / problem solving methods/domain model Structure and reuse of requests

Search Diagnose Classify Personalise Book a holiday

Requests may in principle not be satisfiable Ontological relationships & mediators used to link goals to web

services

Goal Specification

Non functional properties Imported Ontologies Used mediators

OO Mediators: importing ontologies with heterogeneity resolution GG Mediator:

Goal definition by reusing an already existing goal

allows definition of Goal Ontologies

Requested Capability Describes service functionality expected to resolve the objective Defined as a 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

Mediation

Heterogeneity … For 1$ on programming, $5 - $9 on integration © IBM, Nelson Mattos Mismatches on structural / semantic / conceptual / level Assume (nearly) always necessary

Description of role Components that resolve mismatches Declarative description of arbitrary web service

Types of Mediation within Semantic Web Services: (1) Data: mediate heterogeneous Data Sources

(2) Protocol: mediate heterogeneous Communication Patterns

(3) Process: mediate heterogeneous Business Processes

WSMO Mediators Overview

Mediator Structure

WSMO Mediator

uses a Mediation Service via

Source Component

Source Component

TargetComponent 1 .. n

1

Mediation Services

- as a Goal - directly- optionally incl. Mediation

OO Mediator - Example

OO MediatorMediation Service

Train ConnectionOntology (s1)

Purchase Ontology (s2)

Train Ticket Purchase Ontology

Mediation Services

Goal:“merge s1, s2 and s1.ticket subclassof s2.product”

Discovery

Merging 2 ontologies

GG Mediators

Aim: Support specification of Goals by re-using existing Goals Allow definition of Goal Ontologies (collection of pre-defined Goals) Terminology mismatches handled by OO Mediators

Example: Goal Refinement

GG MediatorMediation Service

Source Goal“Buy a ticket”

Target Goal “Buy a Train Ticket”

postcondition: “aTicket memberof trainticket”

WG & WW Mediators

WG Mediators: link a Web Service to a Goal and resolve occurring mismatches match Web Service and Goals that do not match a priori handle terminology mismatches between Web Services and Goals broader range of Goals solvable by a Web Service

WW Mediators: enable interoperability of heterogeneous Web Services support automated collaboration between Web Services

OO Mediators for terminology import with data level mediation Protocol Mediation for establishing valid multi-party collaborations Process Mediation for making Business Processes interoperable

internal business logic of

Web Service(not of interest in Service

Interface Description)

internal business logic of

Web Service(not of interest in Service

Interface Description)

Protocol & Process Level Mediation

If choreographies are not compatible, then find an appropriate WW Mediator that

resolves possible mismatches to establish Information Compatibility (OO Mediator usage) resolves process / protocol level mismatches in to establish Communication Compatibility

WW

Med

iator

itinerary[origin, destination, date]

time

price

origin

destination

itinerary[origin, destination]

date

itinerary [route,date, time, price]

REQUEST

SERVICE

Processes Mediator

Process Mediation Example

time

pricedate

REQUEST

SERVICE

Processes Mediator



origin

destination



time

pricedate

REQUEST

SERVICE

Processes Mediator


origin

destination





WSML

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

Variants of WSML

WSML Syntax

WSML human-readable syntax WSML exchange syntaxes:

XML syntax: Syntax for exchange over the Web Translation between human-readable and XML syntax XML Schema for WSML has been defined

RDF syntax: Interoperability with RDF applications Maximal reuse of RDF and RDFS vocabulary WSML RDF includes most of RDF Translation between human-readable and RDF syntax For logical expressions, XML literals are used

WSML - example

wsmlVariant _”http://www.wsmo.org/wsml/wsml-syntax/wsml-flight”

namespace _”http://www.example.org/example#”, dc _”http://purl.org/dc/elements/1.1/”

ontology _”http://www.example.org/exampleOntology” [...]

goal _”http://www.example.org/exampleGoal” [...]

etc...


WSMX

WSMX Introduction

Software framework for runtime binding of service requesters and service providers

WSMX interprets service requester’s goal to discover matching services select (if desired) the service that best fits provide mediation (if required) make the service invocation

Is based on the conceptual model provided by WSMO Has a formal execution semantics SO and event-based architecture based on microkernel design

using technologies as J2EE, Hibernate, Spring, JMX, etc.

WSMX Architecture

Internet

Message

MessagePeerPeer

Internet

Message

Message

Bas

eS

ervi

ces

Reasoner Semantic Repository Triple Space

Data Mediation Communication Choreography

Negotiation and Contracting

Orchestration Planning

Management Discovery Process Mediation

Ap

pli

cati

on

Ser

vice

sE

nd

Use

r

Applications

Management & Monitoring

Dev

elop

er

Ontology Editor

Process Editor

Goal Editor

Mapping Editor

Vertical Services

Ver

tica

l S

ervi

ces

WSMX @ Sourceforge.net


IRS-III: A framework and platform for

building Semantic Web Services

IRS-III

The Internet Reasoning Service is an infrastructure for publishing, locating, executing and composing Semantic Web Services

Design Principles

Ontological separation of User and Web Service Contexts Capability Based Invocation Ease of Use One Click Publishing Agnostic to Service Implementation Platform Connected to External Environment Open Complete Descriptions Inspectable Interoperable with SWS Frameworks and Platforms

Features of IRS-III

Based on Soap messaging standard Provides Java API for client applications Provides built-in brokering and service discovery support Provides capability-centred service invocation Publishing support for variety of platforms

Java, Lisp, Web Applications, Web Services

Enables publication of ‘standard code’ Provides clever wrappers One-click publishing of web services

Integrated with standard Web Services world Semantic web service to IRS ‘Ordinary’ web service

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

LispWeb Server

IRS-III Architecture

IRS-III Server

WS Publisher Registry

OCML

WSMO Library

Browser

Invocation Client

Publishing Clients

SOAP Handler

SOAP

Publishing Platforms

Web Service

Java Code

Web Application

SOAPBrowserHandler

PublisherHandler

InvocationHandler

Java

APIWSMX

WSMOStudio

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) Interoperability through WSMO4J and DIP API


WSMO Studio

WSMO Studio

Integrated Service Environment for WSMO Provide easy to use GUI for various WSMO tasks

Working with ontologies Creating WSMO descriptions: goals, services, mediators Creating WSMO centric orchestration and choreography specifications Import (export) from (to) various formats Front-end for ontology and service repositotories Front-end for runtime SWS environments (WSMX, IRS-III)

http://www.wsmostudio.org

http://www.wsmostudio.org/

Requirements for an ISE

Modular design Different users need to customise the functionality in a specific way

Easier to maintain (e.g. ship new versions and bugfixes)

More suitable for 3rd party contributions

Extensibility SWS is an emerging domain

It is difficult to specify requirements and functionality upfront

Architecture based on open standards Lowers the cost of adopting / integrating a tool

3rd party extensions and improvements are more likely to occur

Flexible licensing An Open Source licence improves the adoption rate

WSMO Studio

Modular design Eclipse based plug-in architecture Java based implementation

Extensible 3rd parties may contribute new functionality (plug-ins) or modify existing

functionality

Open Source core LGPL 3rd party contributors are free to choose their respective licensing terms

Integration Platform

WSMO Studio provides an Eclipse-based platform for integration of DIP tools.

Design Publishing

OM

S

Rea

son

er

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rep

osi

tory

P

ersp

ecti

ve


WSMO4J provides a data model by which all tools in the studio communicate…

Design Publishing

OM

S

Rea

son

er

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rep

osi

tory

P

ersp

ecti

ve


… and serialisation to WSML for communication, via the DIP API, with tools outside the studio.

Design Publishing

OM

S

Rea

son

er

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rep

osi

tory

P

ersp

ecti

ve


The Ontology Management Suite (OMS) manages Domain Ontologies with versioning and reporting

Design Publishing

Rep

osi

tory

P

ersp

ecti

ve

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rea

son

er

OM

S


WSMO Studio’s WSMO Perspective allows for the creation of Goals, Services and Mediators

Design Publishing

OM

S

Rep

osi

tory

P

ersp

ecti

ve

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rea

son

er


The integrated Reasoner allows definitions to be validated

Design Publishing

OM

S

Rep

osi

tory

P

ersp

ecti

ve

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rea

son

er


WSMO Studio’s Repository Perspective allows for the communication of Domain Ontologies, Goals, Services

and Mediators with the IRS-III Server…

Design Publishing

OM

S

Rea

son

er

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rep

osi

tory

P

ersp

ecti

ve


… as well as the invocation of Goals in IRS-III and WSMX.

Design Publishing

OM

S

Rea

son

er

Validation

WSMO4J

WS

MO

P

ersp

ecti

ve

Rep

osi

tory

P

ersp

ecti

ve

Editing a Goal in WSMO Studio

WSMO Studio view onto IRS-III


Hands On Session

European Travel Scenario

European Travel Demo

Goal Description

Goals describe requirements from client perspective…

Goal

Capability

Interface

PreconditionAssumption

Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Their Capabilities describe the functional requirements…

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Preconditions express guarantees client can make, purely over information they can communicate, in order that functional requirements are met…

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Assumptions express general guarantees client can make, involving communications and environment, in order that functional requirements are met…

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Postconditions express guarantees client would like over information communicated back in order that functional requirements are met…

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Effects express the general guarantees the client would like after the goal has been achieved

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Capabilities can be used for one or more of: representing a client-oriented perspective, advertising and service discovery. We do not use goal capabilities in the hands on session.

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

The interfaces of goals describe the behavioural requirements of clients, i.e. constraints over communication

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

The choreography expresses communications the client is able to engage in…

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The state signature describes these communications semantically, by linking modes to ontological concepts

Goal Description

The state signature describes these communications semantically, by linking modes to ontological concepts:

IN modes describe communications the client would like to receive

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description


IN modes describe communications the client would like to receive; OUT modes describe communications the client is able to send.

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Goal Description

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Transition rules link communications into a stateful interaction

Goal Description

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Transition rules link communications into a stateful interaction: Transition rules can be used to constrain the stateful behaviour of

matching services, or define the process mediation ‘a priori’. We do not use transition rules in the hands on session.

Goal Description

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

Orchestrations govern over the composite behaviour that is required to go into meeting the goal – the technology to exploit this is not yet available

Goal Description in Tutorial

Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The steps that go into describing a goal in the tutorial are:


Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The steps that go into describing a goal in the tutorial are: Ontological description of the communications (request and response)


Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The steps that go into describing a goal in the tutorial are: Ontological description of the communications (request and response); Creation of a goal


Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The steps that go into describing a goal in the tutorial are: Ontological description of the communications (request and response); Creation of a goal; Attachment of a choreography


Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The steps that go into describing a goal in the tutorial are: Ontological description of the communications (request and response); Creation of a goal; Attachment of a choreography; Attachment of a state signature


Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The steps that go into describing a goal in the tutorial are: Ontological description of the communications (request and response); Creation of a goal; Attachment of a choreography; Attachment of a state signature; Attachment of communications to state signature


Goal

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

State Signature

Transition Rules

The steps that go into describing a goal in the tutorial are: Ontological description of the communications (request and response); Creation of a goal; Attachment of a choreography; Attachment of a state signature Attachment of communications to state signature:

request as OUT mode; response as IN

Web Service Description

WSMO Web Services describe abilities of deployed services…

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service

WG-MediatorMediation Goal

OO-Mediator


Their Capabilities describe their functional abilities…

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Preconditions express guarantees they expect from clients, purely over information they communicate…

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Assumptions express general guarantees they expect of clients, involving communications and environment…

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Postconditions express guarantees they make over information communicated back, providing the preconditions and assumptions are met by the client…

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Effects express the general guarantees made, over communicated and changes to the environment, providing the preconditions and assumptions are met by the client

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The last part of the hands on session uses the assumption for web service selection.

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The interfaces of web services describe their behavioural characteristics, i.e. the communications they engage in

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The choreography expresses communications the service engages in with its clients…

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The state signature describes these communications semantically, by linking modes to ontological concepts

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator



IN modes describe communications the service is able to receive

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator



IN modes describe communications the client would like to receive; OUT modes describe communications the service is able to send

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator



IN modes describe communications the client would like to receive; OUT modes describe communications the service is able to send; modes may be grounded to physical communications for service execution

(SOAP endpoints, REST identifiers, LISP and Java functions).

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Transition rules link communications into a stateful interaction

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Transition rules link communications into a stateful interaction: Transition rules may be used in matching and (process) mediation against

goals,

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Transition rules link communications into a stateful interaction: Transition rules may be used in matching and (process) mediation against

goals, or for In process mediation between IRS-III/WSMX broker and the deployed

service

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


Orchestrations describe how composite services achieve their behaviour in terms of communications between its components, which may be goals or services. We do not cover this in the hands on session.

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


WG-Mediators describe which goals are met by a web service

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


WG-Mediators describe which goals are met by a web service; the descriptions may have some mismatch to be mediated

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


WG-Mediators describe which goals are met by a web service; the descriptions may have some mismatch to be mediated:

a mediation goal describes data mediation which needs to take place between client communications and those of the service

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


WG-Mediators describe which goals are met by a web service; the descriptions may have some mismatch to be mediated:

a mediation goal describes data mediation which needs to take place between client communications and those of the service;

an oo-mediator can map between descriptions in two different ontologies – we do not cover this in the hands on session

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator

Web Service Description in Tutorial

The steps that go into describing a service in the tutorial are:

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal)

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal); Creation of a service

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal); Creation of a service; possibly attachment of an assumption

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal); Creation of a service; possibly attachment of an assumption Creation of a wg-mediator (possibly involving a mediation goal)

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal); Creation of a service; possibly attachment of an assumption Creation of a wg-mediator (possibly involving a mediation goal); Attachment of a choreography

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal); Creation of a service; possibly attachment of an assumption Creation of a wg-mediator (possibly involving a mediation goal); Attachment of a choreography; Attachment of a state signature

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal); Creation of a service; possibly attachment of an assumption Creation of a wg-mediator (possibly involving a mediation goal); Attachment of a choreography; Attachment of a state signature; Attachment of communications to state signature

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator


The steps that go into describing a service in the tutorial are: Ontological description of the communications (may be reused from goal); Creation of a service; possibly attachment of an assumption Creation of a wg-mediator (possibly involving a mediation goal); Attachment of a choreography; Attachment of a state signature Attachment of communications to state signature:

request as IN mode

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator



request as IN mode, grounded to LISP function

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator



request as IN mode, grounded to LISP function; response as OUT

Capability

Interface


Postcondition

Effect

Choreography

Orchestration

State Signature

Transition Rules

Web Service


OO-Mediator

IRS-III Hands On Task

Develop an application for the European Travel scenario based on SWS. The application should support a person booking a train ticket between 2 European cities at a specific time and date

The following WSMO Studio tasks are involved:

Retrieve domain ontology from IRS;

Create WSML ontology concepts to describe communications;

Create WSMO descriptions for Goals, WG-mediators and Web service descriptions;

Export these definitions to the IRS;

Create WSML ontology instances of the requests;

Achieve the goals against these instances.

Tutorial Setup

Travel Services

(3001)

IRS Lisp Publisher

IRS-IIIBrowser & Editor

IRS Server (3000)

Domain Models

WSMO Studio

Travel Related Knowledge Models

Key Classes, Relations, Instances

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

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

(student <person>) -> true, for john matt michal

(business-person <person>) -> true, for liliana michael

Goals

1- Get train timetable Inputs: origin and destination cities (city), date (date-and-time, e.g.

(18 4 2004)) Output: timetable (string)

2- Book train Inputs: passenger name (person), origin and destination cities,

departure time-date (list-date-and-time, e.g. (20 33 16 15 9 2004)) Output: booking information (string)

Services

1 service available for goal 1 No constraints

6 services available for goal 2 As a provider write the constraints applicable to the services to satisfy

the goal (assumption logical expressions)

1 wg-mediator mediation-service Used to convert time in list format to time in universal format

Service constraints

Services 2-5 Services for (origin and destination) cities in determined countries

Service 4-5 Need a mediation service to map goal time-date to service time-date

Services 6-7 Services for students or business people in Europe

Available Functions (1/3)

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

2- book-english-train-journey

christoph milton-keynes london (20 33 16 15 9 2004)"British Rail: CHRISTOPH is booked on the 66 going from MILTON-KEYNES to

LONDON at 16:49, 15, SEPTEMBER 2004. The price is 169 Euros."

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

AUGUST 2004. The price is 27 Euros."


4- book-german-train-journey

christoph berlin frankfurt 3304251200

"First Class Booking German Rail (Die Bahn): CHRISTOPH is booked on the 323 going from BERLIN to FRANKFURT at 17:11, 15, SEPTEMBER 2004. The price is 35 Euros."

5- book-austrian-train-journey sinuhe vienna innsbruck 3304251200

"Austrian Rail (OBB): SINUHE is booked on the 367 going from VIENNA to INNSBRUCK at 16:47, 15, SEPTEMBER 2004. The price is 36 Euros. "


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

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

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

8- mediate-time (lisp function) or JavaMediateTime/mediate (java) (9 30 17 20 9 2004)3304686609


WSMO Studio Demo

Guides for Hands on session


The Solution

English Train Ticket Booking Web ServiceAustrian Train Ticket

Booking Web ServiceGerman Train Ticket Booking Web ServiceFrench Train Ticket

Booking Web Service

Customer

Buy book goalBook Flight goalBuy cinema tickets goal

Buy train ticket goal

SWS based Application Development

Customer Team

Development Team

Summary

Semantic Web Services Semantic Web

creation of a machine interpretable web based on ontologies Web Service

Re-usable programs available of the internet Application of Semantic Web technologies to Web Services

WSMO Conceptual framework for describing web services Ontologies Goals, Mediators, Web Services

WSML Family of representation languages for WSMO

WSMX WSMO reference architecture

IRS-III WSMO compliant platform

WSMO Studio WSMO editor and integration platform

Online Tutorials

Full set of online tutorial http://kmi.open.ac.uk/projects/dip/events.html

Tutorial Webcasts http://stadium.open.ac.uk/dip/

http://kmi.open.ac.uk/projects/dip/events.html

http://stadium.open.ac.uk/dip/



Working group and software URLs

WSMO – the conceptual model/ontology http://www.wsmo.org

WSML – the family of representation languages http://www.wsml.org

WSMX the execution environment http://www.wsmx.org

IRS-III home page http://kmi.open.ac.uk/projects/irs/

WSMO Studio Home page http://www.wsmostudio.org/



http://www.wsml.org/

http://www.wsml.org/

http://www.wsmx.org/


http://kmi.open.ac.uk/projects/irs/



WSMO References

[WSMO Specification]: Roman, D.; Lausen, H.; Keller, U. (eds.): Web Service Modeling Ontology, WSMO Working Draft D2, final version 1.2, 13 April 2005.

[WSMO Primer]: Feier, C. (ed.): WSMO Primer, WSMO Working Draft D3.1, 18 February 2005.

[WSMO Choreography and Orchestration] Roman, D.; Scicluna, J., Feier, C. (eds.): Ontology-based Choreography and Orchestration of WSMO Services, WSMO Working Draft D14, 01 March 2005.

[WSMO Use Case] Stollberg, M.; Lausen, H.; Polleres, A.; Lara, R. (ed.): WSMO Use Case Modeling and Testing, WSMO Working Drafts D3.2; D3.3.; D3.4; D3.5, 05 November 2004.

[WSML] de Bruijn, J. (Ed.): The WSML Specification, WSML Working Draft D16, 03 February 2005.

WSMX References

http://www.wsmx.org The main documents are:

Conceptual Model (http://www.wsmo.org/2004/d13/d13.1/v0.3/) Architecture (http://www.wsmo.org/TR/d13/d13.4/v0.2/) Implementation: open source at http://sourceforge.net/projects/wsmx Documentation (http://www.wsmo.org/TR/d22/v0.2/) Execution Semantics (http://www.wsmo.org/TR/d13/d13.2/) WSMX Toolkit (http://www.wsmo.org/TR/d9/d9.1/v0.2/)

Further Readings: Bussler, C. (2003): B2B Integration. Berlin, Heidelberg: Springer.

Haselwanter, T.; Zaremba, Ma.., Zaremba Mi.: Enabling Components Management and Executions Semantics in WSMX. In Proceedings of the 2nd International WSMO Implementation Workshop (WIW 2005), Innsbruck, Austria, June 2005.

Zaremba, M. and Bussler, C.: Towards Dynamic Execution Semantics in Semantic Web Services. In Proceedings of the WWW 2005 Workshop on Web Service Semantics: Towards Dynamic Business Integration, 2005.


http://www.wsmo.org/2004/d13/d13.1/v0.3/






http://www.wsmo.org/TR/d13/d13.4/v0.2/

http://sourceforge.net/projects/wsmx

http://sourceforge.net/projects/wsmx

http://www.wsmo.org/TR/d22/v0.2/




http://www.wsmo.org/TR/d13/d13.2/

http://www.wsmo.org/TR/d9/d9.1/v0.2/

J. Domingue, S. Galizia and L. Cabral (2005). Choreography in IRS-III - Coping with Heterogeneous Interaction Patterns in Web Services. 4th International Semantic Web Conference (ISWC 2005) . Galway, Ireland, November 6th - 10th 2005.

J. Domingue, L. Cabral, F. Hakimpour,D. Sell and E. Motta (2004). IRS-III: A Platform and Infrastructure for Creating WSMO-based Semantic Web Services. Proceedings of the Workshop on WSMO Implementations (WIW 2004) Frankfurt, Germany, September 29th-30th, 2004.

S. Galizia and J. Domingue (2004). Towards a Choreography for IRS-III. Proceedings of the Workshop on WSMO Implementations (WIW 2004) Frankfurt, Germany, September 29th-30th, 2004.

Cabral, L., Domingue, J., Motta, E., Payne, T. and Hakimpour, F. (2004).

Approaches to Semantic Web Services: An Overview and Comparisons. In proceedings of the First European Semantic Web Symposium (ESWS2004). May 10th-12th 2004, Heraklion, Crete, Greece.

Motta, E., Domingue, J., Cabral, L. and Gaspari, M. (2003) IRS-II: A Framework and Infrastructure for Semantic Web Services. In proceedings of the 2nd International Semantic Web Conference (ISWC2003) October 20th-23th 2003, Sundial Resort, Sanibel Island, Florida, USA.

IRS-III References

Acknowledgements (1/2)

The WSMO work is funded by the European Commission under the projects ASG, DIP, Knowledge Web, SEKT, SWWS, AKT and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Austrian government under the FIT-IT program.

IRS development is funded by the European Commission under the DIP project, and formerly IBROW, and by the UK EPSRC under the AKT project, and formerly MIAKT.

WSMO Studio is partly funded by the EU IST projects DIP, InfraWebs and SemanticGov

Acknowledgements (2/2)

This slide set was developed by the DIP and WSMO tutorial team who include:

Liliana Cabral, Stefania Galizia, Matt Moran, Barry Norton, Michael Stollberg and Michal Zaremba

Some slides adapted from slides of Frank van Harmelen and Enrico Motta

European Integrated Project John Domingue and Barry Norton, The Open University Frank Leymann,...

Documents

Transcript of European Integrated Project John Domingue and Barry Norton, The Open University Frank Leymann,...