Sws Han

Semantic Web Services:
Challenges and Research Trend

July, 2009

Prof. Sung-Kook Han
Semantic Technology Research Grou
Won Kwang Universuty

Agenda

Semantic Web Semantic Services

Ontology
Semantic Technology

Web Documents Services / Agents

Static Dynamic
Information Resources Active Resources
2010-01-28 skhan@wku.ac.kr page 2

Agenda

 Review of Semantic Web Services Technologies
 Web Services
 Semantic Web Services

 Approaches towards Semantic Web Services
 OWL-S Coalition
 Semantic Web Service Initiative
 WSMO / WSML / WSMX

 Discussion on Semantic Web Services
 Future Trend
 Cloud Computing

2010-01-28 skhan@wonkwang.ac.kr page 3

Evolution of Web Technologies

Web Applications
Web Pages
Applet XML
Servlet SOAP
JSP/ASP WSDL
Web Services
JDBC/ODBC UDDI

HTTP
HTML AJAX Services
URL Folksonomy
Semantic Web
Web 2.0
StyleSheet RSS / ATOM

XML
RDF/S Semantic Web
Content OWL
Information
Knowledge

Web Services

Services Description
Location Communication
Web Services
Web Services
UDDI, WSDL, SOAP
UDDI,WSDL,SOAP

Semantic Web
Dynamic Web Services
Services
UDDI,WSDL,SOAP

Semantic
Integration

Web Services
Semantic Web
Static UDDI,WSDL,SOAP

Resource
ontology
Current Web
Web Services
URL, HTML, HTTP
UDDI,WSDL,SOAP
Information Knowledge


Web Services

Loosely coupled, reusable software components that semantically
encapsulate discrete functionality and are distributed and programmatically
accessible over standard Internet protocols.

 Loosely coupled
 Loosely coupled systems require a much simpler level of coordination and allow for more
flexible reconfiguration.
 Reusable software components
 Web services are service components that allows developers to reuse the building blocks of
a system created by others to assemble and extend them in new ways.
 Semantically encapsulate discrete functionality
 Web services are self-contained, self-describing modular applications.
 Accessed programmatically
 Web services certainly will be incorporated into other Web services and applications.
 Distributed over the Internet
 Web services make use of existing, ubiquitous transport protocols like HTTP.


Web Services Architecture

Service Broker
Service Registration:
UDDI
Web Services
Repository

 Find  Publish
Service Description:
WSDL

Service Service
Requester Provider
 Bind
Service Messaging:
SOAP


Web Services Architecture

Service Location http://uddi.microsoft.org
Service Interface

 Publish Services
Search Service

Return URL

Service Requester  Request WSDL Service Provider
Application Application
Return WSDL
A
Web Service-B B
Proxy C
 Request Service

WSDL
Return Service Result
SOAP Engine SOAP Engine


Example: On-Line Bookstore

Customer

Amazon.com
Amazon-Korea

Enterprise
Bank


Example: Virtual Travel Agency

Customer
Virtual
Travel
Hotel Agency

Airline Ticket Enterprise
Rent a Car

Core Technologies for Web Services

 XML (Extensible Markup Language): the basic foundation on which Web services
are built provides a language for defining data and how to process it. XML represents
a family of related specifications published and maintained by the World Wide Web
Consortium(W3C)and others.

 WSDL (Web Services Description Language): an XML-based technology, defines
Web services interfaces, data and message types, interaction patterns, and protocol
mappings.

 SOAP (Simple Object Access Protocol): a collection of XML-based technologies,
defines an envelope for Web services communication ─ mappable to HTTP and other
transportsㅡand provides a serialization format for transmitting XML documents over
a network and a convention for representing RPC interactions.

 UDDI (Universal Description, Discovery, and Integration): a Web services registry
and discovery mechanism, is used for storing and categorizing business information
and for retrieving pointers to Web services interfaces

skhan@wonkwang.ac.
Page 12 2010-01-28
kr

SOAP Message

SOAP Message The complete SOAP Message

HTTP Headers Standard HTTP and SOAP HTTP Headers

SOAP Envelope <Envelope> encloses payload

SOAP Header <Header> encloses headers
Headers Individual headers

<Body> contains SOAP
SOAP Body
Message Name & Data
Message Name & Data XML Encoded SOAP
Message Name & Data


Message Exchange

(1) message
 One-way Client Webservice

(1) request
 Request-Response Client Webservice
(2) response

(1) message
 Solicit-Response Client Webservice
(2) correlated message

(1) message
 Notification Client Webservice


WSDL

 XML document for describing Web Services
WSDL specification
 Input and output data structures
• Includes or refers to XML Schema type information
 Method signatures abstract part
 Protocol bindings (HTTP, SMTP etc.) types
 Location of the service
messages
 Document can be stored in UDDI registry operations
or served from the provider server
port types
 Typically generated by a tool
 xrpcc in Java Web Services Developer Pack
concrete part
bindings

services and
ports


WSDL
Interface : What

Support
PortType Operation

Format and How to Input/Output
protocol invoke

Access Binding
How to
Message
encode
specification

implement

provide
Port Service

Endpoint : Where

UDDI

 Universal Description, Discovery, and Integration
 Specification to Publish & Discover Web Services
 Shared Distributed Registry on the Web
 Analogy: Universal Phone Book
 UDDI enables three basic functions:
 Publish function – how a Web Service registers
 Find function – how a client finds a Web Service
 Bind function – how the client connects and interacts with a Web Service

Name of Business
White Page Contact Information
Description of the Company

Business Classification Information
Based on NAICS, UNSPSC, or
Yellow Page Geographical Index
List of Products (multiple entries)

Technical Information about services
Green Page Example: business processes, binding
info, etc.

UDDI Registry


Service Finder

http://demo.service-finder.eu/index


Web Service Composition

Workflow = Automation of a business process, in whole or part,
during which documents, information or tasks are passed from one
participant to another for action, according to a set of procedure
rules (W
(WfMC)
B

A N1 E N2 F

Organization A Organization B Organization C
+
10101011
C D
t1 + t7 t8
t5 t6

t2 t3 t4

Set_Data DB_Access Manager
Lab Tech GET_ Seq

DB_Access
Lab Tech II


Workflow
Application
Architecture
Consumer

Process

Services and
Messages

Service
Architecture
Provider

Component
Architecture
Component
Architecture


Web Services Choreography & Orchestration
 Web Services orchestration
 implies the presence of a single agent that controls and coordinates interactions between
and among multiple Web Services
 Web Services choreography
 involves non-executable descriptions of observable behavior of Web Services through the
definition of observable message exchanges between a collection of services

Web Web
Service Service

Collaboration

Web Process flow Web
Web Web
Service Service
Service Service

Web Services orchestration Web services choreography


Choreography & Orchestration

 Travel Agency example
When the service is When the service
requested requests

Date, Time
Date
Hotel Service
Hotel
Time
Error
Flight, Hotel
Travel Agenc
y Date, Time
Error
Service
Confirmation Flight
Flight Service
Error

 Choreography = how to interact with the service to
consume its functionality
 Orchestration = how service functionality is achieved
by aggregating other Web services

23

WSBPEL

 Business Process Execution Language for Web Services

 WSBPEL replaces WSFL and XLANG by combining and
extending the functions of both

 Describe business process involving many WS

 XML-based workflow definition language

 Standard for Web Service composition language


WSBPEL Elements

 Partner
 the different parties that interact with the business process
 Container
 WSDL messages that are received from or sent to partner
 faultHandlers
 the ways to handle and recover from errors in businesses.
 Compensation
 allowing the process designer to implement compensation actions for certain irreversible
errors in business
 Activities
 the actions that are being carried out within a business process
<receive> <reply> <invoke> <assign> <throw> <terminate> <wait> <empty>
<sequence> <switch> <while> <pick>
<flow> <scope> <compensate>
 Correlation
 figuring out which instance an incoming message is meant for


WSBPEL Core Concepts
Web Service Partner (Service) Linking
Implementation <partnerLink>,
<receive>, <reply> defined
<partnerLinkType>

implements
defined
Correlations
<correlationSet>,
Process Definition Web Service invocation
<correlationSets>,
<process> <invoke>
<property>, Iden-
<propertyAlias> tified

comprise uses defined

Sequencing and Flow
Scopes Control uses Non deterministic
<scope>, <faulthandler>, <sequence>, <flow>, support
<compensationhandler>, Contained <while>, <switch>, <pick>, <onMessage>,
<eventhandler> in <onAlarm>
<link>

uses
uses

Fault Handling Variable Definition and
<catch>, <compensate>, Assignment
<throw> <variable>, <assign>


Web Services and Security

 When Web Services-based exchanges branch out beyond an organization’s
firewall and span across organizations, security becomes a much larger factor
than it is for exchanges that are behind the firewall

 Security involves multiple requirements, such as:
 Integrity: Ensuring that messages have not been tampered with en route or otherwise
 Non-Repudiation: Ensuring that a party to a contract or communication cannot deny the
authenticity of their signature or the fact that they originated a message
 Authentication/Identity Management: Requiring proof of identity in a Web-based
transaction
 Authorization: Controlling access privileges to resources
 Confidentiality: Protecting information from interception during transmission, and
potentially afterward


Web Services and Security

Specification Satisfies Security Requirement
OASIS Web Services Security  Integrity (message-level)
 Non-Repudiation (message-level)
 Confidentiality (message-level)
OASIS SAML (Security Assertion  Authentication
Markup Language)  Identity Management (Version 2.0)
The Liberty Alliance  Identity Management
WS-Federation (Web Services  Identity Management
Federation Language)

WS-Trust (Web Services Trust  Managing trust relationships
Language)
WS-SecureConversation (Web Services  Integrity (session-level)
Secure Conversation Language)  Non-Repudiation (session-level)
 Confidentiality (session-level)
XACML (Extensible Access Control  Authorization/Access Control
Markup Language)


Service implementation - logical

A service is a software component designed and built in order to be reused
by another software component in different execution contexts.

Provides service identification, definition of
Service Interface parameters, and conventions concerning
passing the service results back to the consumer

Service content provides business logic
Service such as a stateless computation
Content
Services might need to be able to distinguish
messages from individual consumers and also
be able to correlate those messages
into meaningful conversations.

Author: Peter Campbell, ANZ Banking Group Australia
Source: Applying EA Roadmapping: An SOA Roadmap, Cutter Consortium

2010-01-28 skhan@wonkwang.ac.kr 29

Service-oriented Architecture (SOA)

1. Point to point systems 2. Message-based middleware with integration broker
Partner
Partner App B App D Warehouse
App A
App A
(J2EE) Warehouse
App B Sales
(.Net) App C Service Bus / MOM
Sales
App C
App D
(.Net)
(J2EE) Adapter
Adapter
Shared
Legacy System Legacy
Legacy System
Application
Application
Finance
Finance

Service Oriented Architecture & Enterprise Service Bus
Business

Consumer
Custom Package Business Rules
Process
applications applications Engine “Above the bus”
Orchestration

HTTP Enterprise Service Bus
Internet Service

Provider
Routing Transformation (Process)
Services Adapter Adapter
orchestration
Legacy Shared “Below the bus”
System System
skhan@wonkwang.ac.
30 2010-01-28
kr

SOA Layers

Composite Business Service Service
Services

Composite Application
Enterprise Service Bus

Business Service Bus

Service Service Service Service Service Service
Implementation-Based
and Utility Services

Other
Service Enablement Service
Providers
Providing Resources Internal and External Resources
and Implementations


Service / Business Process

Business Process “Open account for customer”

Presentation – user interface

Business Process
Orchestration

Business Get Locate Add
Services customer account account to Coarse Grained
details type customer

Service Orchestration
(Process Orchestration)

Lookup Create Fine
Locate Check Retrieve
Technical customer customer
account
account
Customer- Grained
Services type Account
record status details
table record

skhan@wonkwang.ac.
32 2010-01-28
kr

Service / Business Process Composition

BEA WebLogic Platform

skhan@wonkwang.ac.
33 2010-01-28
kr

Business Process Standards

skhan@wonkwang.ac.
34 2010-01-28
kr

Web Services and SOA
 SOA can be implemented without Web services, and Web services can be used for non-
SOA (e.g. RPC) interactions. However, Web services delivers key standards for
implementing SOA.
 The WS-* family scales to meet integration challenges intra-enterprise (enterprise
application integration [EAI]) and inter-enterprise (business to business [B2B]).
 XML is an ideal candidate for loosely coupled inter-application data sharing. XML is not
self-describing, but XML Schema can be be used to constrain message layout and content.

SOA
“The architecture”
 Services architecture  Web services specs  RPC interactions
 Service contract  WSDL  Binary XML
 Message based  SOAP & XML
 Service directory  UDDI Web services
 Protocol independent  HTTP
 Coarse grained & document  Doc literal binding “The plumbing”
centric
 Process orchestration (BPEL)

You don't have SOA until you build/buy Web Services is the stack of standard web technologies
services and compose them to implement required at both consumer and provider ends to implement the
business functionality. pipe for shipping XML messages between them.


Standards Stack for Web Services


Trend in Web Services


WS standards: Lack of Semantics!

Syntax only!

Problem: Enable interoperability by using the same format, but still discovery,
combinability only syntax based, no way to describe functionality.


Semantic Web Services

Ontology
Semantic
Model Semantic
Based
Resources Web System

Semantic
Web
Services
Distributed
Processing
Distributed Model Web
Services EAI
Services

Service


Semantic Enabled Web Services

Semantics


Semantic Web Services (SWS)

Three characteristics of SWS:

1. Enhance
Web Service usage by adding semantics for
automation
 Web service aspect

2. Use
an ontology as the underlying model for the Web
Service description
 Ontology aspect

3. Support
ontology reuse to build a Web of Links
 Semantic Web aspect

Tackling Semantic Interoperability…

Publication Make available the description of the capability of a service

Discovery Locate different services suitable for a given task
Choose the most appropriate services among
Selection
the available ones
Composition Combine services to achieve a goal
Solve mismatches (data, protocol, process) among
Mediation
the combined Web services
Execution Invoke services following programmatic conventions

Monitoring Control the execution process
Provide transactional support and undo or mitigate
Compensation
unwanted effects
Replacement Facilitate the substitution of services by equivalent ones


Semantic Web Services Lifecycle

Qos
Description

Security

Publication

Enactment
Discovery

Engagement


Building on Existing Web Services Standards

OWL-S
OWL-S
Service
(Grounding)
Matching
XML

WSDL UDDI

SOAP

HTTP


OWL-S Objectives

 Provide:
 An upper ontology for describing properties & capabilities of agents & (Web) services in an
unambiguous, computer interpretable markup language.
 Supporting ontologies for describing service types, security definitions, execution
parameters, access and invocation characteristics.
 Guidelines for advertising, modeling and requesting services.
 Infrastructure to support the location and invocation of services.

 Model services using DAML syntax and description-logics
 Achieve semantic interoperability through tight coupling with Semantic Web
standards.
 Automate:
 WS Discovery
 WS Invocation
 WS Selection, Composition & Interoperation
 WS Execution Monitoring


OWL-S Upper Ontology

• Capability specification
• General features of the Service
• Quality of Service
• Classification in Service
taxonomies

• Mapping to WSDL
• communication protocol (RPC, HTTP, …)
• marshalling/serialization • Control flow of the service
• transformation to and from XSD to OWL • Black/Grey/Glass Box view
• Protocol Specification
• Abstract Messages


Service Profiles

 Service Profile
 Presented by a service.
 Represents
• what the service provides
 Two main uses:
• Advertisements of Web Services capabilities (non-functional
properties, QoS, Description, classification, etc.)
• Request of Web services with a given set of capabilities


OWL-S Service Profile
Non Functional Properties

Functionality
Description

Service Model

 Process Model
 Describes how a service works: internal
processes of the service
 Specifies service interaction protocol
 Specifies abstract messages: ontological type
of information transmitted
 Facilitates
 Web service invocation
 Composition of Web services
 Monitoring of interaction


OWL-S Service Model (Overview)


Process Model Control Constructs
 Four types of control construct
 Sequential, concurrent, conditional, and iteration
 Test and conditional constructs used to control workflow


Composite Process Example (Sequence)

<rdfs:Class rdf:ID="BookFlight">
<rdfs:subClassOf rdf:resource="#CompositeProcess" />
<rdfs:subClassOf rdf:resource="http://www.daml.org/Process#Sequence" />
<daml:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="http://www.daml.org/Process#components" />
<daml:toClass>
<daml:subClassOf>
<daml:unionOf rdf:parseType="daml:collection">
<rdfs:Class rdfs:about="#GetFlightDetails" />
<rdfs:Class rdfs:about="#GetContactDetails" />
<rdfs:Class rdfs:about="#ReserveFlight" />
<rdfs:Class rdfs:about="#ConfirmReservation" />
</daml:unionOf>
</daml:subClassOf> Composite Process
</daml:toClass>
BookFlight
</daml:Restriction>
</daml:subClassOf>
</rdfs:Class>

Get Flight Get Contact Confirm
Reserve Flight
Details Details Reservation

Sequence Sequence Sequence

Service Grounding

 Service Grounding
 Provides a specification of service access
information.
 Service Model + Grounding give everything
needed for using the service
 Builds upon WSDL to define message
structure and physical binding layer
 Specifies:
 communication protocols, transport
mechanisms, agent communication languages,
etc.


Mapping OWL-S / WSDL 1.1
 Operations correspond to Atomic Processes
 Input/Output messages correspond to Inputs/Outputs of processes

OWL-S
Process Model DL-based Types

Atomic Process Inputs / Outputs

Operation Message

Binding to SOAP, HTTP, etc.

WSDL

Web Services vs. Semantic Web Services

Items Web Services Semantic Web Services
Service Requestor Human Agents

UDDI May not be necessary
Service Publication
Description Language WSDL( Service taxanomy) Ontology-based language
Ontology-based
Service Descriptions Operations, messages and binding
Goals and Capabilities
Message Exchange Syntactic-based Semantic-based
Core technologies UDDI/WSDL/SOAP Ontology and Reasoning
Service Composition Passive using WSBPEL Goal-driven approach by agents
choreography /
Passive using WSBPEL Automatic generation by BPM
orchestration
Heterogeneity Passive Semantic mediation

Service Discovery/Selection Search repository by human Automatic discovery by agents

Transportation Protocols SOAP SOAP, and other XML protocols


Overview: Semantic Web Services Research

Ontology

W3C OWL
OWL-S
SWSI
(USA) Coalition

STI2 WSMF WSMO
(EU)

Web Services


Semantic Web Services Framework

Semantic Web Services Language
Semantic Web Services Architecture (SWSA)
(SWSL)

SWSL-FOL SWRL-Rules
Dynamic Service
Lifecycle and Resource
Discovery
Management Services

Semantic Web
Service Engagement Community
Support Services
Semantic Web Services Ontology
(SWSO) Service Process
Enactment and Cross-Cutting Issues
FLOWS ROWS Management


Semantic Web Services Framework (SWSF)

general purpose language designed to
Semantic Web Service Language (SWSL) address the needs of Semantic Web Services
• based on FOL
SWSL–FOL • used to express the formal characterization
(ontology) of Web Service concepts

• based on logic programming
SWSL–Rules • used to support the use of the Service
ontology in reasoning and execution
environments

Semantic Web Service Ontology (SWSO) conceptual model and axiomatization

FLOWS (First-Order Logic Ontology for Web Services)
• axiomatized ontology of service ontology learned from OWL-S, PSL

ROWS (Rules Ontology for Web Services)
 a (partial) translation of FLOWS into SWSL-Rules

The Layered Structure of SWSL-Rules

 a rule-based language with non-monotonic semantics.
 to provide support for a variety of tasks that range from service profile
specification to service discovery, contracting, policy specification, and so on.

Courteous Nonmon LT

NAF

Reification

Equality Mon LT

HiLog

Frames
Horn

The Layered Structure of SWSL-Rules

 Core language: pure Horn subset of SWSL-Rules.
 Monotonic Lloyd-Topor (Mon LT) extension
 permits disjunctions in the rule body and conjunction and implication in the rule head.
 NAF extension
 allows negation in the rule body, which is interpreted as negation-as-failure.
 Non-Nonotonic Lloyd-Topor extension (Non-Non LT)
 permits quantifiers and implication in the rule body.
 Courteous rules extension
 introduces two new features: restricted classical negation and prioritized rules.
 HiLog extension
 allowing variables to range over predicate symbols, function symbols, and even formulas.
 Despite second-order features, the semantics of HiLog remains first-order and tractable.
 Frames extension
 introduces the most common object-oriented features, such as the frame syntax, types, and
inheritance.
 Reification extension
 provides a mechanism for making objects out of a large class of SWSL-Rules formulas,
which puts such formulas into the domain of discourse and allows reasoning about them.


SWSL-FOL

 is used to specify the dynamic properties of services, namely, the processes that they are
intended to carry out
 a specification language for SWSO, and specialized reasoners will be used to reason with
the service ontology
 a common platform to support semantic interoperability among the different first-order
based service ontologies, such as OWL-S

 All of the above layers have been implemented in one system or another.
 FLORA-2: all layers except Courteous rules and Non-Monotonic Lloyd-Topor.
 SweetRules: Courteous extensions
 Ontobroker: Non-Monotonic Lloyd-Topor and frames.


The Layers of SWSL-FOL

SWSL-FOL+HiLog

SWSL-FOL+Equality SWSL-FOL+Frames

SWSL-FOL

HiLog
Equality
Mon LT

Frames
Horn


Semantic Web Services Ontology (SWSO)

 SWSO: Two ontologies

 FLOWS
 First-order Logic Ontology for Web Services. FLOWS
 also known as SWSO-FOL
 First-order logic version of the Semantic Web Services Ontology.
 An extension of the PSL-OuterCore ontology, to incorporate the fundamental aspects of
(web and other electronic) services, including service descriptors, the service activity, and
the service grounding.

 ROWS
 Rules Ontology for Web Services.
 ROWS, also known as SWSO-Rules
 Rules-based version of the Semantic Web Services Ontology.
 created by a relatively straight-forward, almost faithful, transformation of fundamental
aspects of (web and other electronic) services, including service descriptors, the service
activity, and the service grounding.
 Enables a rules-based specification of a family of services, including both the underlying
ontology and the domain-specific aspects.


SWSO: FLOWS

 First-order Logic Ontology for Web Services
 Representational Desiderata
 Model-theoretic semantics
 Primitive and complex processes are first-class objects
 Taxonomic representation
 Leverages existing service ontologies (OWL-S)
 Embraces and integrates with existing and emerging standards and research (BPEL, W3C
choreography, etc.)
 Explicit representation of messages and dataflow (cf. W3C choreography, behavioral
message-based signatures, etc.)
 Captures activities, process preconditions and effects on world.
 Captures process execution history.

 FLOWS comprises:
 Service Descriptors
 Process Model
 Grounding


SWSO: FLOWS

FLOWS

Service Process
Grounding
Descriptors Model

Control Ordering Occurrence State Exception
FLOWS-Core
Constraints Constraints Constraints Constraints Constraints


Service Descriptors

 Service Name: name(service,service_name)
 Service Author: author(service,service_author)
 Service Contact Information: contact(service,contact_info)
 Service Contributor: contributor(service,service_contributor)
 Service Description: description(service,service_description)
 Service URL: url(service,service_URL)
 Service Identifier: identifier(service,service_identifier)
 Service Version: version(service,service_version)
 Service Release Date: releaseDate(service,service_release_date)
 Service Language: language(service,service_language)
 Service Trust: trust(service,service_trust)
 Service Subject: subject(service,service_subject)
 Service Reliability: reliability(service,service_reliability)
 Service Cost: cost(service,service_cost)


Process Model

 Extension of PSL, a generic ontology for processes
 the structured notion of atomic process as found in OWL-S
 infrastructure for specifying various forms of data flow

Module Major Concepts
Service
AtomicProcess
FLOWS-Core composedOf
message
channel
Split
Sequence
Unordered
Control Constraints Choice
IfThenElse
Iterate
RepeatUntil
Ordering Constraints OrderedActivity
Occurrence Constraints OccActivity
State Constraints TriggeredActivity
Exception Constraints Exception


Process Modeling Constructs


SWSO: ROWS

 Rules Ontology of Web Services
 Partial translation of FLOWS into SWSL- Rules
 Features of ROWS
 Since SWSL-Rules is inherently less expressive than SWSL-FOL, some axioms in ROWS
are weakened with respect to the corresponding axiom in SWSL-FOL.
 Top-level Classes of ROWS
 Correspond to similar to classes of FLOWS
 Service, Process, AutomicProcess, Message, Channel

prefix xsd = "http://www.w3.org/2001/XMLSchema".
Service[
name *=> xsd#string,
author *=> xsd#string,
contactInformation *=> xsd#string,
contributor *=> xsd#string,
………………………….
identifier *=> xsd#string,
subject *=> xsd#string,
trust *=> xsd#string,
reliability *=> xsd#string,
cost *=> xsd#string
].

Semantic Web Service Architecture (SWSA)

 Mission of the Semantic Web Services Initiative Architecture committee
(SWSA): Development of architectural and protocol abstractions forming a
reference architecture to support Semantic Web Service technologies on the
World Wide Web
 extends the Web Services Architecture developed by the Web Services Architecture
Working Group of W3C
 make use of terms and concepts in a conceptual architecture for semantic web services that
extends the Web Services WG Architecture.
 is based in part on the layered Semantic Web Architecture as proposed by Tim Berners-Lee
 is taken from the OWL-S Coalition, WSMO Working Group, the open grid services
architecture and the METEOR-S project

 abstract protocols for interactions between clients and Semantic Web Services
and other support services that may be needed in some contexts to fulfill the
basic requirements of the proposed architecture
 support functions to be accomplished by Semantic Web agents (service
providers, requestors, and middle agents).


SWSA Architectural Considerations

 Dynamic Service Discovery:
 The capability of a software agent, through interaction with other agents, to identify candidate services for
particular objectives.

 Service Engagement - Negotiation and Contracting:
 The capability of two agents to mutually formulate, by offline or online interaction, a shared agreement
on the terms of performance of a service to be provided by one agent for the other.

 Service Process Enactment and Management:
 The capability to dynamically select and invoke or interact with services to achieve some defined
objective.

 Semantic Web Community Support Services:
 Capabilities associated with sharing semantic descriptions, ontologies and ontology mappings, and
service catalogs within and across communities.

 Semantic Web Service Lifecycle and Resource Management Services:
 The capability to spawn, allocate, manage and report on the life status of services, computational host
platforms and storage facilities for Semantic Web Services.

 Cross-cutting Issues:
 Semantic representations of two kinds of service quality meta-properties may be important during
discovery of appropriate services, may appear in service agreements, and may be monitored during
execution.

Service Interaction Process of SWSA

• 발견 (Service Discovery) 단계
서비스
• 약속 (Service Engagement) 단계
서비스
• 처리 규약 및 관리 (Service Process Enactment and Management)
서비스
• 웹 지원 관련 서비스 (Semantic Web Community Support Services)
시맨틱
• 웹 서비스 생명주기 및 자원관리 서비스 (Semantic Web Service Lifecycle
시맨틱
and Resource Management Services)
• 부가적 요구사항 (Cross-cutting Requirement)

Negotiation-Commitment Process


Main Principles of WSMF

Automatic finding and Diverse heterogeneous Diverse heterogeneous
comparing data format business logic

Machine-Processible Ontology
Mediation
Semantics Technology

Two complementary principles

 Strong de-coupling
- information hiding : private process and public process
- scalable interaction for coupling process

 Strong mediation
- mediate different terminologies / different interaction styles


WSMO Framework

WSMO WG  Conceptual Model of Web Services

WSML WG WSMX WG
 Languages for WSMO  Run-Time
Execution Environment
∙ WSMO Working Group : 시맨틱 웹서비스 모델 연구
∙ WSML Working Group : 시맨틱 웹서비스 언어 연구
Formal Language
Rule-base Language
∙ WSMX Working Group WSMO
for : 시맨틱 웹서비스 실행 환경 연구


WSMO Design Principles

 Web Compliance
 inherits the concept of URI (Universal Resource Identifier) for unique identification of resources
 adopts the concept of Namespaces for denoting consistent information spaces, and supports XML and
other W3C Web technology recommendations, as well as the decentralization of resources.
 Ontology-Based
 used as the data model throughout WSMO, meaning that all resource descriptions as well as all data
interchanged during service usage are based on ontologies.
 semantically enhanced information processing as well as support for interoperability
 Strict Decoupling
 is specified independently without regard to possible usage or interactions with other resources.
 Centrality of Mediation
 addresses the handling of heterogeneities that naturally arise in open environments.
 Ontological Role Separation
 differentiates between the desires of users or clients and available Web services.
 Description versus Implementation
 differentiates between the descriptions of Semantic Web services elements (description) and executable
technologies (implementation).
 Execution Semantics -
 verify the WSMO specification, the formal execution semantics of reference implementations like
WSMX as well as other WSMO-enabled systems provide the technical realization of WSMO.
 Service versus Web service –
 A Web service is a computational entity which is able (by invocation) to achieve a goal. A service in
contrast is the actual value provided by this invocation.


Core Components of WSMO
 Ontologies
 consisted of concepts, relations, functions, axioms, instances, non-functional properties, imported
ontologies, and used mediators

 Web Services
 describe the functional properties for service discovery, invocation, composition, mediation,
compensation and…
 consisted of non-functional properties, imported ontologies, used mediators, capability and interfaces
 should have more than one capability

 Goals
 describe the required user’s goal of service.
 consisted of non-functional properties, imported ontologies, used mediators, requested capability and
requested interface

 Mediators
 mediation of structural, semantic, conceptual mismatches
 consisted of non-functional properties, imported ontologies, source comjponent, target comjponent and
mediation service
 4 types of mediators


WSMO – the Web service element


WSML

 WSML provides a formal grounding for the conceptual elements of WSMO,
based on:
 Description Logics
 Rule Languages
 First-Order Logic
 Many current Semantic Web languages have
 undesirable computational properties
 unintuitive conceptual modeling features
 inappropriate language layering
• RDFS/OWL
• OWL Lite/DL/Full
• OWL/SWRL
 WSML aims to:
 Provide a Web Service Modeling Language based on the WSMO conceptual model
• Concrete syntax
• Semantics
 Provide a Rule Language for the Semantic Web


Web Service Modelling Language (WSML)

 Ontology / Rule Languages WSML
 WSML Core: efficiency and compatibility
 WSML DL: decidability, open world semantics Static Dynamic
 WSML Rule: efficient existing rule engines Aspects Aspects
 WSML Full: unifying language, theorem proving

 Languages for dynamics
 Transaction Logic over ASMs

WSML Full
 Mapping languages
 for dynamics (process mediation) WSML Rule WSML DL
 for data (data mediation) WSML Core
RDF (S)
XML
Unicode URI


Variants of WSML
 WSML-Core
 Based on the intersection of Description Logics and Datalog
 Semantics defined through OWL Lite-
 Has (frame-based) conceptual syntax and logical expression
syntax
 WSML-Flight
 Based on OWL Flight
• Basic meta-class facility
• Constraints
• Non-monotonic features (default negation)
 “Fixes” some of the mistakes in OWL, such as unintuitive
modeling constructs
 Preferred ontology modeling language
 WSML-Rule
 Based on Logic Programming with default negation and
F-Logic/HiLog syntactical extensions
 Preferred goal/web service modeling language
 WSML-DL
 Based on species of OWL
 WSML-Full
 Combining FOL with minimal models and non-
monotonicity


WSMO/WSML: Examples

 Concept example  Relation example
concept phoneNumber
nonFunctionalProperties relation hasRoute(ofType routeDescription, ofType route)
dc#description hasValue "concept of a nonFunctionalProperties
dc#description hasValue "Relation that holds between
phone number"
endNonFunctionalProperties a route description and a route"
endNonFunctionalProperties
countryCode ofType _string
areaCode ofType _string
number ofType _string  Instance example
instance myPhoneNumber memberOf phoneNumber
countryCode hasValue “43“
areaCode hasValue “664“
 Sub-concept example number hasValue “49322607“
concept mobilePhoneNumber subConceptOf
phoneNumber
nonFunctionalProperties
dc#description hasValue "concept of a
 Axiom example
axiom ValidInformationQuality
mobile phone number" definedBy
endNonFunctionalProperties forall {?x} (
mobileProvider ofType Provider ?x memberOf informationQualityType impli
es
?x[value hasValue “low“] or
?x[value hasValue “high“]).


WSMO/WSML: Examples
webService _"https://asg-platform.org/AttractionBooking/MobtelPhoneLocationService"
nfp
dc#title hasValue "MobtelPhoneLocationService"
dc#publisher hasValue "Mobtel“
dO#informQualityType hasValue "high"
endnfp
importsOntology _"https://asg-platform.org/AttractionBooking/domainOntology.wsml"
capability MobtelPhoneLocationServiceCapability
sharedVariables {?P}
precondition
definedBy
?P memberOf dO#phoneNumber.
postcondition
definedBy
?L memberOf dO#location
and
dO#hasLocation(?P,?L).
interface MobtelPhoneLocationServiceInterface
choreography MobtelPhoneLocationServiceChoreography
stateSignature
in
dO#phoneNumber withGrounding
ssWSDL#wsdl.interfaceMessageReference(MobtelPhoneLocationServicePortType/doIt/In)
out
dO#location withGrounding
ssWSDL#wsdl.interfaceMessageReference(MobtelPhoneLocationServicePortType/doIt/Out)
transitionRules
forAll{?P} with (?P memberOf dO#phoneNumber) do
add(?L memberOf dO#location and dO#hasLocation(?P,?L))
endForall


WSMX Architecture


WSMX Functionality

 Core Component: interactions between components (business logic of the system, events engine,
internal worklow engine...)
 Resource Manager: management of repositories to store definitions of any WSMO (Web Services,
goals, ontologies and mediators) and non-WSMO related objects for WSMX.
 Web Services Repository: Semantic Description of Web Services
 Goals repository: semantic description of general goals
 Ontology repository: ontologies to be stored in the registry describing semantics of particular domains.
 Mediator repository: mediators to be stored in the registry.
 Data repository :system data and any component specific data required for correct system execution.
 Service Discovery: provide functionality on matching of usable SWS with the goals.
 Goal-driven matching with the capability of Web Services and the user goal.
 Service Selection: Selection of the appropriate Web Services among the candidate services discovered
in Service Discovery
 variant selection strategies: “best”, “optimal”, and “first”
 Non-functional properties: cost, performance, geographical location, reliability, security, etc.
 Data and Process Mediator: Mediator when two entities that cannot communicate directly need to
interact.
 Communication Manager
 Choreography
 mediate between the requester's and the provider's communication patterns.
 provide the necessary means for a runtime analysis of two given choreography instances and to use Mediators to
compensate the possible mismatches that may appear,
 WSMT Web Service Modeling Toolkit (WSMT): framework for the rapid deployment of graphical
administrative tools


WSMX – Components


Core Standardization Initiatives in the Area of SWS

 OASIS Semantic Execution Environment TC
 Developing guidelines, justifications, and implementation directions for deploying Semantic
Web services in SOA
 www.oasis-open.org/committees/semantic-ex/

 W3C Semantic Annotations for Web Services Description Language Working
Group
 Develop a mechanism to enable annotation of Web services descriptions
 http://www.w3.org/2002/ws/sawsdl/


OWL-S VM

 OWL-S 기반 지원도구

 주요 3 모듈로 구성

 OWL-S 프로세스 모델 지원

 기본적인 추론 기능


IRS-III

Web Service
Publishing
Platforms Java Code

 UPML 기반의 문제해결 추론 시스템
Web Application
WSMX
J S  WSMO 생성 지원
a
v O SOAP
WS Publisher
Registry  편리한 서비스 공표 기능
Browser
Browser a A Handler

 서비스 발견과 실행
P SOAP
Handle
r Publisher OCML
Handler
Publishing
Clients
A  OWL-S 지원
P WSMO Library
Invocation
I Handler

Invocation IRS-III Server
Client

LispWeb Server

OWL(-S)
OWL(-S) Handler


SWWS Studio

 클라이언트용 통합개발환경

 WSMO 지원

 Visual Service Composer와 Service Editor
로 구성

 서비스 합성은 OWL-S만 지원


ODE-SWS

 개념 수준에서의 서비스 기술과 합성

 WebODE 서비스 확장

 언어 중립적


Web Service Semantics - WSDL-S

 A mechanism to augment WSDL descriptions with semantics
 a set of annotations can be created to semantically describe the inputs, outputs and operations of a Web
service.
 keeps the semantic model outside WSDL, making the approach agnostic to any ontology representation
language

 WSDL-S doesn’t provide a conceptual model and language for SWS
 a bottom up approach to SWS (annotating existing standards with metadata)
 Could be used as a grounding mechanism for SWS


METEOR-S

Development Discovery Composition  대규모 Workflow 관리 시스템을
시맨틱 웹서비스에 확장
WSDL-S Semantic Invoker & Web Process
Development Publishing & Testing Designer
Deployment Discovery  서비스 라이프 사이클 관리 가능
GUI
Core
 서비스 기술에 WSDL-S 이용
WSDL-S Publishing & Invoker Process Manager
API Discovery
Engine
Constraint Policy  서비스 저장고에 MWSDI 이용
Analyzer Optimizer Handler

Infrastructure
 본격적인 시맨틱 웹서비스 플랫폼

WSDL UDDI SOAP Inference ILP BPEL
Parser Registry Engine Engine Solver Engine

WSDL4J JWSDP Apache Jena/ Lindo BPWS
Axis Snobase 4J


SUPER Project

SUPER Project
The major objective of Semantics Used for Process management
within and between EnteRprises (SUPER) is to raise
Business Process Management to the business level,
where it belongs, from the IT level where it mostly resides now.
SUPER aims to create the technological framework constituting BPM enriched with machine
readable semantics by employing Semantic Web and Semantic Web Services accompanied by
universal reference implementation for mechanized BPM.

 SUPER Goals:
• To develop a comprehensive ontology stack that describes formal semantics for semantic
business processes
• To facilitate/support BPM tasks by semantic web service technology
• Semantic Business Process Composition
• Semantic Business Process Mediation
• To provide a holistic, semantically enriched modeling stack for BPM
• To provide “advanced” BPM functionality like semantic business process mining &
analysis


SUPER Modeling Stack


SUPER Semantic Service Bus


Different Approaches

Services
Description
STI2 approach
Location Communication

Web Services
Web Services Semantic Web
Dynamic Web Services
UDDI, WSDL, SOAP
UDDI,WSDL,SOAP Services
UDDI,WSDL,SOAP

Semantic SWSI approach
Integration

Current Web
Web Services Semantic Web
Web Services
Static
URL, HTML, HTTP
UDDI,WSDL,SOAP Ontology
UDDI,WSDL,SOAP

Resource

Semantic Interoperability

Framework Comparison

WSMO WG  Conceptual Model of Web Services

WSMO/WSML/WSMX

WSML WG WSMX WG
 Languages for WSMO  Run-Time
Execution Environment

Formal Language
Rule-base Language
for WSMO Semantic Web Services Language
(SWSL) Semantic Web Services Architecture (SWSA)

SWSL-FOL SWRL-Rules
Dynamic Service
Lifecycle and Resource
Discovery
Management Services

SWSI
Service Process Semantic Web
Enactment and Community
Management Support Services

Semantic Web Services Ontology
(SWSO)

Service Engagement Cross-Cutting Issues
FLOWS ROWS


Research Trend

Semantic Web Services Initiative (SWSI)
(WSMO/WSML/WSMX •••)

BPEL4WS Semantic Annotation
WSCL
Web process Advertisement
WSCI Discovery
XLANG Web process Selection
WSFL Composition
Time

••• Execution

SOAP Web service Semantic
OWL-S
WSDL Web service OWL
UDDI DAML-S
XML DAML
••• •••

Industry Research Academic Research

Sws Han

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Sws Han

Similar a Sws Han (20)

Más de Won Kwang University

Más de Won Kwang University (16)

Último

Último (20)

Sws Han