Executive Summary

Semantic Web Service (SWS) frameworks especially address service discovery, composition and execution. This article first describes WSMO-Lite, a lightweight ontology of service semantics that builds on a W3C standard for semantic annotations of WSDL. WSMO-Lite distinguishes four kinds of service semantics (functional, nonfunctional, behavioral and information) and it provides a simple and modular ontology for capturing these semantics. Secondly, the article describes MicroWSMO, an approach for semantic description of RESTful services, which have been largely neglected both in context of SOA and in SWS research. MicroWSMO uses WSMO-Lite semantics and thus integrates RESTful services in our Semantic Web Service automation.

Introduction

Service-Oriented Architecture is commonly lauded as a silver bullet for Enterprise Application Integration, implementation of inter-organizational business processes, and even as a general solution for the development of all complex distributed applications. Although technology-independent, SOA is typically implemented using Web service technologies such as WSDL, SOAP, and the other so-called WS–F standards. More recently,Web technologies (HTTP, XML), which underlie machine-orientedWeb applications and APIs, are increasingly being used to provide what is commonly referred to as RESTful Web services.

Despite the appealing characteristics of service-orientation principles and technologies, their application remains largely limited to large corporations and, effectively, we are still far from truly benefiting from the promised simplicity for constructing agile and interoperable systems. To address this, Semantic Web Services (SWS) combine Web services with semantic technologies in order to better support the discovery, composition and execution of Web services. Top-down approaches to the development of Semantic Web Services, e.g. WSMO and OWL-S, provide highly expressive frameworks for describing Web services in a way that can support further automation for discovering or composing services. However, a large-scale uptake of these solutions is still to be witnessed.

Arguably, the main limitation of these approaches is probably their complexity both from a computational and from a knowledge-acquisition perspective. In the light of this limitation, the W3C recently finished a lightweight bottom-up specification for adding semantic annotations to WSDL (SAWSDL, see [2]). Within the European research project SOA4All¹, we have combined this new standard with the ideas and algorithms of earlier SWS frameworks, especially WSMO, to develop a lightweight approach for semantic description of Web services, which consists of two parts:

• WSMO-Lite is an ontology of service semantics which fits directly in SAWSDLannotations,
• and MicroWSMO is an equivalent of SAWSDL for RESTful services, whichsupports integration of Web APIs with more traditional Web services.

In this article, we give a brief overview of these two technologies that make SWS automation available to Web services practitioners.

WSMO-Lite Service Semantics

For describing the semantic aspects of Web services and APIs, we distinguish four types of service semantics:

• Functional semantics defines service functionality, that is, what a service can offer to its clients when it is invoked.
• Nonfunctional semantics defines any incidental details specific to the implementationor running environment of a service, such as its price or quality of service.
• Behavioral semantics specifies the protocol (ordering of operations) that a clientneeds to follow when consuming a service’s functionality.
• Information model defines the semantics of input, output and fault messages

Functional semantics describe formally what the service does. This information is necessary for finding services that are suitable for a given goal, and composing them together in business processes or mash-ups.

We offer two mechanisms for representing functional semantics: simple taxonomies and more expressive preconditions and effects. The simpler approach uses functionality taxonomies (such as ecl@ss²) to define service functionalities through a hierarchy of categories. This is the age-old cataloguing approach (also in use in UDDI) enhanced with semantic inference possibilities. WSMO-Lite offers the RDFS class wsl:FunctionalClassificationRoot to distinguish functional classification hierarchies from ontologies with other purposes.

When more expressivity is required, the functionality of a service can be specified using logical expressions that capture the preconditions and effects of the service. In WSMO-Lite, we have the classes wsl:Condition and wsl:Effect to mark such expressions. To specify the functional semantics of a concrete WSDL service, we use the SAWSDL modelReference attribute on the WSDL service or interface (a.k.a. portType) components. The attribute value identifies the functionality categories, the preconditions and the effects using URIs:

<wsdl:interface name=”BookStoreInterface”
sawsdl:modelReference=
 ”http://example.com/services/ecommerce/books”>
...
</wsdl:interface>

Nonfunctional semantics are represented using some ontology, semantically capturing nonfunctional properties such as the pricing, quality of service, or various policies. Nonfunctional semantics mainly serve to rank the discovered services. WSMO-Lite provides the class wsl:NonfunctionalParameter to mark concrete pieces of nonfunctional semantics. Since nonfunctional properties are service-specific, they are specified by including their URIs in the modelReference attribute on the WSDL service component.

Behavioral semantics describe how the client should communicate with a service, by capturing control dependencies among the operations of the service. Behavioral descriptions are naturally necessary for automated service invocation, but they are also very useful for creating service compositions and verifying, for instance, the absence of deadlocks.

In WSMO-Lite, we represent behavioral semantics with functional descriptions of the operations, i.e., using functional classifications and/or preconditions and effects; the URIs of these pieces of functional descriptions are put as modelReference values on the WSDL operation components. The client can then reason flexibly about which operations can be invoked in any particular state, and which ones will lead to the desired outcome.

Finally, the information model captures the semantics of the data exchanged between a service and its clients. Understanding the data is crucial for automated invocation, so the client and the service can successfully communicate, and also for composition, where the resulting process (or mash-up) needs to take into account and mediate any data heterogeneities.

Ontologies are used in WSMO-Lite to capture information models; such ontologies can be marked as wsl:Ontology to point out that they are intended as information models. To tie the WSDL service description of a service with its information model, SAWSDL specifies the use of modelReference to point from XML Schema components to the proper elements of the ontology. Additionally, because Web services generally work with application-specific XML data, whereas the semantic clients deal with semantic data, e.g. in RDF, SAWSDL introduces two attributes that carry pointers to the necessary lifting and lowering (from XML to RDF and vice versa) data transformations. The attributes called liftingSchemaMapping and loweringSchemaMapping are placed alongside the model references on the appropriate XML Schema components.

Figure 1 shows the complete definition of the simple WSMO-Lite service semantics ontology, serialized in Notation 3.³ Table 1 illustrates the modularity of WSMO-Lite: it shows what kinds of semantics are necessary (or useful but optional) for automating the various tasks involved in the use of Web services. Service discovery generally only needs the functional semantics of the available services. Service ranking can use any kind of information but it mostly relies on nonfunctional properties. The most complex of the tasks is composition, which first discovers the services that solve a part of the problem at hand, and then it needs to connect in the right ways the appropriate operations and data.

The table shows that even partial semantic annotations can be useful for semantic automation—with such a modular approach, WSMO-Lite aims to lower the barrier of entry to applications of semantic in service-oriented environments.

The full specification of WSMO-Lite is available at http://cms-wg.sti2.org/TR/d11/.

MicroWSMO: AnnotatingWeb API Documentation

So far, we have discussed WSDL-basedWeb services, which are based on technologies with significant industry backing. With the newest wave of social and interactive Web sites and applications, commonly referred to as Web 2.0, we have seen the advent of RESTful⁴ Web services. Web sites with major content contributions from their user communities have a strong interest on making it easier for the users to contribute; therefore they provide programmatic APIs that enable third-party tools to access the Web applications. While the earlier SWS frameworks have effectively ignored RESTful Web services, we provide a way to integrate them in semantic automation together with traditional, WSDL-based services.

In contrast to traditional distributed computing technologies, distributed systems on the Web do not use any interface description language (such as WSDL). Instead, RESTful applications are supposed to be largely self-describing, and the majority of Web API providers simply describe their services in textual (HTML) documentation. We have developed two microformats to be used on API documentation to give it machine-readable structure and to add semantic annotations:

• hRESTS (HTML for RESTful Services) is added to HTML documentation toidentify the service, its operations and their input and output messages,
• and MicroWSMO extends hRESTS with SAWSDL-like hooks for semantic annotations.

Web applications (and RESTfulWeb services) are made up ofWeb resources. Even though the four methods of HTTP (GET, POST, PUT and DELETE) dictate the interface of Web resources, on a higher level of abstraction we can identify operations that the client must perform while communicating with a service: log in (POST credentials to authorization resource), search in a product catalogue (fill in a form and GET searchresults), add a product to a shopping basket (POST product info to basket resource) etc.

Web API documentation is therefore naturally split into the methods that the API provides⁵. The key task for the hRESTS microformat is to identify the operations unambiguously in the HTML pages. Together with the label of an operation, hRESTS points out the URI address of the resource that handles the operation, and the HTTP method that the operation uses. hRESTS also identifies blocks within the documentation that describe the inputs and the outputs of an operation. In effect, hRESTS is a counterpart of WSDL, with a vocabulary limited to service, operation, address, method, input, output and label.

With the hRESTS structure in place, HTML service descriptions (which are now machine-processable as well as human-readable) can be annotated with pointers to the semantics of the service. MicroWSMO is a microformat that extends hRESTS with three properties: model, lifting and lowering. These are direct translations of SAWSDL modelReference, liftingSchemaMapping and loweringSchemaMapping attributes.

MicroWSMO allows WSMO-Lite semantics to be added to descriptions of RESTful Web services. Functional and nonfunctional semantics are model references on the service, behavioral semantics are in model references on the operations, and information semantics are captured on the input and output messages. In most of its processing, a semantic client can treat WSDL-based and RESTful services equally; only automated invocation needs to know whether to send a SOAP message or to form an HTTP request.

The full specification of hRESTS and MicroWSMO is available at http://cms-wg.sti2.org/TR/d12/.

Outlook for Lightweight Semantics

The use of lightweight annotation mechanisms such as SAWSDL and hRESTS makes it possible to add semantics to service and API descriptions incrementally, as shown in Table 1, without the need to adopt a complete framework such as OWL-S or WSMO. The extent of semantic annotations, and the expressivity (and computational complexity) of the used knowledge-representation languages, is determined by the requirements on automation, i.e., by the tasks that must be automated. Enterprises can choose economically-viable small steps and adopt semantics only where it is appropriate.

Within the SOA4All project, we are applying WSMO-Lite and MicroWSMO in diverse use cases that apply SOA in local government, in an e-commerce platform, and in social-networking applications. We will develop tooling for both authoring and use of semantic annotations; however, WSMO-Lite and MicroWSMO can give benefits even without extensive tool support.

After all, as they say, “a little semantics goes a long way.”

For more details, the reader may be interested in [2, 3, 1]

References
[1] Jacek Kopeck´y, Karthik Gomadam, and Tomas Vitvar. hRESTS: an HTML Microformat
for Describing RESTful Web Services. In Proceedings of the 2008
IEEE/WIC/ACM International Conference on Web Intelligence (WI-08), Sydney,
Australia, 2008.
[2] Jacek Kopeck´y, Tomas Vitvar, Carine Bournez, and Joel Farrell. SAWSDL: Semantic
Annotations for WSDL and XML Schema. IEEE Internet Computing,
11(6):60–67, 2007.
[3] Tomas Vitvar, Jacek Kopeck´y, Jana Viskova, and Dieter Fensel. WSMO-Lite Annotations
for Web Services. In The Semantic Web: Research and Applications,
5th European Semantic Web Conference, ESWC 2008, pages 674–689, Tenerife,
Spain, 2008. Springer.

Footnotes
1 http://www.soa4all.eu/
2 eCl@ss Standardized Material and Service Classification, eclass-online.com
3 http://www.w3.org/DesignIssues/Notation3.html
4 The adjective RESTful comes from adhering to REST, the architectural style of the Web.
5 For example, see http://www.flickr.com/services/api/.