Semantic Ws

7/28/2019 Semantic Ws

1/34

12/25/20

C6

Semantic Web Services

Fall 2010

Distributed Systems

- Master in CS -

Technical University of Cluj-NapocaComputer Science Department

Web service

Definition

An application accessible to other applications over the Web.

W3C Definition

A software application identified by a URI, whose interfaces and bindings

are capable of being defined, described and discovered as XML artifacts. A

Web service supports direct interactions with other software agents using

XML-based messages exchanged via internet based protocols.


2/34

12/25/20

Why need Web service?

B2B Integration

Need a solution to the problem of automating processes across companies

Problems faced by B2B integration are similar to those faced by EAI but

the solutions are different

B2B Integration with Web Services

Everything is an autonomous and independent service

Based on open standards

Easier business process management

Easier integration

More flexible

Better and cheaper customer service

Service-Oriented Architecture (SOA)

UDDI

Provides a mechanism for clients to find Web

services

SOAP

Access of services over the Web

WSDL

An XML-based language used to define Web

services and describe how to access them


3/34

12/25/20

WSDL, SOAP

Web Service Description Language (WSDL)

W3C effort - WSDL 1.1, WSDL 2.0

Describes interface for accessing a Web Service

Interface (operations, inputs and outputs)

Access (protocol binding)

Endpoint (location of service)

Simple Object Access Protocol

W3C Recommendation http://www.w3.org/TR/soap12-part1/

XML based protocol for exchange of information in a decentralized,

distributed environment Binding, Communication aspects, Content

Universal Description, Discovery, and IntegrationProtocol (UDDI)

Registry for Web Services

UDDI data model

businessEntity

Information about the service provider (i.e. the providers name, description and

contact details)

businessService

Information about a Web service or a group of services (i.e. the service name,

description and an optional list ofbindingTemplates

)

bindingTemplate

Information about how and where to access a specific service

tModel

Usually a pointer to external technical specifications and service descriptions.

One common type of such descriptions is WSDL documents. Include also a

name and a description


4/34

12/25/20

Web Service usage process

Deployment

Create and publish Web service description

Discovery

Determine the services that satisfy a request

Composition

Combine services to achieve a complex goal

Selection

Choose most appropriate service among the available ones

Mediation

Solve incompatibilities (data, protocol, process) that hamper interoperation Execution

Invoke Web services following programmatic conventions

Deficiencies of WS technology

Current technologies allow usage of Web Services but offers

Only syntactical information descriptions

Syntactic support for discovery, composition and execution

Web Service usage, and integration needs to be inspected

manually

No semantically marked up content/services

No support for the Semantic Web

Current Web service technology stack failed to realize the

promise of Web Services


5/34

12/25/20

Semantic Web service (SWS)

SWS combine two technologies

Semantic Web technology

Ontologies as data model

Allow machine supported data interpretation

Web services technology

Discovery, selection, composition

Web-based execution of services

SWS represents integrated solution for realizing the vision of the

next generation of the Web

Semantic Web service framework

SWS frameworks need to integrate

Basic Web design principles

Design principles defined for the Semantic Web

Design principles for distributed, service-oriented computing on the Web

A SWS framework should answer to the following requirements:

Web compliance

Ontology-based

Strict decoupling

Centrality of mediation

Ontological role separation

Description vs. implementation

Service vs. Web service


6/34

12/25/20


Web Compliance

A set of simple and flexible concepts forming the foundation of Web suchas URI, namespaces, etc.

Why is it important?

Reliance on the already established concepts such as URIs enables

seamless integration of pre-existing Web resources and tested tools

What is expected from the framework?

A SWS framework should integrate with the current Web, thus it should

reuse/rely on the basic Web concepts


Ontology based

An ontology-based system is a system which adopts ontologies to express

data and processes which the system deals with


Ontologies are allowing enhanced information processing and automatic

resolution of heterogeneity issues between resources


Usage of ontologies as the data model throughout framework

All resource descriptions and data exchanged are ontologically described


7/34

12/25/20


Strict Decoupling

Represents separation of resources which should not depend on eachother


On the Web resources are developed in isolation from one another


Resources should be strictly decoupled from one another

Semantic descriptions are developed in isolation without regard for their

possible usage or interaction with other resources


Centrality of Mediation

Mediation is an activity which reconciles heterogeneities between parties


Decoupling of resources requires existence of a mechanism for resolving

heterogeneity issues between them

Mediation performs the role of resolving potential incompatibilities between

resources that occur at the data, protocol and process level

What is expected from the framework? Mediators should be top-level elements of the framework

It should be easy to connect mediators to the other elements


8/34

12/25/20


Ontological Role Separation

Consumers and providers of Web Services are loosely coupled


The contexts within which requesters and providers of services exist can

be very different from one another


A framework should differentiate between the requirements that a given

requester has and the functionality that service providers are willing to

offer

The framework should stress the difference between the goals and Web

services


Description vs. Implementation

Difference between description of functionality and its implementation

Service description is separated from the way the service is implemented


A firm distinction between the description of elements of SWS and

executable technologies should be present

What is expected from the framework? A framework should aim at providing ontological description model for the

elements and to be compliant with the executable technologies


9/34

12/25/20


Service vs. Web Service

A clear distinction between Services and Web Services

A Web Service is a computational entity that is able to provide some

functionality to the user by invoking it

A service is the actual value provided by the invocation


Although services are what counts for the consumers their value may be

subjective and context-dependent

A SWS framework should provides means to describe Web Services

What is expected from the framework? A framework should be designed as a means to describe Web Services

Actual value is provided by Web Service invocations


Approaches (W3C Member Submissions)

WSMO: Ontologies, Goals, Web Services, Mediators

OWL-S: WS Description Ontology (Profile, Service Model, Grounding)

WSDL-S/SA-WSDL: Semantic annotation of WSDL descriptions


10/34

12/25/20

OWL-S

Represents an upper ontology for the description of semantic

Web services

Has its roots in the DAML Service Ontology (DAML-S)

Adopts existing Semantic Web recommendations (i.e. OWL)

Maintains bindings to the Web Services world by linking to WSDL

descriptions

W3C Member Submission

OWL-SConceptual Model Service Class

Provides an organizational point of reference fora declared Web service

The class has three properties

presents

Defines what service does

Points to the ServiceProfile instance

supports Defines how to access the described service

Points to the ServiceGroundinginstance

describedBy Defines how the service works

Points to the ServiceModelinstance


11/34

12/25/20

OWL-SConceptual Model Service Profile Class

Expresses what a service does for

Advertising purposes

Used to express the service functional and non-functional properties

OWL-S Profile represents two aspects of the functionality of the service:

The information transformation represented by inputs and outputs (using Input and

Output class as specifications of Parameter general class)

The state change produced by the execution of the service represented by

preconditions and effects (using Condition and Result class)

Template for service requests

Exposes how a service works to enable

Invocation, composition, monitoring, recovery, etc.

To give a detailed perspective on how to interact with a service,

it can be viewed as aprocess

Specifically, OWL-S defines a subclass ofServiceModel,Process

A OWL-SProcess is not a program to be executed. It is a specification of the

ways a client may interact with a service

OWL-SConceptual Model Service Model Class


12/34

12/25/20

Process class is specialized into

Atomic process

Have no sub-processes and execute in a single step, as far as the service

requester is concerned

They take an input message, do something, and then return their output

message

Simple process

Not invocable and are not associated with a grounding

Used as elements of abstraction

Used to provide a view of some atomic process

Simplified representation of some composite process

Composite process Decomposable into other (non-composite or composite) processes by using

control constructs such as Sequence andIf-Then-Else

OWL-SConceptual Model Service Model Class

The grounding of a service

Specifies the details of how to access the service

Protocol and message formats, serialization, transport, and addressing

Can be thought of as a mappingfrom an abstractto a concrete

specification of those service description elements that are required for

interacting with the service

OWL-SConceptual Model Service Grounding Class


13/34

12/25/20

WSDL-S

Developed by IBM and the University of Georgia, following the

guidelines stated below: Build on existing Web services standards

The mechanism for annotating Web services with semantics should be

independent of the semantic representation language

The mechanism for annotating services with semantics should allow the

association of multiple annotations written in different semantic

representation languages

Support semantic annotation of Web services whose data types are

described in XML schema

WSDL-S

Advantages of adding semantics to WSDL

Users can, in an upwardly compatible way, describe both the semantics

and the operation level details in WSDL

By externalizing the semantic domain models, agnostic approach to

ontology representation languages has been considered

Allows developers to annotate their services with their choice of modeling

language

Users can use OWL or WSMO or any other modeling language of their choice

Is considered to be significant because the ability to reuse existing domain models


14/34

12/25/20

WSDL-S

Adding semantic annotations to the WSDL document

An extension element wssem:modelReference

To specify the association between a WSDL entity and a concept in some

semantic model

An extension attribute wssem:schemaMapping

Added to XSD elements and complex types, for handling structural differences

between the schema elements of a Web service and their corresponding

semantic model concepts

Two elements, namely wssem:precondition and wssem:effect

Specified as child elements of the operation element

Preconditions and effects are primarily used in service discovery, and are not

necessarily required to invoke a given service

An extension attribute on the interface element, namely category

Consists of service categorization information that could be used when

publishing a service in a Web Services registry such as UDDI

Web Services Modeling Ontology (WSMO)

Identifies four main concepts which have to be described in

order to define semantic Web services

Ontologies

Provide the terminology used by other WSMO elements to describe the relevant

aspects of the domains of discourse

Web services

Provides a conceptual model for describing, in an explicit and unified manner, all

aspects of a service, including its non-functional properties, its functionality, and theinterfaces needed to obtain it

Goals

Describe aspects related to user desires with respect to the requested functionality

Mediators

Describe elements that handle interoperability problems between differentWSMO elements; they are the core concepts to resolve incompatibilities on thedata, process and protocol level


15/34

12/25/20

Web service discovery

The process of finding suitable Web services for given task

A reference architecture of conventional WS discovery systems

Conventional WS discovery systemsMain components

Service provider is an entity that offers some services to other

entities upon request

Each implemented service of a provider is called service instance

Service requestors are the entities that search for services

Issue service requests against this registry

Service Registry is an implementation of a directory service (i.e.,

yellow pages)

Indexes service advertisements in several ways

Classify the services according to their application domain, service provider, and

so forth

Does not contain the actual service instances but only the bindings of

service descriptions with the actual service instances


16/34

12/25/20

Conventional WS discovery systems

Main components

Matching Algorithm

Matches the service requests with service descriptions

Tightly coupled with the service registry

Service Request

Declares the intention of the service requestor regarding the desired

service functionality

Is a formal/informal description of the functional and technical capabilities

and/or constraints that should be satisfied by the discovered service

Service Advertisement

Is analogous to a service request but from the providers perspective

Describes the functionality, invocation details and execution flow of an

offered service. Depending on the registry type, this specification may be

more or less formal

Conventional WS discovery systemsMatching methods

Standard UDDI registries allow for keyword based search

Services can be searched by category, name, location, business,

bindings ortModels

Keyword based matching

Many researchers have proposed extensions to this querying mechanism.

The most interesting approaches are based on information retrieval

techniques


17/34

12/25/20

Limitations of conventional WS discovery systems

Informal description of service functionality/capabilities

The high-level functionality of the services is described in an unstructuredor semi-structured format

Most service descriptions are provided in natural language form

Inference cannot be performed on UDDI business and service catalogs

This hinders the matching process, if the provider and requestor do not use

common vocabulary

Incomplete description of service functionality/capabilities

The level of detail for the service descriptions is determined by each

provider

Since no predefined and mandatory fields exist, providers are free to

describe their services in arbitrary detail

Limitations of conventional WS discovery systems

Syntax-based matching of service capabilities cannot give

quality results, because a service request matches an

advertisement only if their keywords match

Exact matching methods cannot fully capture the intentional

semantics of services or service requests

Phenomena such as linguistic polysemy (i.e., the property of a word

having many meanings)

Keyword-based descriptions cannot describe internal servicestructure (e.g., data and execution flows), which may be of use

during service discovery or composition

The search methods of UDDI cannot support indirect matching

This is a serious limitation, especially if there are only primitive and very

simple services available in a registry


18/34

12/25/20

Semantic Web service discovery

Is based on semantic service annotations

Semantic service annotations

Were introduced to automate the whole service lifecycle, from advertisement to

invocation and execution

Have a crucial role in service discovery and affects the architectures, algorithms,

effectiveness of service retrieval and every other aspect of the discovery

Architectural components of the conventional WS discovery

systems are maintained, but implemented differently in order to

provide enhanced functionality

In addition, several new components are introduced

i.e. Service Annotation Ontologies, Domain Ontologies Service discovery interaction steps remain the same as for

traditional Web services discovery systems

SWS discovery architecture

Service advertisement are described according to specific

Service Annotation Ontologie

OWL-S (Martin, 2005)

WSDL-S (Li, 2006)

WSMO (Roman, 2005)

The annotation terms used in the service advertisements are

expressed through shared vocabularies, defined byDomain

Ontologies Describe the terminology and term relationships in specific application

domains

Are used in the semantic service annotations, as specified by the Service

Annotation Ontologies


19/34

12/25/20


Service Request

May vary from natural language text to the service annotation ontologies

Irrespectively of the adopted format, a request contains information

relevant to that specified by the used service annotation ontology (e.g.,

IOPE values)

Domain ontologies

The use of the same domain ontologies by both the service requestors and

providers, although not mandatory, significantly simplifies the matching

process by eliminating the need for mediation layers


Service Registry

The traditional WS registries (e.g., UDDI) are still used by most SWS

discovery architectures

However, besides the traditional WS descriptions (e.g., tModelentries,

WSDL documents), they also store, or contain references to semantics

information annotating the advertised services

Several methods have been proposed for linking semantic service

annotations to UDDI registry entries (e.g., tModels)

Matching Algorithm

The semantic matching algorithms are, in general, more complex and

intelligent than their syntax-based counterparts

Are designed so as to exploit the explicit functionality semantics of the

provided service descriptions and requests


20/34

12/25/20

Algorithmic approaches to matchmaking

Most service matchmaking approaches exploit the service

profile of a SWS During discovery, the requestor is more interested in whether a service can

fulfill the posed requirements than in how it works or how it can be invoked

Moreover, most approaches exploit the IOPE attributes,

described in the service profile

This is also intuitively correct, since two services that have similar IOPE

attributes are generally considered similar


The most important problems in matchmaking

Is unrealistic to expect advertisements and requests to be in perfect match

Adopting a hard-decision logic, would result in ignoring services that

partially match a service request

The problem is becoming worse if we take into account that the service

request may not fully capture the requestors intention

In that case, one can observe the paradox where a service advertisement that

partially matches the service request might perfectly match the requestors

intention


21/34

12/25/20


Degree of Match (DoM)

A value that expresses how similar two entities are, with respect to some

similarity metric(s)

Entities may be services,IOPEattributes or specific service operations

Important feature of most SWS matchmaking algorithms

Allows for ranking of discovered services according to their relevance to

the service request


Matchmaking approaches can be categorize according to

various criteria

Direct vs. Indirect match

Direct: A service request is matched against single service advertisements

Indirect: A service request is matched against composite services, constructed

from simple or complex workflows of single service advertisements

Supporting DoMor not

Using only service profile or other service information Assessing service similarity through logic-based reasoning or other

techniques


22/34

12/25/20

Algorithmic approaches to matchmakingSemantic Capabilities Matching (Paolucci, 2002)

One of the first, and probably most influent work in the field of

SWS discovery

The basic idea

An advertisement matches a request when all the outputs of the request

are matched by the outputs of the advertisement, and all the inputs of the

advertisement are matched by the inputs of the request

Takes into account only the inputs and outputs of the service

profiles during matchmaking

DoMbetween two outputs/inputs depends on the relationship

between the domain ontology concepts associated with those

inputs/outputs

Algorithmic approaches to matchmakingSemantic Capabilities Matching (Paolucci, 2002)

The approach is based on thesubsumption matching

FourDoMs have been specified

The matching algorithm

Implements degreeOfMatch rules

Returns an ordered list of matching service advertisements

DoM Matching conditions

EXACT Ifreq.o is equivalent to adv.o, or

Ifreq.o is a direct subclass ofadv.o

PLUGIN Ifadv.o subsumes req.o

SUBSUMES Ifreq.o subsumes adv.o

FAIL If there is no subsumption relationship between req.o and adv.o


23/34

12/25/20

Web services composition

Service composition

The process of developing a composite service

Can be either performed by composing

Elementary services

Composite services

Are recursively defined as an aggregation of elementary and composite services

The need for Web services composition

If the implementation of a Web services business login involves the

invocation of other Web services it is necessary to combine the

functionality of several Web services

This is called composite service

Web services composition

When composing Web services, the business logic of the client

is implemented by several services

This is analogous to workflow management, where the application logic is

realized by composing autonomous applications

This allows the definition of increasingly complex applications by

progressively aggregating components at higher levels of abstraction

A composite service can itself be exposed as a Web service

Despite all research efforts, the Web service composition still isa highly complex task, and it is already beyond the human

capability to deal with the whole process manually


24/34

12/25/20

Composition Issues

Number of services available

The number of services available over the Web increases dramatically

during the recent years, and one can expect to have a huge Web service

repository to be searched

Domain Dynamic

Web services can be created and updated on the fly, thus the composition

system needs to detect the updating at runtime and the decision should be

made based on the up to date information

Heterogeneity

Web services can be developed by different organizations, which use

different concept models to describe the services However, there does not exist a unique language to define and evaluate

the Web services in an identical means

Composition Issues

Coordination

When it comes to composing Web services and building complex software

systems, it is likely that interaction requires coordination of sequences of

operations, to ensure correctness and consistency

New protocols and abstractions are needed and this is exactly the case of

coordination

Context

In terms of Web services, context may be inferred as information utilized by

the Web service to adjust execution and output to provide the client with acustomized and personalized behavior

Context is extensible with new types of information at any time, without any

changes to the underlying infrastructure

Context may contain information such as a consumers name, address, and

current location, the type of client device, including hard and software that the

consumer is using, or all kinds of preferences regarding the communication


25/34

12/25/20

Aspects of composition

Component Model

Composition Model

Formal: State charts, Petri Nets, -Calculus

XML-Oriented: Activity Hierarchies

Process Based: JOpera (Visual), WS-BPEL (XML)

Others: Rule Based, UML Activity Diagrams, Data Driven

Service Selection Model

Data Transfer Model

Exception Handling

Transactions

Aspects of compositionComponent Model

Component model defines the assumptions about the

components that should be composed

In general, composing homogeneous components is easier than

composing heterogeneous ones as the corresponding

infrastructure is less complex

In one case, all components could be Web services (accessed with the

SOAP/HTTP protocols and described by a WSDL document)

On the other extreme, the components are just services that can beaccessed using a variety of invocation mechanisms


26/34

12/25/20

Aspects of compositionComposition Model

Composition models define how to build a coherent system out

of a collection of services

They define:

What is the order in which the services are invoked and what are the

conditions under which a certain service may or may not be invoked

(control flow)

How the services exchange data with one another (data flow) and how

they interact

Some for ofexception handling, i.e., what happens if a service is not

available

Aspects of compositionService Selection Model

In addition to specifying what are the messages to be

exchanged, a composition model should also define how to

select the services that should receive or send such messages

In order to enhance the reusability of a composition, such

services are usually not hard-coded into the composition but

bound into it at different times:

Composition time

Compilation and deployment time

Invocation time


27/34

12/25/20

Aspects of compositionService Selection Model

The service selection model defines how services are bound

into a composition:

Static binding (URL of service endpoint is hard-coded)

Dynamic binding by reference: (Service URL is computed and stored into a

variable)

Dynamic binding by lookup (before each service invocation a query is sent

to a registry to locate a suitable implementation)

Dynamic operation selection (no assumptions are made about the

signature of the arbitrary service to be invoked)

Aspects of compositionData Model

Services typically interact by exchanging some data

Not all composition languages include an explicit model of the

data flow

Data is not always treated in the same way:

Composition-level data is modeled at a finer level as it is used to control

the composition (control flow branches) and has data types associated

with it

Application-specific data is seen as an opaque pointer (URL) which isforwarded between services


28/34

12/25/20

Aspects of compositionException Handling

Exception Handling is very important as service compositions

should explicitly model what to do if a service is not available orif its invocation fails

Flow-based exception handling uses normal control flow

constructs to branch after a service invocation has failed

Try/Catch blocks are used in a similar way to associate an

exception handler to a set of service invocations

Rules may also be associated to a composition in order to

detect global exceptional conditions

Aspects of compositionTransactions

In order to support long running transactions, each service

operation can be also associated with a compensation handler,

which is invoked only if the operation should be undone


29/34


30/34

12/25/20

3

Composition approaches

Automated vs. manual web services composition

Traditionally, Web service composition has been performed manually,

making it a difficult and error prone task

In an automatic composition system, the userss role is limited to

specifying the functional requirements. Instead, the system should define

the data and control flow by assembling individual services based on user

provided inputs and expected outputs

Manual Web service composition process

Initially, a user would create an abstract specification of a high-

level task

The specification may include the task goals, I/O and control parameters,

and any conditions and effects

As a next step, if the user possesses enough domain

knowledge, he could create an abstract composite workflow by

decomposing the specification


31/34

12/25/20

3


To create the abstract workflow, the user may utilize some Web

service standard language (WS-BPEL or OWL-S)

Besides the basic flow of the process, additional constraints

may be specified for the task as a whole or each subtask within

the workflow

e.g. QoSparameters and security policy information

At this point, the user needs to have some guarantee that the

abstract workflow he created satisfies his intended high level

goal


Next, the user would have to bind Web services to his workflow

The most widely used method is to search and discover services published

in a Web service repository such as UDDI

There is no guarantee that services will be a one-to-one match with the

task descriptions: I/O parameter differences may make them incompatible,

several tasks may be fulfilled by one service, requiring further

decomposition of the specification, or visa versa

Once the user binds services to tasks, an executable process is

created

As the process is executed, the user needs to monitor the execution and

handle faults if they arise


32/34

12/25/20

3

Requirements for automatic Web service composition

Specification phase

Provide an easy way for a user to specify task goals, requirements andconstraints without extensive domain knowledge

Planning phase Provide an automatic way to compose an abstract workflow based on the

specification

Validation phase Provide techniques to ensure that the composite process realized via an

abstract workflow satisfies the users stated task goals

Discovery phase Provide a way to discover services that satisfy task specifications in the

workflow Execution with monitoring phase Provide a framework for monitoring an executing service, and provide

automatic fault-handling mechanisms


Specification Phase

The user specifies the goal he is trying to achieve

The specification

Should have enough detail to aid in creating the abstract specification

Include functional and non-functional requirements

Functional requirements are constraints, control/data flow and high-level goal of the

complex task

Non-functional aspects may include security policy, QoSconstraints, etc.

Desired behavioral issues (i.e. termination conditions, failure recoveryrequirements) should also be able to be specified


33/34

12/25/20

3


Planning Phase

Takes the abstract specification created in the specification phase andproduces an abstract composite workflow

If the specification did not contain enough detail (i.e., it was a partial

specification) or was stated as P/E and goals, then the description needs

to be decomposed into simpler steps in this phase


Validation Phase

Takes an abstract composite workflow that is an output of the planning

phase to address the following:

Syntactic validation:

Is the workflow well-formed and structurally correct (i.e. does not contain deadlocks,

infinite cycles, etc)?

Syntactic validation may be handled by the planning tool, depending on the approach

used

Semantic validation:

Does the plan satisfy user goals and requirements/constraints that were detailed in the

specification phase?

If the user created more than one abstract composite workflow in the

planning phase, there may be multiple candidates to validate. The result of

the validation should produce a syntactically and semantically optimal

abstract composite workflow


34/34

12/25/20


Discovery Phase

Takes the abstract composite workflow, and finds suitable atomic servicesfor each task in the workflow by querying service repositories

Execution and Monitoring Phase

Provides deployment and execution of a newly created composite service

This phase includes following control flows that were specified in the

workflow and recovery mechanisms to ensure proper execution of

composition

Semantic Ws

Documents