Approaches to Service Description (up)

LaTeX Version LaTeX Version
A Web service is defined by the W3C as a software system designed to support interoperable machine-to-machine interaction over a network. [WSMO (2007)] define Web services as computational entities which are capable to achieve a users goals. On the contrary, services are understood to be the actual value provided by the invocation of web services. A Web service might provide different services. An example often referd to is Amazon. Amazon can be used for acquiring books as well as to find out an ISBN number of a book. 
On the abstract level a Web service works with three phases and three main stakeholders. Figure [1] shows this scenario, where the phases are publish, find, and invoke. The stakeholders are service provider, service requestor and discovery agencies [Moyano, M; Buccella, A.; Cechich, A. (2005)]. The service provider provides an interface description (usually WSDL) of the service, which defines the operations of the service, input/output parameters of each operation, and information of how the service can be located in the network. The provider is responsible for publishing the service description in one or more discovery agencies. A service requestor finds the published service description and configures a client to enable communication between client and service. Finally, the requestor invokes the service facillitating the available communication protocols. 
Common Scenario of a Web Service
Abbildung 1: Common Scenario of a Web Service
Today, Web services technology allows to publish services in a UDDI registry, a registry based on a standard, which allows clients to find Web services through descriptions of business entities, business services or via predefined business categories. Interfaces of web services are described using the Web Service Description Language (WSDL). Requests as well as messages are exchanged over a network using SOAP protocol (see figure [2]). The Business Process Execution Language (BPEL) allows composition of services into complex processes as well as their execution.  
Abbildung 2: UDDI, SOAP and WSDL
Web services technologies and standards like UDDI, SOAP and WSDL have added a new value to the current IT environments concerning the integration of distributed software components [NESSI Semantic Technologies Working Group (2006)]. However, almost all current SOA solutions remain to be in-house solutions of companies, not fulfilling the vision of a service-oriented world consisting of an “uncountable” number of services, as proclaimed by NESSI's strategic project SOA4All. One factor limiting the take up of Web services is that using Web services are not configurable on the business (user) level, but need to be configured by developers and IT experts. 
This drawbeck is to be resolved by adding machine processable semantics to the scenario discussed above. According to SOA4All automatic selection, mediation and composition of services across heterogeneous users and domains will be possible. Therefore the current web needs to be refined towards a comprehensive framework which integrates two complimentary and revolutionary technical advances, namely Service-Oriented Architectures (SOA) and Semantic Web, into a single computing architecture (see figure [3], [Dominque, J.; Martin, D. (2008)]). SOA, as the emerging dominant paradigm for application development, allows abstraction from software to the notion of service. Semantic Web technologies offer means to automate service discovery, mediation and composition. 
Combining SOA and Semantic Web
Abbildung 3: Combining SOA and Semantic Web
As discussed in section SOA4All , the outcome of the SOA4All project will be a comprehensive framework and infrastructure that integrates those advances into a coherent and domain independent service delivery platform [European Commission (2008)]. Besides SOA and Semantic Web, Context Management and Web 2.0 technologies will be important "ingredients". In the following section the focus lies on Semantic Web Service technologies as the current most promising approach for automating service discovery, mediation and composition. The state of the art on service decription is surveyed. For these purpose service description approaches are structured into the following groups: 

WS-* Standards (up)

WS-* Standards focus on Web Service Description Language (WSDL) services. WSDL is an XML language to formally describe a Web service as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)], independent from the message formats or network protocols used to communicate. In short, WSDL defines some XML grammar for describing communications regarding Web services in a structured and standardized way. 
According to [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)] WSDL structures Web services into three main levels:  
Apart from the interfaces, bindings and endpoints described above, WSDL documents can contain further elements, enclosed in the root <description> element. Figure [4] ([W3C (2007)]) gives an overview on the structure of WSDL documents that conforms to the current version of WSDL - Version 2.0. 
WSDL 2.0 Infoset Diagram
Abbildung 4: WSDL 2.0 Infoset Diagram

RESTful Web Services (up)

Service descriptions for REpresentational State Transfer (REST) Web services follow the 'Web Principles'. REST is an architectural style that treats the Web as a resource-centric application.  
Based on Tim Berners-Lee's 'Design Principles of the Web' (see [Berners-Lee, T.; Hendler, J.; Lassila, O. (2001)]) the REST architectural style is based on four principles (see [Pautasso, C.; Zimmermann, O.; Leymann, F. (2008)]): 
In short, RESTful web services are viewed as resources that can be identified by their URLs. Service clients that want to use these resources access a particular representation by transferring application content using a small globally defined set of remote methods. The methods PUT, GET, POST, and DELETE describe the action to be performed on the resource [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)]
Currently no standard description languages for RESTful Web services exists. [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)] state that most current descriptions of RESTful services are provided as plain texts. They refer to Web Application Description Language (WADL) - a specification developed to be an alternative to WSDL with specific support for RESTful web services - as one timid description language with a poor dissemination so far. According to [Hadley, M.J. (2006)] WADL is an XML language designed to provide a machine processable protocol description format for use with HTTP-based Web applications. Its focus lies on web applications using XML to communicate. A WADL document is defined using the elements application, grammar element, resource element, method element, representation element, and fault element. The table below provides a short description on components of a WADL document. For a more detailed specification refer to [Hadley, M.J. (2006)]
Application is a top level element that contains the overall description of the service. It acts as container for the other listed elements.
Grammar Element
The grammars element acts as a container for definitions of the format of data exchanged during execution of the protocol described by the WADL document.
Resource Element
A resource element describes a set of resources, each identified by a URI that follows a common pattern.
Method Element
A method element describes the input to and output from an HTTP protocol method that may be applied to a resource.
Representation Element
A representation element describes a representation of a resource’s state.
Fault Element
A fault element is similar to a representation element in structure but differs in that it denotes an error condition.
Tabelle 2: Components of a WADL Document
For a more detailled description on WADL refer to [Hadley, M.J. (2006)]

Incorporating Semantic Web into SOA - Semantic Services Frameworks (up)

The standards discussed above use syntactic notations. WSDL and WADL are machine readable but not machine understandable. Only developers can carry out required tasks associated with creating and maintaining Web service-based applications. Tasks like Web service discovery, composition, and invocation can be automated to a great extent by applying semantic technologies. This target - providing Web content in a machine processable way - has been applied in the past years in the context of Web services usage giving birth to a new research area know as Semantic Web services. "The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation." [Berners-Lee, T.; Hendler, J.; Lassila, O. (2001)]  
In the following an overview on the existing approaches to Semantic Web technologies is given. 

Web Service Modeling Ontology (WSMO) (up)

WSMO is intended for describing the various aspects related to Semantic Web services discussed above. WSMO is based on the Web Service Modeling Framework (WSMF) [Fensel, D.; Bussler, C. (2002)] and extends this framework through a formal ontology and language. Following the main elements identified in the Web Service Modeling Framework, WSMO identifies four top level elements as the main concepts (see figure [5]). According to [WSMO (2007)] these elements have to be defined in order to describe Semantic Web services. 
WSMO Top Level Notations
Abbildung 5: WSMO Top Level Notations
WSMO Mediator Overview
Abbildung 6: WSMO Mediator Overview

Ontology Web Language for Services (OWL-S) (up)

OWL-S (formerly DAML-S) is an OWL-based Web Service Ontology. It aims at providing building blocks for encoding rich semantic service descriptions, in a way that builds naturally upon OWL. The overall structure of OWL-S provides three main parts [W3C (2004)]:  
The OWL-S upper level ontology comprises four major elements: Service, Service Profile, Service Model and Service Grounding. 
Top level of the service ontology
Abbildung 7: Top level of the service ontology
The figure below illustrates the mapping between OWL-S and WSDL used for service grounding [W3C (2004)]
Mapping between OWL-S and WSDL
Abbildung 8: Mapping between OWL-S and WSDL

Semantic Web Services Framework (SWSF) (up)

The Semantic Web Services Framework (SWSF) is proposed and promoted by Semantic Web Services Language 
Committee (SWSLC) of the Semantic Web Services Initiative (SWSI). According to [ref:WC3 (2006)] and [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)] it is based on two major components:  
  1. a conceptual model by which Web services can be described, called Semantic Web Services Ontology (SWSO) and  
  2. a language for specifying formal characterizations of Web services concepts and descriptions of individual Web services called Semantic Web Services Language (SWSL)
1) SWSO 
presents a conceptual model for semantically describing Web services and an axiomatization, formal characterization of this model given in one of the two variants of SWSL:  
The FLOWS ontology consists of three major components specified in table below.  
Service Descriptor
The Service Descriptors are used to provide basic descriptive information - nonfunctional metainformation and/or provenance information - about the service. Service Descriptions are usually used to provide means for the automation of service related tasks like service discovery. Examples for Service Descriptors are Service Name, Service Author, Service Contact Information, Service Description and Service URL.
Process Model
The Process Model is used to describe how the service works. It provides means to describe the behavior of the service. This is done by adding two fundamental elements:  
  • the structured notion of atomic process as found in OWL-S and  
  • the infrastructure for specifying various forms of data flow.  
The FLOWS Process Model ontology is a combination of the following six ontology elements: FLOWS-Core, Control Constraints, Ordering Constraints, Occurrence ConstraintsState Constraints, State Constraints, and Exception Constraints. Most important the FLOWS-Core module introduces the basic notions of activities as activities composed of atomic activities.
The Grounding is used to link the semantic, abstract descriptions of the service provided in SWSO to detailed specifications of messages, protocols, and so forth used by Web services.
Tabelle 2: Components of the FLOWS Ontology
2) SWSL 
is a language for describing Web services concepts and descriptions of individual services. There are two variants of SWSL which are based on the following formalisms:  
Both languages are in compliance with Web principles, like usage of URIs, integration with XML built-in types and XML-compatible namespaces, and import mechanisms. They represent layered languages where every layer includes a number of new concepts that enhance the modeling power of the language. For a more detailled discussion on SWSL refer to [W3C (2005)]

Internet Reasoning Service (IRS-III) (up)

The IRS-III represents a framework and implemented platform for creating and executing semantic Web services. IRS-III takes a semantic broker based approach to mediating between service requesters and service providers [Cabral et. al (2006)], [Domingue et. al (2004)], [Tanasescu et. al. (2007)]. Hence it mediates between the goals of a user or client, and available deployed Web services. 
IRS-III builds on the framework of its precursor - the IRS-II framework [Motta, E. et. al. (2003)] and incorporates the Web Services Modelling Ontology [WSMO (2007)], [Fensel, D. et. al. (2006)] conceptual model. It uses WSMO as its basic ontology and follows the WSMO design principles. Differences and extensions to WSMO are mainly derived from the fact that in IRS-III the aim is to support capability driven Web service invocation. 
IRS-III work is guided by a set of principles, the most important of them being listed below: [Domingue et. al. (2008)], [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)]
The framework and its components to support the discussed principles in depicted in figure [9]. For a detailled discussion on the architecture refer to [Domingue et. al. (2008)]
The Architecture of the IRS - III Framework
Abbildung 9: The Architecture of the IRS - III Framework


Semantic Annotations for WSDL and XML Schema (SAWSDL) addresses semantic annotations to various parts of a WSDL document. More precisely SAWSDL delivers a set of extension attributes for WSDL that allows description of semantics aspects of services [W3C (2007)]. In the following the main principles of SAWSDL are discussed briefly. Furthermore the extensibility elements used and the annotations that can be created are explained.  
As reviewed in [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)] the most important design principles SAWSDL is based on are discussed: 
SAWSDL focuses on semantically annotating the abstract definition of a service to enable dynamic discovery, composition and invocation of services. It proposes two basic semantic annotation constructs to be used in annotating the interfaces, operations, faults in WSDL and simple types, complex types, elements and attributes in XSD: 
Figure [10] illustrates the overall structure of SAWSDL. 
Technical Overview on SAWSDL
Abbildung 10: Technical Overview on SAWSDL

WSMO-Lite (up)

WSMO is an important baseline for SOA4Alls goal to developing lightweigt ontology for the purpose of semantic annotation of Web services as it is one of the major Semantic Web Service approaches. WSMO has been used in many European funded projects as a solution to describe Semantic Web services. As discussed above WSMO provides a rich support to describe various aspects of services. However, there is one major drawback considering the learning curve of developers that want to annotate services and the tool support required.  
As stated in [Toma, I.; Steinmetz, N.; Lorre, J.P. (2008)] in some cases, a simpler, lighter support would be more appropriate. In this context, SOA4All project will develop a lighter version of WSMO, called WSMO-Lite that provides simple annotation support for services following the same principles described previously in this section. 
WSMO-lite can be described as the next evolutionary step after SAWSDL, filling the SAWSDL annotations with concrete semantic service descriptions and thus embodying the semantic layer of the Semantic Service Stack. WSMO-Lite is the description language that will be used in SOA4All for semantic descriptions of Web services. These descriptions will be stored in a service registry, represented in RDF.  
In other words, WSMO-Lite can be understood as a lightweight set of semantic service descriptions in RDFS that can be used for annotations of various WSDL elements using the SAWSDL annotation mechanism. Hence standard languages of W3C including RDF and RDFS as well as various extensions of those languages such as OWL, WSML and RIF are exploited with the ultimatate goal to support realistic real-world challenges in intelligent service integration. The follwing main goals are adressed [Kopecký, J.; Vitvar, T.; Fensel, D. (2008)]
The use cases deal with Web services, both WSDL-based and RESTful (see above). WSMO-Lite will be used by the use cases to describe the WSDL-based services. Additionally, the WSMO-lite service ontology and the minimal RDF representation are also used by MicroWSMO, the language for describing RESTful services [SOA4All (2009b)]. Figure [11] gives an overview the relation of MicroWSMO to SAWSDL, along with their positioning among the various service description specifications. MicroWSMO is a SAWSDL-like layer on top of hRESTS. In this context WSMO-Lite specifies an ontology for the content of SAWSDL annotations in WSDL. MicroWSMO annotations in hRESTS also point to instances of the WSMO-Lite ontology, since it captures service semantics independently of the underlying Web service technology (WSDL/SOAP or REST/HTTP). In effect, MicroWSMO is on a layer below WSMO-Lite, even though both use the acronym “WSMO” in their names [Kopecký, J. et al. (2009)].  
Releative Positioning of WSMO-Lite and MicroWSMO
Abbildung 11: Releative Positioning of WSMO-Lite and MicroWSMO
Letzte Änderung: 27.06.2009, 16:58 | 4355 Worte