12/25/2010

Technical University of Cluj-Napoca Computer Science Department

Distributed Systems - Master in CS -

C6 Semantic Web Services

Fall 2010

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.

12/25/2010

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 Access of services over the Web An XML-based language used to define Web services and describe how to access them

SOAP

WSDL

12/25/2010

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 Integration Protocol (UDDI)

Registry for Web Services UDDI data model

businessEntity

Information about the service provider (i.e. the providers name, description and contact details) Information about a Web service or a group of services (i.e. the service name, description and an optional list of bindingTemplates) Information about how and where to access a specific service

businessService

bindingTemplate

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

12/25/2010

Web Service usage process

Deployment

Create and publish Web service description Determine the services that satisfy a request Combine services to achieve a complex goal Choose most appropriate service among the available ones Solve incompatibilities (data, protocol, process) that hamper interoperation Invoke Web services following programmatic conventions

Discovery

Composition

Selection

Mediation

Execution

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

12/25/2010

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 Web compliance Ontology-based Strict decoupling Centrality of mediation Ontological role separation Description vs. implementation Service vs. Web service

A SWS framework should answer to the following requirements:

12/25/2010

Semantic Web service framework

Web Compliance

A set of simple and flexible concepts forming the foundation of Web such as URI, namespaces, etc. Reliance on the already established concepts such as URIs enables seamless integration of pre-existing Web resources and tested tools A SWS framework should integrate with the current Web, thus it should reuse/rely on the basic Web concepts

Why is it important?

What is expected from the framework?

Semantic Web service framework

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

Why is it important?

What is expected from the framework?

12/25/2010

Semantic Web service framework

Strict Decoupling

Represents separation of resources which should not depend on each other 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

Why is it important?

What is expected from the framework?

Semantic Web service framework

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 Mediators should be top-level elements of the framework It should be easy to connect mediators to the other elements

Why is it important?

What is expected from the framework?

12/25/2010

Semantic Web service framework

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

Why is it important?

What is expected from the framework?

Semantic Web service framework

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 A framework should aim at providing ontological description model for the elements and to be compliant with the executable technologies

Why is it important?

What is expected from the framework?

12/25/2010

Semantic Web service framework

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

Why is it important?

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

Semantic Web service framework

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

12/25/2010

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-S
Conceptual Model Service Class

Provides an organizational point of reference for a declared Web service The class has three properties

presents

Defines what service does Points to the ServiceProfile instance

Defines how to access the described service Points to the ServiceGrounding instance

supports

describedBy

Defines how the service works Points to the ServiceModel instance

10

12/25/2010

OWL-S

Conceptual 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

OWL-S

Conceptual Model Service Model Class 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 a process

Specifically, OWL-S defines a subclass of ServiceModel, Process

A OWL-S Process is not a program to be executed. It is a specification of the ways a client may interact with a service

11

12/25/2010

OWL-S
Conceptual Model Service Model Class

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 Not invocable and are not associated with a grounding Used as elements of abstraction

Simple process

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 and If-Then-Else

OWL-S

Conceptual Model Service Grounding 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 mapping from an abstract to a concrete specification of those service description elements that are required for interacting with the service

12

12/25/2010

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

13

12/25/2010

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 Consists of service categorization information that could be used when publishing a service in a Web Services registry such as UDDI

An extension attribute on the interface element, namely category

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 the interfaces needed to obtain it Describe aspects related to user desires with respect to the requested functionality

Goals

Mediators

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

14

12/25/2010

Web service discovery

The process of finding suitable Web services for given task A reference architecture of conventional WS discovery systems

Conventional WS discovery systems

Main 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 Issue service requests against this registry

Service requestors are the entities that search for services

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

15

12/25/2010

Conventional WS discovery systems

Main components

Matching Algorithm

Matches the service requests with service descriptions Tightly coupled with the service registry 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 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

Service Request

Service Advertisement

Conventional WS discovery systems

Matching methods Standard UDDI registries allow for keyword based search Services can be searched by category, name, location, business, bindings or tModels Keyword based matching

Many researchers have proposed extensions to this querying mechanism. The most interesting approaches are based on information retrieval techniques

16

12/25/2010

Limitations of conventional WS discovery systems

Informal description of service functionality/capabilities

The high-level functionality of the services is described in an unstructured or 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 service structure (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

17

12/25/2010

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 by Domain 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

18

12/25/2010

SWS discovery architecture

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

Domain ontologies

SWS discovery architecture

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., tModel entries, 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) 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

Matching Algorithm

19

12/25/2010

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

Algorithmic approaches to matchmaking

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

20

12/25/2010

Algorithmic approaches to matchmaking Degree of Match (DoM)

A value that expresses how similar two entities are, with respect to some similarity metric(s) Entities may be services, IOPE attributes 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

Algorithmic approaches to matchmaking

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 DoM or not Using only service profile or other service information Assessing service similarity through logic-based reasoning or other techniques

21

12/25/2010

Algorithmic approaches to matchmaking

Semantic 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 DoM between two outputs/inputs depends on the relationship between the domain ontology concepts associated with those inputs/outputs

Algorithmic approaches to matchmaking

Semantic Capabilities Matching (Paolucci, 2002)

The approach is based on the subsumption matching

Four DoMs have been specified

DoM EXACT PLUGIN Matching conditions If req.o is equivalent to adv.o, or If req.o is a direct subclass of adv.o If adv.o subsumes req.o If there is no subsumption relationship between req.o and adv.o

SUBSUMES If req.o subsumes adv.o FAIL

The matching algorithm Implements degreeOfMatch rules

Returns an ordered list of matching service advertisements

22

12/25/2010

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 is a highly complex task, and it is already beyond the human capability to deal with the whole process manually

23

12/25/2010

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

Heterogeneity

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 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 a customized 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

Context

24

12/25/2010

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 composition

Component 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 be accessed using a variety of invocation mechanisms

25

12/25/2010

Aspects of composition

Composition 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 of exception handling, i.e., what happens if a service is not available

Aspects of composition

Service 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

26

12/25/2010

Aspects of composition
Service 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 composition

Data 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 is forwarded between services

27

12/25/2010

Aspects of composition

Exception Handling Exception Handling is very important as service compositions should explicitly model what to do if a service is not available or if 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 composition
Transactions

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

28

12/25/2010

Web Service Composition - Classification

Proactive Composition vs. Reactive Composition

Proactive: offline composition of available services

When: services are stable and always running Example: ticket reservation service

Reactive: dynamically creating a composite service

When: composite service not often used and service processes not stable Example: tour manager where the itinerary is not predefined

Mandatory vs. Optional Composite Services

Mandatory: all subcomponents must participate to yield a result

Example: service that calculates the averages of stock values for a company

Optional: subcomponents are not obligated to participate for a successful execution

Example: services that include a subcomponent that is an optimizer

Composition approaches

Static vs. dynamic service composition

Concern the time when Web services are composed Static composition

Takes place during design-time when the architecture and the design of the software system are planned The components to be used are chosen, linked together, and finally compiled and deployed This may work fine as long as the Web service environment business partners, and service components does not, or only rarely, change Takes place during run-time Is able to transparently adapt to environment changes, and to adapt to customer requirements with minimal user intervention

Dynamic composition

29

12/25/2010

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 highlevel 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

30

12/25/2010

Manual Web service composition process

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. QoS parameters 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

Manual Web service composition process

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

31

12/25/2010

Requirements for automatic Web service composition

Specification phase

Provide an easy way for a user to specify task goals, requirements and constraints without extensive domain knowledge Provide an automatic way to compose an abstract workflow based on the specification Provide techniques to ensure that the composite process realized via an abstract workflow satisfies the users stated task goals Provide a way to discover services that satisfy task specifications in the workflow Provide a framework for monitoring an executing service, and provide automatic fault-handling mechanisms

Planning phase

Validation phase

Discovery phase

Execution with monitoring phase

Requirements for automatic Web service composition

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, QoS constraints, etc.

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

32

12/25/2010

Requirements for automatic Web service composition

Planning Phase

Takes the abstract specification created in the specification phase and produces 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

Requirements for automatic Web service composition

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 Does the plan satisfy user goals and requirements/constraints that were detailed in the specification phase?

Semantic validation:

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

33

12/25/2010

Requirements for automatic Web service composition

Discovery Phase

Takes the abstract composite workflow, and finds suitable atomic services for each task in the workflow by querying service repositories 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

Execution and Monitoring Phase

34