Semantic Web Service Systems
description
Transcript of Semantic Web Service Systems
1
Semantic Web Service Systems
3rd European Semantic Web Conference
ESWC 200611-14 June, Budva, Montenegro
Presenters: Liliana Cabral Mick KerriganMaciej Zaremba
Contribution: Emilia CimpianJohn DomingueMatthew MoranBrahmananda SapkotaMichal Zaremba
ESWC, Budva, 2006 2
Part I: Introduction to Semantic Web Services and WSMO (30 min)
Part II: The Web Service Execution Environment, WSMX (45 min)– WSMX motivation, scope, approach – System Architecture
Coffee Break (15 min)
Part III: The Internet Reasoning Service, IRS III (45 min)– IRS Architecture – IRS Editing, Browsing, and Publication Environment
Part IV: Hands-On Session with IRS III and WSMT (1 hour 15 min)– Create and publish WSMO descriptions – Use WSMX and IRS frameworks for goal-driven service invocation
Agenda
ESWC, Budva, 2006 3
The Aims of this Tutorial
• Introduce the aims & challenges of Semantic Web Services (SWS) – focusing on the WSMO approach
• Describe WSMX and IRS-III, two complimentary execution environments for Semantic Web Services
• Demonstrate WSMX, IRS-III and WSMT, a design tool for WSMO ontologies and service descriptions
ESWC, Budva, 2006 4
Part I: Introduction to Semantic Web Services and WSMO
Part II: The Web Service Execution Environment, WSMX– WSMX motivation, scope, approach – System Architecture
Coffee Break
Part III: The Internet Reasoning Service, IRS III– IRS Architecture – IRS Editing, Browsing, and Publication Environment
Part IV: Hands-On Session with IRS III and WSMT– Create and publish WSMO descriptions – Use WSMX and IRS frameworks for goal-driven service invocation
Agenda
ESWC, Budva, 2006 5
Introduction to Semantic Web Services
• Introduction to Semantic Web
• Introduction to Web services
Semantic Web Services
ESWC, Budva, 2006 6
500 million user
more than 3 billion pages
Static WWWURI, HTML, HTTP
Semantic Web and Web Services – The Vision
ESWC, Budva, 2006 7
Static WWWURI, HTML, HTTP
Serious Problems inSerious Problems ininformation finding,information finding,information extracting,information extracting,Information representing,Information representing,information interpreting and information interpreting and information maintaining.information maintaining.
Semantic WebRDF, RDF(S), OWL
Semantic Web and Web Services
ESWC, Budva, 2006 8
Static WWWURI, HTML, HTTP
Bringing the Bringing the computer back computer back as a device for as a device for computationcomputation
Semantic WebRDF, RDF(S), OWL
Dynamic Web ServicesUDDI, WSDL, SOAP
Semantic Web and Web Services – The Vision
ESWC, Budva, 2006 9
Static WWWURI, HTML, HTTP
Bringing Bringing the Web the Web to its full to its full potentialpotential
Semantic WebRDF, RDF(S), OWL
Dynamic Web ServicesUDDI, WSDL, SOAP
Intelligent WebServices
Semantic Web and Web Services – The Vision
ESWC, Budva, 2006 10
Formal, explicit specification of a shared conceptualization
commonly accepted understanding
conceptual model of a domain
(ontological theory)
unambiguous terminology definitions
machine-readability with computational
semantics
Ontology Definition
ESWC, Budva, 2006 11
Ontology Example
Concept conceptual entity of the domain
Attribute property of a concept
Relation relationship between concepts or properties
Axiom coherent description between Concepts / Properties / Relations via logical expressions
Person
Student Professor
Lecture
isA – hierarchy (taxonomy)
name email
studentnr.
researchfield
topiclecture
nr.
attends holds
holds(Professor, Lecture) Lecture.topic Professor.researchField
ESWC, Budva, 2006 12
What are Web Services
• Loosely coupled, reusable components
• Described using XML– WSDL and XML Schema
• Encapsulate discrete functionality
• Distributed
• Programmatically accessible over internet protocols– HTTP, SOAP
ESWC, Budva, 2006 13
Using Web Services
ESWC, Budva, 2006 14
Using Web Services
ESWC, Budva, 2006 15
Problems unresolved by Web Services
• (Semi)-automatic service discovery
• Data interoperability
• Process interoperability
• (Semi)-automatic service composition
ESWC, Budva, 2006 16
Semantic Web Services
• Define formal description frameworks for describing Web Services and related aspects – Ontologies such as WSMO and OWL-S (and WSDL-S)
• Support ontologies as underlying data model to allow machine supported data interpretation – Ontology language such as WSML and OWL
• Define semantically driven technologies for automation of the Web Service usage process– Tools and environments such as WSMX, IRS-III, WSMT
ESWC, Budva, 2006 17
Semantic Web Services (2)
Usage Process:
• Publication: – Make available the description of the capabilities 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 (or goals) to achieve a goal
• Mediation: – Solve mismatches (in data or process) among the combined services
• Execution: – Invoke services following programmatic conventions
ESWC, Budva, 2006 18
Semantic Web Services =
Semantic Web Technology +
Web Service Technology
Summary
ESWC, Budva, 2006 19
Web Service Modeling Ontology (WSMO)
• A conceptual model for Semantic Web Services: – Ontology of core elements for Semantic Web Services
– a formal description language (WSML)
– execution environment (WSMX)
• … derived from and based on the Web Service Modeling Framework WSMF
• an European Semantic System Initiative – “ESSI Cluster” Working Group
– joint European research and development initiative
ESWC, Budva, 2006 20
A Conceptual Model for SWS
A Formal Language for WSMO
A Rule-based Language for SWS
Execution Environment for WSMO
WSMO Working Groups
ESWC, Budva, 2006 21
WSMO Design Principles
Web Compliance Ontology-Based
Strict DecouplingOf Modeling Elements
Centrality of Mediation
Ontological Role Separation
Description versus Implementation
Execution Semantics
WSMO
ESWC, Budva, 2006 22
Objectives that a client wants toachieve by using Web Services
Provide the formally specified terminologyof the information used by all other components
Semantic description of Web Services: - Capability (functional)- Interfaces (usage)
Connectors between components with mediation facilities for handling heterogeneities
WSMO Top Level Notions
ESWC, Budva, 2006 23
Non-Functional Properties
• Every WSMO element can be described by properties that contain relevant, non-functional aspects.
• Sample information sets are: – Dublin Core Metadata Set:
• For resource management
– Versioning Information • For evolution support
– Quality of Service Information • For availability, stability
– Other • WSMO non functional properties are extensible
ESWC, Budva, 2006 24
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
Non-Functional Properties List
ESWC, Budva, 2006 25
WSMO Ontologies
Provide the formally specified terminology
of the information used by all other components
Semantic description of Web Services: - Capability (functional)- Interfaces (usage)
Connectors between components with mediation facilities for handling heterogeneities
Objectives that a client wants to achieve by using Web Services
ESWC, Budva, 2006 26
Ontology Description and Usage
• Ontologies are used as the ‘data model’ throughout WSMO – WSMO is defined in terms of itself– All data-types used in Web Service interfaces are ontology concepts – Discovery, mediation and composition are based on 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
ESWC, Budva, 2006 27
Ontology Specification
• Non functional properties (see before)
• Imported Ontologies importing existing ontologies where no heterogeneities arise
• Used mediators OO Mediators (ontology import with terminology mismatch handling)
• Ontology Elements:Concepts set of concepts that belong to the ontology, incl.
Attributes set of attributes that belong to a concept
Relations define interrelations between several concepts
Functions special type of relation (unary range = return value)
Instances set of instances that belong to the represented ontology
Axioms axiomatic expressions in ontology (logical statement)
ESWC, Budva, 2006 28
WSMO Web services
Provide the formally specified terminology
of the information used by all other components
Semantic description of Web Services: - Capability (functional)- Interfaces (usage)
Connectors between components with mediation facilities for handling heterogeneities
Objectives that a client wants to achieve by using Web Services
ESWC, Budva, 2006 29
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
WSMO Web service description
ESWC, Budva, 2006 30
Capability Specification
• Non functional properties • Imported Ontologies • Used mediators
– OO Mediator: importing ontologies with mismatch resolution – WG Mediator: link to a Goal wherefore service is not usable a priori
• Pre-conditions – What a web service expects in order to be able to provide its service– 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 WS 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)
ESWC, Budva, 2006 31
VTAService
Date
Time
Flight, Hotel
Error
Confirmation
Hotel Service
Flight Service
Date, Time
Hotel
Error
Date, Time
Flight
Error
When the service is requested
When the service requests
Choreography & Orchestration
VTA example:
• Choreography = how to interact with the service to consume its functionality • Orchestration = how service functionality is achieved by aggregating other Web services
Confirmation
Confirmation
ESWC, Budva, 2006 32
Choreography Aspects
• Interface for consuming Web Service
– External Visible Behavior• those aspects of the workflow of a Web Service where Interaction is required • described by workflow constructs: sequence, split, loop, parallel
– Communication Structure • messages sent and received • their order (communicative behavior for service consumption) • choreography related errors (e.g. input wrong, message timeout, etc.)
– Grounding • concrete communication technology for interaction
– Formal Model • reasoning on Web Service interfaces (service interoperability)• allow mediation support on Web Service interfaces
ESWC, Budva, 2006 33
- decomposition of service functionality
- all service interaction via choreographies
Control Structure for aggregation of other Web Services
WS
Web S
ervice Business Logic
1
2
3
4
WS
State in Orchestration
Control Flow
Data Flow
Service Interaction
Orchestration Aspects
ESWC, Budva, 2006 34
Orchestration Aspects
• Service interfaces are concerned with service consumption and interaction
• Choreography and Orchestration as sub-concepts of Service Interface
• Common requirements for service interface description: – represent the dynamics of information interchange during service
consumption and interaction – support ontologies as the underlying data model – appropriate communication technology for information interchange– sound formal model / semantics of service interface specifications in
order to allow operations on them.
ESWC, Budva, 2006 35
WSMO Goals
Provide the formally specified terminologyof the information used by all other components
Semantic description of Web Services: - Capability (functional)- Interfaces (usage)
Connectors between components with mediation facilities for handling heterogeneities
Objectives that a client wants to achieve by using Web Services
ESWC, Budva, 2006 36
Goals
• Ontological De-coupling of Requester and Provider
• Goal-driven Approach– derived from AI rational agent approach
– Requester formulates objective independently
– ‘Intelligent’ mechanisms detect suitable services for solving the Goal
– allows re-use of Services for different purposes
• Usage of Goals within Semantic Web Services– A Requester, 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
– Goal Resolution Management is realized in implementations
ESWC, Budva, 2006 37
Goal Specification
• Non functional properties
• Imported Ontologies
• Used mediators
– OO Mediators: importing ontologies with heterogeneity resolution
– GG Mediator:
• Goal definition by reusing an already existing goal• allows definition of Goal Ontologies
• Requested Capability
– describes service functionality expected to resolve the objective
– defined as capability description from the requester perspective
• Requested Interface
– describes communication behaviour supported by the requester for consuming a Web Service (Choreography)
– Restrictions / preferences on orchestrations of acceptable Web Services
ESWC, Budva, 2006 38
WSMO Mediators
Provide the formally specified terminology
of the information used by all other components
Semantic description of Web Services: - Capability (functional)- Interfaces (usage)
Connectors between components with mediation facilities for handling heterogeneities
Objectives that a client wants to achieve by using Web Services
ESWC, Budva, 2006 39
Mediation
• Heterogeneity … – Mismatches on structural / semantic / conceptual / functional / 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) Functional Level: mediate mismatches between Web Service/Goal and Web Service/Goals
functionalities(3) Process/Protocol Level: mediate heterogeneous Business Processes/Communication
Patterns
• Layers of Mediators– Specification Layer – WSMO Mediators– Implementation Layer – Levels of Mediation
ESWC, Budva, 2006 40
WSMO Mediators Overview
ESWC, Budva, 2006 41
WSMO Mediator
uses a Mediation Service via
Source Component
Source Component
TargetComponent 1 .. n
1
Mediation Services
- as a Goal - directly- optionally incl. Mediation
Mediator Structure
Specification layer
Implementation layer
ESWC, Budva, 2006 42
OO MediatorMediation Service
Train ConnectionOntology (s1)
Purchase Ontology (s2)
Train Ticket Purchase Ontology
Mediation Services
Discovery
Merging 2 ontologies
OO Mediator - Example
Goal:“merge s1, s2 and
s1.ticket subclassof s2.product”
ESWC, Budva, 2006 43
GG MediatorMediation Service
Source Goal“Buy a ticket”
Target Goal “Buy a Train Ticket”
postcondition: “aTicket memberof trainticket”
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
ESWC, Budva, 2006 44
• 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
WG & WW Mediators
ESWC, Budva, 2006 45
Data Level Mediation
• Scope– Solving terminological mismatches
• Related Aspects / Techniques: – Ontology Integration (Mapping, Merging, Alignment) – Data Lifting & Lowering– Transformation between Languages / Formalisms
• Terminology Mismatches Classification – Conceptualization Mismatches
• same domain concepts, but different conceptualization• different levels of abstraction • different ontological structure • => resolution only includs human intervention
– Explication Mismatches • mismatches between:
– T (Term used), D (definition of concepts), C (real world concept)• => automated resolution partially possible
ESWC, Budva, 2006 46
Functional Level Mediation
• Scope– Solving functional mismatches between goals and/or ws
• Related Aspects/Techniques– Discovery– Semantic Matchmaking
• Matchmaking Mismatches
= G/WS = G/WS
X
Exact Match Subsumption Match Intersection Match No MatchPlugIn Match
ESWC, Budva, 2006 47
Process Level Mediation
• Scope– Resolves communication mismatches and establish behavior
compatibility
• Related Aspects/Techniques– Data and control flow composition
• Process Mismatches– Signature terminology mismatches (need for data level mediation)
– Communication/behavior mismatches
Business Partner1Business Partner1
Business Partner2Business A
B B
Business Partner1Business Partner1
Business Partner2Business Partner2
A B
B A
Business Partner1Business Partner1
Business Partner2Business Partner2
A and BA
B
Business Partner1Business Partner1
Business Partner2Business Partner2
A
BA and B
PM
PM
PM
PM
Business Partner1Business Partner1
Business Partner2Business Partner2
A
AckA
APM
ESWC, Budva, 2006 48
WSMO Mediators and Mediation Levels
• ooMediator– Data Level Mediation
• ggMediator– Data Level Mediation
– Functional Level Mediation
Example:
• wgMediator– Data Level Mediation– Functional Level Mediation– Process Level Mediation
• wwMediator– Data Level Mediation– Functional Level Mediation– Process Level Mediation
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)
WW
Med
iator
ESWC, Budva, 2006 49
Part I: Introduction to Semantic Web Services and WSMO
Part II: The Web Service Execution Environment, WSMX– WSMX motivation, scope, approach – System Architecture
Coffee Break
Part III: The Internet Reasoning Service, IRS III– IRS Architecture – IRS Editing, Browsing, and Publication Environment
Part IV: Hands-On Session with IRS III and WSMT– Create and publish WSMO descriptions – Use WSMX and IRS frameworks for goal-driven service invocation
Agenda
ESWC, Budva, 2006 50
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• Service Oriented and event-based architecture
– based on microkernel design using technologies as J2EE, Hibernate, Spring, JMX, etc.
ESWC, Budva, 2006 51
WSMX Motivation
• Provide a reference implementation for WSMO– Eat our own cake
• Build on existing Web service technology– Use existing standards where possible
• Enable goal based service discovery and invocation– Run-time binding of service requester and provider
• Extend SOA to cater for semantic technology– Everything is defined in an ontology
• Keep open-source to encourage participation– Developers are free to use in their own code
• Define formal execution semantics– Unambiguous model of system behaviour
ESWC, Budva, 2006 52
WSMX Usage Scenario
ESWC, Budva, 2006 53
WSMX Usage Scenario - P2P
• A P2P network of WSMX ‘nodes’• Each WSMX node described as a SWS• Communication via WSML over SOAP• Distributed discovery – first aim• Longer term aim - distributed execution environment
ESWC, Budva, 2006 54
WSMX Usage Scenario - P2P
Peer
Internet
Message
Message
Internet
Message
MessagePeer
WSMX SWSARCHITECTURE
ESWC, Budva, 2006 55
WSMX Usage Scenario - P2P
Exe
cutio
n M
an
ag
em
en
t
Ve
rtic
al S
erv
ice
s e
.g.
Se
curi
ty
Storage Reasoning
Communication (external)
Fault Handling Monitoring
Data MediationProcess
Mediation
Discovery Adaptation Composition Choreography
Application Services Layer
Problem Solving Layer
Base Services Layer
End User Tools Developer Tools
Internet
Message
MessagePeerPeer
Internet
Message
Message
ESWC, Budva, 2006 56
External SOA
SEE
Execution Management
(Execution Semantics)
Platform Service: Data Mediation
Platform Service:Discovery
Platform Service:[…]
User Service
User Service
User Service
User Service
User Service versus Platform Service in SWS Systems
ESWC, Budva, 2006 57
Vertical and Horizontal Services
• Vertical services remain invisible to horizontal services, and during its execution, the horizontal services remain unaware that vertical services are executed together with them
• Vertical services invoke horizontal services, coordinating overall workflow, rather than horizontal service invoking the vertical
ESWC, Budva, 2006 58
Design Principles
• Strong Decoupling & Strong Mediation– autonomous components with mediators for interoperability
• Interface vs. Implementation– distinguish interface (= description) from implementation (=program)
• Peer to Peer– interaction between equal partners (in terms of control)
WSMO Design Principles == WSMX Design Principles
== SOA Design Principles
ESWC, Budva, 2006 59
Benefits of SOA
• Better reuse– Build new functionality (new execution semantics) on top of
existing Business Services
• Well defined interfaces – Manage changes without affecting the Core System
• Easier Maintainability– Changes/Versions are not all-or-nothing
• Better Flexibility
ESWC, Budva, 2006 60
Selected Components
• Adapters• Parser• Invoker• Choreography • Process Mediator• Discovery• Data Mediator• Resource Manager
• Reasoning E
xecu
tion
Ma
na
ge
me
nt
Ve
rtic
al S
erv
ice
s e
.g.
Se
curi
ty
Storage Reasoning
Communication (external)
Fault Handling Monitoring
Data MediationProcess
Mediation
Discovery Adaptation Composition Choreography
Application Services Layer
Problem Solving Layer
Base Services Layer
End User Tools Developer Tools
Internet
Message
MessagePeerPeer
Internet
Message
Message
ESWC, Budva, 2006 61
Adapters
• To overcome data representation mismatches on the communication layer
• Transforms the format of a received message into WSML compliant format
• Based on mapping rules
ESWC, Budva, 2006 62
Parser
• WSML compliant parser– Code handed over to wsmo4j initiative
http://wsmo4j.sourceforge.net/
• Validates WSML description files
• Compiles WSML description into internal memory model
• Stores WSML description persistently
ESWC, Budva, 2006 63
Communication Manager – Invoker
• WSMX uses – The Apache Jetty in-code Web server
– The Apache SOAP with Attachments library (SAAJ)
• WSMO service descriptions are grounded to WSDL• Both RPC and Document style invocations possible• Input parameters for the Web Services are translated from WSML to
XML using an additional XML Converter component.
Network
InvokerApache
AXISXML
ConverterMediatedWSML Data
XML WebService
SOAP
ESWC, Budva, 2006 64
Choreography
• The Choreography engine handles the exchange of messages based on WSML descriptions
• WSMX Requester (Goal description)
• WSMX Provider (Web Service description)
• Works closely with the communication manager
ESWC, Budva, 2006 65
Process Mediator
• Handles differences between Goal and Web service choreographies (if possible)
• Design-time aspect – determine equivalences between the choreographies and store rules
• Run-time aspect – analyse the two choreography instances and to use the rules to mediate any mismatches
ESWC, Budva, 2006 66
Discovery
• Responsible for finding appropriate Web Services to achieve a goal (discovery)
• Naive discovery component based on keyword matching– Keywords identified in the NFP of the goal– Matched against NFPs of the published WSs – Variable set of NFPs to be considered for this process– To be extended
• Values in NFPs might be concepts from ontologies
• More elaborate string matching algorithms
• Advanced semantic discovery in prototypical stage
ESWC, Budva, 2006 67
Data Mediator
• Ontology-to-ontology mediation
• A set of mapping rules are defined and then executed
• Initially rules are defined semi-automatic
• Create for each source instance the target instance(s)
Target Ontology
Source Ontology
Storage
Mappings
Mappings
Source Instance
Target Instance
Run-time ComponentDesign-time Component
Data Mediation
ESWC, Budva, 2006 68
Resource Manager
• Stores internal memory model to a data store
• Decouples storage mechanism from the rest of WSMX
• Data model is compliant to WSMO API
• Independent of any specific data store implementation i.e. database and storage mechanism
ESWC, Budva, 2006 69
Reasoner
• Mins – Datalog + Negation + Function
Symbols Reasoner Engine– Features
• Built-in predicates • Function symbols • Stratified negation
• WSMO4J– validation, serialization and parsing
• WSML2Reasoner– Reasoning API
• mapping fromWSML to a vendor-neutral rule representation
– Contains: • Common API for WSML Reasoners• Transformations of WSML to tool-specific input data
(query answering or instance retrieval)
• WSML-DL-Reasoner– Features:
• T-Box reasoning (provided by FaCT++) • Querying for all concepts • Querying for the equivalents, for the children, for the
descendants, for the parents and for all ancestors of a given concept
• Testing the satisfiability of a given concept with respect to the knowledge base
• Subsumption test of two concepts with respect to the knowledge base
• Wrapper of WSML-DL to the XML syntax of DL used in the DIG interface
ESWC, Budva, 2006 70
System Entry Points
• achieveGoal (WSMLDocument)
• getWebServices (WSMLDocument)
invokeWebService(WSMLDocument, Context)
ESWC, Budva, 2006 71
Define “Business” Process
ESWC, Budva, 2006 72
Generate Wrappers for Components
Discovery Wrapper
ChoreographyWrapper
Communication Manager Wrapper
Registry of known components
ESWC, Budva, 2006 73
Context Data
PROCESS CONTEXT
Discovery Wrapper
Data Mediator ChoreographyWrapper
Communication Manager Wrapper
Registry of known components
Choreography objectMediated objects ,
Web Services entities
ErrorsExceptions
ESWC, Budva, 2006 74
Event-based Implementation
ESWC, Budva, 2006 75
WSMX Conclusions
• Conceptual model is WSMO • End to end functionality for executing SWS• Has a formal execution semantics• Real implementation • Open source code base at SourceForge• Event-driven component architecture
Exe
cutio
n M
ana
gem
ent
Ver
tical
Ser
vice
s e
.g. S
ecur
ity
Storage Reasoning
Communication (external)
Fault Handling Monitoring
Data MediationProcess
Mediation
Discovery Adaptation Composition Choreography
Application Services Layer
Problem Solving Layer
Base Services Layer
End User Tools Developer Tools
Internet
Message
MessagePeerPeer
Internet
Message
Message
ESWC, Budva, 2006 76
Time for a break …
ESWC, Budva, 2006 77
Part I: Introduction to Semantic Web Services and WSMO
Part II: The Web Service Execution Environment, WSMX– WSMX motivation, scope, approach – System Architecture
Coffee Break
Part III: The Internet Reasoning Service, IRS III– IRS Architecture – IRS Editing, Browsing, and Publication Environment
Part IV: Hands-On Session with IRS III and WSMT– Create and publish WSMO descriptions – Use WSMX and IRS frameworks for goal-driven service invocation
Agenda
ESWC, Budva, 2006 78
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
ESWC, Budva, 2006 79
Features of IRS-III (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
ESWC, Budva, 2006 80
Features of IRS-III (2/2)
• Publishing support for variety of platforms– Java, Lisp, Web Applications, Java 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
ESWC, Budva, 2006 81
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
ESWC, Budva, 2006 82
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
ESWC, Budva, 2006 83
European Travel Scenario
ESWC, Budva, 2006 84
European Travel Demo
ESWC, Budva, 2006 85
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)
ESWC, Budva, 2006 86
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
ESWC, Budva, 2006 87
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
ESWC, Budva, 2006 88
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
ESWC, Budva, 2006 89
Editing a Goal in WSMO Studio
ESWC, Budva, 2006 90
WSMO Studio view onto IRS-III
ESWC, Budva, 2006 91
Part I: Introduction to Semantic Web Services and WSMO
Part II: The Web Service Execution Environment, WSMX– WSMX motivation, scope, approach – System Architecture
Coffee Break
Part III: The Internet Reasoning Service (IRS III) and WSMO Studio (45 mins)– IRS Architecture – IRS Editing, Browsing, and Publication via WSMO Studio
Part IV: Hands-On Session with IRS III and WSMO Studio (1 hour 15 min)– Create and publish WSMO descriptions – Use IRS frameworks for goal-driven service invocation
Agenda
ESWC, Budva, 2006 92
European Travel Scenario
ESWC, Budva, 2006 93
European Travel Demo
ESWC, Budva, 2006 94
Goal Description
• Goals describe requirements from client perspective…
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 95
Goal Description
• Their Capabilities describe the functional requirements…
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 96
Goal Description
• Preconditions express guarantees client can make, purely over information they can communicate, in order that functional requirements are met…
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 97
Goal Description
• Assumptions express general guarantees client can make, involving communications and environment, in order that functional requirements are met…
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 98
Goal Description
• Postconditions express guarantees client would like over information communicated back in order that functional requirements are met…
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 99
Goal Description
• Effects express the general guarantees the client would like after the goal has been achieved
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 100
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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 101
Goal Description
• The interfaces of goals describe the behavioural requirements of clients, i.e. constraints over communication
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 102
Goal Description
• The choreography expresses communications the client is able to engage in…
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 103
Goal Description
Goal
Capability
Interface
PreconditionAssumption
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
ESWC, Budva, 2006 104
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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 105
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;– OUT modes describe communications the client is able to send.
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
ESWC, Budva, 2006 106
Goal Description
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
• Transition rules link communications into a stateful interaction
ESWC, Budva, 2006 107
Goal Description
Goal
Capability
Interface
PreconditionAssumption
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.
ESWC, Budva, 2006 108
Goal Description
Goal
Capability
Interface
PreconditionAssumption
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
ESWC, Budva, 2006 109
Goal Description in Tutorial
Goal
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
State Signature
Transition Rules
• The steps that go into describing a goal in the tutorial are:
ESWC, Budva, 2006 110
Goal Description in Tutorial
Goal
Capability
Interface
PreconditionAssumption
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)
ESWC, Budva, 2006 111
Goal Description in Tutorial
Goal
Capability
Interface
PreconditionAssumption
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
ESWC, Budva, 2006 112
Goal Description in Tutorial
Goal
Capability
Interface
PreconditionAssumption
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
ESWC, Budva, 2006 113
Goal Description in Tutorial
Goal
Capability
Interface
PreconditionAssumption
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
ESWC, Budva, 2006 114
Goal Description in Tutorial
Goal
Capability
Interface
PreconditionAssumption
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
ESWC, Budva, 2006 115
Goal Description in Tutorial
Goal
Capability
Interface
PreconditionAssumption
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
ESWC, Budva, 2006 116
Web Service Description
• WSMO Web Services describe abilities of deployed services…
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 117
Web Service Description
• Their Capabilities describe their functional abilities…
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 118
Web Service Description
• Preconditions express guarantees they expect from clients, purely over information they communicate…
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 119
Web Service Description
• Assumptions express general guarantees they expect of clients, involving communications and environment…
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 120
Web Service Description
• Postconditions express guarantees they make over information communicated back, providing the preconditions and assumptions are met by the client…
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 121
Web Service Description
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 122
Web Service Description
• The last part of the hands on session uses the assumption for web service selection.
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 123
Web Service Description
• The interfaces of web services describe their behavioural characteristics, i.e. the communications they engage in
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 124
Web Service Description
• The choreography expresses communications the service engages in with its clients…
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 125
Web Service Description
• The state signature describes these communications semantically, by linking modes to ontological concepts
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 126
Web Service Description
• The state signature describes these communications semantically, by linking modes to ontological concepts:– IN modes describe communications the service is able to
receive
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 127
Web Service Description
• The state signature describes these communications semantically, by linking modes to ontological concepts:– IN modes describe communications the client would like to receive;
– OUT modes describe communications the service is able to send
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 128
Web Service Description
• The state signature describes these communications semantically, by linking modes to ontological concepts:
– 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 129
Web Service Description
• Transition rules link communications into a stateful interaction
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 130
Web Service Description
• Transition rules link communications into a stateful interaction:– Transition rules may be used in matching and (process)
mediation against goals,
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 131
Web Service Description
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 132
Web Service Description
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 133
Web Service Description
• WG-Mediators describe which goals are met by a web service
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 134
Web Service Description
• WG-Mediators describe which goals are met by a web service;• the descriptions may have some mismatch to be mediated
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 135
Web Service Description
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 136
Web Service Description
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 137
Web Service Description in Tutorial
• The steps that go into describing a service in the tutorial are:
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 138
Web Service Description in Tutorial
• The steps that go into describing a service in the tutorial are:– Ontological description of the communications (may be reused
from goal)
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 139
Web Service Description in Tutorial
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 140
Web Service Description in Tutorial
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 141
Web Service Description in Tutorial
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 142
Web Service Description in Tutorial
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 143
Web Service Description in Tutorial
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 144
Web Service Description in Tutorial
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 145
Web Service Description in Tutorial
• 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
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 146
Web Service Description in Tutorial
• 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, grounded to LISP function
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 147
Web Service Description in Tutorial
• 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, grounded to LISP function; response as OUT
Capability
Interface
PreconditionAssumption
Postcondition
Effect
Choreography
Orchestration
State Signature
Transition Rules
Web Service
WG-MediatorMediation Goal
OO-Mediator
ESWC, Budva, 2006 148
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.
ESWC, Budva, 2006 149
Tutorial Setup
Travel Services
(3001)
IRS Lisp Publisher
IRS Server (3000)
Domain Models
WSMO Studio
ESWC, Budva, 2006 150
Travel Related Knowledge Models
ESWC, Budva, 2006 151
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
ESWC, Budva, 2006 152
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)
ESWC, Budva, 2006 153
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
ESWC, Budva, 2006 154
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
ESWC, Budva, 2006 155
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."
ESWC, Budva, 2006 156
Available Functions (2/3)
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. "
ESWC, Budva, 2006 157
Available Functions (3/3)
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
ESWC, Budva, 2006 158
References
• The central location where WSMO work and papers can be found is WSMO Working Group: http://www.wsmo.org
• WSMO languages – WSML Working Group: http://www.wsml.org
• WSMO implementation – WSMX working group : http://www.wsmx.org– WSMX open source can be found at: https://sourceforge.net/projects/wsmx/
ESWC, Budva, 2006 159
Wrap-up, References & Acknowledgements
ESWC, Budva, 2006 160
Tutorial Wrap-up
• The targets of the presented tutorial were to:– Understand aims & challenges within Semantic Web Services – Understand WSMO approach to Semantic Web Services – Present WSMX and IRS - future Web Service based IT middlewares
• design and architecture • components design
=> You should now be able to assess WSMO technologies and utilize these for your future work
ESWC, Budva, 2006 161
References
• The central location where WSMO work and papers can be found is WSMO Working Group: http://www.wsmo.org
• WSMO languages – WSML Working Group: http://www.wsml.org
• WSMO implementation – WSMX working group : http://www.wsmx.org– WSMX open source can be found at: https://sourceforge.net/projects/wsmx/
ESWC, Budva, 2006 162
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.
• [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.
ESWC, Budva, 2006 163
References
• [Bussler, 2003] Bussler, C. (2003): B2B Integration. Berlin, Heidelberg: Springer.
• [Cimpian and Mocan, 2005] Emilia Cimpian, Adrian Mocan: WSMX Process Mediation Based on Choreographies, 1st International Workshop on Web Service Choreography and Orchestration for Business Process Management (BPM 2005), September 2005, Nancy, France
• [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.
• [Haller et al., 2005] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler. WSMX - A Semantic Service-Oriented Architecture. International Conference on Web Services (ICWS 2005), July 2005.
• [Kerrigan, 2006] Mick Kerrigan: Web Service Selection Mechanisms in the Web Service Execution Environment (WSMX), Proceedings of the 21st Annual ACM Symposium on Applied Computing (SAC), April, 2006, Dijon, France
• [Mandell and McIIraith, 2003] Daniel J. Mandell and Sheila A. McIlraith. Adapting BPEL4WS for the Semantic Web: The Bottom-Up Approach to Web Service Interoperation. In Proceedings of the Second International Semantic Web Conference (ISWC2003)
• [Mocan and Cimpian, 2005] Adrian Mocan, Emilia Cimpian: Mapping Creation Using a View Based Approach, 1st International Workshop on Mediation in Semantic Web Services (Mediate 2005), December 2005, Amsterdam, Netherlands
ESWC, Budva, 2006 164
References
• [Domingue et al., 2004] Domingue, J. Cabral, L., Hakimpour, F., Sell D., and Motta, E., (2004) IRS-III: A Platform and Infrastructure for Creating WSMO-based Semantic Web Services WSMO Implementation Workshop (WIW), Frankfurt, Germany, September,2004
• [Feier et al., 2005] C. Feier, A. Polleres, R. Dumitru, J. Domingue, M. Stollberg, and D. Fensel. Towards intelligent web services: The web service modeling ontology (WSMO). International Conference on Intelligent Computing (ICIC), April 2005.
• [Fensel, 2001] Dieter Fensel, “Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce”, Springer-Verlag, Berlin, 2001.
• [Fensel and Bussler, 2002] Fensel D. and Bussler C., "The Web Service Modeling Framework, WSMF," Electronic Commerce Research and Application, vol. 1, 2002
• [Fensel, 2004] D. Fensel: Triple Space computing - Semantic Web Services based on persistent publication of information. In Proceedings of IFIP International Conference on Intelligence in Communication Systems, Pages 43-53, Bangkok, Thailand, November 2004.
• [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.
ESWC, Budva, 2006 165
References
• [Haselwanter et al., 2005] 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.
• [Keller et al., 2004] Keller, U.; Lara, R.; Polleres, A. (Eds): WSMO Web Service Discovery. WSML Working Draft D5.1, 12 Nov 2004.
• [Keller et al., 2005] Keller, U.; Lara, R.; Lausen, H.; Polleres, A.; Fensel, D.: Automatic Location of Services. In Proc. of the 2nd European Semantic Web Symposium (ESWS2005), Heraklion, Crete, 2005.
• [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.
• [Kiffer et al., 2004] M. Kifer, R. Lara, A. Polleres, C. Zhao, U. Keller, H. Lausen and D. Fensel: A Logical Framework for Web Service Discovery. Proc. 1st. Intl. Workshop SWS'2004 at ISWC 2004,Hiroshima, Japan, November 8, 2004, CEUR Workshop Proceedings, ISSN 1613-0073
• [Li and Horrocks, 2003] Lei Li and Ian Horrocks. A software framework for matchmaking based on semantic web technology. In Proc. of the Twelfth International World Wide Web Conference (WWW 2003), 2003
• [Paolucci et al., 2002a] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, Katia Sycara; Importing the Semantic Web in UDDI. In Proceedings of Web Services, E-business and Semantic Web Workshop, 2002
• [Paolucci et al., 2002b] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, Katia Sycara; "Semantic Matching of Web Services Capabilities." In Proceedings of the 1st International Semantic Web Conference (ISWC2002), 2002
ESWC, Budva, 2006 166
References
• [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.
• [Preist, 2004] Preist, C.: A Conceptual Architecture for Semantic Web Services. In Proceedings of the 3rd International Semantic Web Conference (ISWC 2004), 2004, pp. 395 - 409.
• [Pollers et al., 2005] Axel Polleres, Holger Lausen, Jos de Bruijn and Dieter Fensel. WSML - A Language Framework for Semantic Web Services. W3C Workshop on Rule Languages for Interoperability, April 2005.
• [Stencil Group] - www.stencilgroup.com/ideas_scope_200106wsdefined.html
• [Stolberg et al., 2004] Stollberg, M.; Keller, U.; Fensel. D.: Partner and Service Discovery for Collaboration on the Semantic Web. Proc. 3rd Intl. Conference on Web Services (ICWS 2005), Orlando, Florida, July 2005.
• [Stolberg et al., 2005] M. Stollberg, E. Cimpian, and D. Fensel. Mediating Capabilities with Delta-Relations. In Proceedings of the First International Workshop on Mediation in Semantic Web Services, co-located with the Third International Conference on Service Oriented Computing (ICSOC 2005), Amsterdam, the Netherlands, 2005.
• [Stollberg et al., 2006] Michael Stollberg, Emilia Cimpian, Adrian Mocan, Dieter Fensel: A Semantic Web Mediation Architecture, Canadian Semantic Web Working Symposium (CSWWS 2006), June 2006, Québec city, Canada
• [Zaremba and Bussler, 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.
ESWC, Budva, 2006 167
Acknowledgements
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.
The WSMO working groups are funded by the European Commission under the projects ASG, DIP, Knowledge Web, SEKT, SemanticGov, SWWS, AKT and Esperonto; by Science Foundation Ireland under the DERI-Lion project; and by the Austrian government under the FIT-IT program