Semantic web services achieve e ects in the world through web services, so the connection to those services|the grounding|is of paramount importance. The established technique is to use XML-based translations between ontologies and the SOAP message formats of the services, but these mappings cannot address the growing number of non-SOAP services, and step outside the ontological world to describe the mapping. We present an approach which draws the service's interface into the ontology: we de ne ontology objects which represent the whole HTTP message, and use backward-chaining rules to translate between semantic service invocation instances and the HTTP messages passed to and from the service. We present a case study using Amazon's popular Simple Storage Service.
Semantic web services are implemented on top of conventional, syntactic web
services. The connection between the two|the grounding |must enable an actual
web service to be invoked based on the content of a semantic description of a
service invocation. The conventional approach taken by all the major semantic
services frameworks [1{3] is to use an XML mapping language to translate between
the two. This naturally doesn't work for non-XML services, such as many of the
growing number of RESTful services [
(HTTP messages) as ontological objects, and uses backward chaining rules to direct the translations between the semantic service invocation and the low-level data formats required by the service (section 3). As a case study, we take the
authentication process precludes its description by WSDL or WADL (section 4).
and the broker's ontological hooks for the grounding procedure, and put them
together in a description of Amazon's service (section 5). The ontologies and
grounding have been implmented in the Internet Reasoning Service broker [
Semantic web services rely on normal web services to source and manipulate information and to e ect change in the world. This requires that semantic service brokers translate between the world of domain theories, represented in some ontology language, and the on-the-wire data formats and protocols that are the language of the target web services. For semantic web services to be taken seriously by practitioners, groundings must be able to organise communication with a comprehensive subset of real, deployed web services.
web services stack, colloquially known as `WS-*'. As the complexity of the WS-*
stack has increased, SOAP's hegemony has ebbed, with many services being
o ered using lighter weight alternatives. The genuinely simple protocol which
inspired SOAP has re-emerged in its own right as XML-RPC [
evangelist Je Barr, around 80% of invocations of Amazon's services are done through the REST interface1. Yahoo! does not provide a SOAP interface at all, and has no intention of adding one2. Flickr, a popular photo-sharing website, provides its API in all three web service avours: SOAP, XML-RPC, and RESTful.
third-party bindings3 for the most popular languages target the SOAP variant:
ickrj Java REST phpFlickr PHP REST jickr Java REST ickr.py Python REST
2.1 Invoking syntactic web services
we should rst look at how the various service types are invoked. In SOAP, the connection proceeds at two levels: the HTTP connection, and the XML message.
URL of the service, and an HTTP header named SOAPAction, which the server
uses to dispatch internally. With SOAP, most of the information required for
service invocation is encoded in an XML message which comprises the content of
an HTTP POST request4. This leads to the conception of groundings as simply
translations at the XML level from some ontological representation to an XML
1 http://www.jeff-barr.com/?p=96
2 http://developer.yahoo.com/faq/#soap
3 http://www.flickr.com/services/api/
4 SOAP abstracts away from the transport, but in practise it is used almost exclusively
with HTTP, and it is highly questionable whether a system not using HTTP can
legitimately be called a `Web' service [
POST http: // www . world - weather . org / soap SOAPAction: WeatherReport <? xml version =" 1.0 "? > < soap:Envelope xmlns:soap =" http: // schemas . xmlsoap . org / soap / envelope /" xmlns:xsd =" http: // www . w3 . org /2001/ XMLSchema " xmlns:w =" http: // www . weather . ex / soap /" > < soap:Body > < w:GetWeatherReport >
< w:Country > Italy </ w:Country >< w:City >Rome </ w:City > </ w:GetWeatherReport > </ soap:Body > </ soap:Envelope >
nor the large number of XML namespace declarations. Unlike SOAP, XML-RPC relies on HTTP as more than a transport protocol. For example, authentication is handled at the HTTP level, so the Authorization header must be accessible to the grounding.
Representational State Transfer, better known as REST [
and some of the service parameters|country and city names, and forecast date.
description of the weather, or a graphic illustration of the weather over Rome.
rarely, if ever, furnished by the service provider. 3
need to reconsider the desiderata for a grounding scheme. For us, we needed a grounding which could address REST services, but which would also support
and other data formats.
Principle 1 enables us to support the three web services approaches today, and gives us some degree of future-proo ng. Principle 2 allows us to describe, for example, services that return images. Principle 3 frees the semantic web services description from the service provider. If a service's WSDL description is not available, or incorrect, we should not be prevented from creating a grounding if we can otherwise discover the interface, through reverse engineering or reading documentation. Nor should we expect the provider to link to our semantic description of their service: it is our description, and they have no obligation to trust or advertise it. Principle 4 is just the application of Ockham's razor: the fewer languages the engineer must deal with, the better. But it also retains the possibility of reasoning over the grounding, for instance in data mediation. More philosophically, if we are truly convinced of the power of ontologies to model such things, it seems odd to avoid their use at this point.
This thought leads to our approach: we model, in a series of ontologies, the various protocols and encodings needed to invoke web services. Each facet of the process is represented by its own ontology: a pure HTTP ontology; a cryptography ontology; and the IRS speci c ontology which allows us to map from service invocations to data on the wire. While our ontologies were developed for the purpose of supporting groundings, they could in principle be general purpose ontologies developed for other uses in the respective domains. To invoke a web service, a WSMO broker follows this procedure: 1. A user invokes a semantic services goal by calling the broker with a goal name and the parameters. 2. After some processing by mediators, a web service invocation instance is created. The invocation object holds the service name, input parameters, and slots to hold the return values from the web service.
based on the service invocation object, with its various slots' values set to re ect the parameters from the the service invocation object.
object directly into a request on the network.
in this paper is step 3. The two rules we call lower and lift, which respectively `lower' and `lift' the service request object to an implementation level and back.
( lower ? service-type ? service-instance ? http-request ) ( lift ? service-type ? http-response ? service-instance ) The rst argument, ?service-type, allows each service to have its own implementation, dispatched on the value of the ?service-type argument. The lower rule is a series of subgoals whose successful ful lment leads to the instantiation of ?http-request, which can then be interpreted by the broker to call the web service. When a response is received from the server, the lift rule runs on the same ?service-instance, and the newly returned ?http-response, modifying the original ?service-instance frame to record the return value.
uses OCML [
to de ne the operational semantics of ontological components directly in Lisp. 4
targeting of a real-world web service in the context of our work in the Living
about the human musculoskeletal system, along with web services to visualise and manipulate it. The medical imaging and motion data, from MRI scans, dissection and gait analysis, is stored in repositories accessed and managed by
use semantics to manage and integrate them with external services.
A key aim of LHDL is to enable the storing and sharing of the research data, but the data les commonly range in size from hundreds of megabytes to several gigabytes. It would be bene cial if we could outsource the storage and transfer of this data, and several major web services providers have recently begun o ering such facilities. We decided to use Amazon's `simple storage service' (S3) as our test-bed. Amazon's S3 is a commercial service, with charging being a function of storage and data transfer (in Gigabytes per month), and number of HTTP operations.
Storage at S3 is organised by `buckets' and `keys', which are analogous to directories and les in le systems. Buckets live in a global namespace, and users can create new ones provided the name is currently unused. Within a bucket, the owner has control over the keys and the objects they name, as well as access control for other users. A user is identi ed by an `access key', and authorised by means of a `secret key'. Buckets are created by executing a PUT to the bucket's corresponding URL. The following HTTP request instructs S3 to store the string `Hello, world!' in the object with key hello in the bucket lhdl: PUT / lhdl / hello HTTP /1.1 Host : s3. amazonaws .com Authorization : AWS 5 EB1K7DR13JHNF92JV23 : CwuLdze7uX4LLP + KGMe /5 htHb20 = Date : Fri , 26 Sep 2008 21:33:39 GMT Content - Type : text / plain Content - Length : 13 Hello , world !
the HMAC-SHA1 hash) of the HTTP request itself, created with the user's secret key. Figure 1 shows the grammar provided by Amazon specifying the signature's content. Since a request's Date header must agree with that on the Amazon servers (within a narrow margin of error), the above request would not work now.
cannot be generated before the date is decided. Since the date is only decided at
the HTTP layer, they must both be done as part of the same process in the broker,
and with one control procedure being responsible. These features make S3's
interface impossible to capture in WSDL [
Authorization =
" AWS " + " " + AWSAccessKeyId + ":" + Signature ; Signature =
Base64 ( HMAC - SHA1 (UTF -8 - Encoding - Of ( StringToSign ))); StringToSign =
HTTP - Verb + "\ n" + Content - MD5 + "\ n" + Content - Type + "\ n" + Date + "\ n" + CanonicalizedAmzHeaders +
CanonicalizedResource ; CanonicalizedResource = [ "/" + Bucket ] + <HTTP - Request -URI , from the protocol name up to the query string > Having seen our overall approach, and our target web service, we are now in a position to present the ontologies: one each for the IRS broker, HTTP protocol, cryptographic operations, and the Amazon service description itself. In OCML, namespaced symbols are written #_namespace:localName. A symbol #_localName without a namespace refers to the current namespace. In this paper, the namespace pre xes map to ontologies as follows:
irs ! irs The broker's grounding interface rfc2616 ! rfc2616 HTTP protocol crypt ! cryptography Cryptography store ! storage Amazon S3 services
named rfc2616, for the IETF standard for HTTP/1.1 [
( ironclad : ascii-string-to-byte-array key ) : sha1 ))) ( ironclad : update-hmac hmac ( ironclad : ascii-string-to-byte-array data )) ( ironclad : hmac-digest hmac ))) ( def-function # _encode-base64 ( octets ) " Encode OCTETS into base 64 ASCII ." : lisp-fun #' base64 : usb8-array-to-base64-string )
Figure 3 shows the key parts of the storage ontology which holds the description of the S3 service for getting objects from the server. The class amazon-get-object-service models the web service, where it is characterised by input and output roles. Those are typed by the ve domain classes which relate to the S3 concepts of buckets, object keys, access keys, and secret keys, with the latter two being tied together in an account structure. The description shown omits several WSMO elements related to choreographies, capabilities and so on which are not relevant here. Figure 3 contains the lifting and lowering rules. Note that the lift-for-get-object recovers not just the content of the HTTP message, but the Content-Type header, too. For S3, this is important because arbitrary data types can be stored, and S3 records the type speci ed at upload time and returns when the object is downloaded.
creation of a new frame instance, the ?http-request, and the date and host elds being set up. The target bucket and key objects are recovered from the service invocation with the slot-value relation, and are used to create the URL. The HTTP object's URL and method slots are set appropriately. Finally, the keys are recovered from the account, and used to sign the request. The signature itself is controlled by the rule sign-amazon, whose structure parallels that of the grammar provided in Amazon's documentation as shown in gure 1. Fig. 3. The get-object service, lower and lift rules, and digital signature function.
birth of web services. Both OWL-S [
descriptions in various frameworks. SA-WSDL uses mapping schemas to handle
the lifting and lowering, but again it is XML speci c. The IRS [
uses service-speci c `adaptors', written in Java, to connect to services.
well established, it does not address aspects of the HTTP protocol like the
services that do not use XML. Although WSDL and SOAP are products of the
complexity, interoperability, and their lack of Web nature. Personal experience has made us skeptical of the quality of WSDL and XSD descriptions, even, or perhaps especially, machine generated ones. Finally, using an XML mapping scheme like XSLT forces the ontology engineer to leave the semantic realm to work on the groundings, and to consider the domain objects in terms of their
In contrast, our groundings unify the lifting and lowering with the management of the HTTP protocol, and are declarative and wholly within the ontology language, modulo the small number of operational primitives such as the cryptography functions. Since there are relatively few data encoding and cryptography schemes| many orders of magnitude fewer than there will be web services|it makes sense to embed them in semantic brokers, and make them available to ontology rules. With these hooks in place, we can encode groundings to a large number of important, real-world web services in a uni ed, ontology-based manner. 7
we introduced an approach to groundings rooted in ontologies and rules. A set of ontologies for modelling aspects of web service implementation was introduced, allowing us to use the ontological language itself to express the grounding, including the `lifting and lowering' to string serialisations of data structures. We used these to describe a popular commercial REST web service, Amazon's S3.
currently support the automated transfer of le resources in the LHDL project (http://lhdl.open.ac.uk:8080/irs).
We see this approach as a useful low-level implementation platform: it is su ciently powerful to connect to any kind of HTTP service, and yet is fully accessible from the ontological level. It is general enough, for instance, that it could support multi-part MIME messages. We intend to add ontologies for reasoning directly with XML, XML-RPC, and SOAP messages, which currently must be accessed by direct manipulation of the XML string representation. On top of this, we expect to layer generic rules which will handle any services which have WSDL or WADL de nitions, as well as semantic approaches like SA-WSDL.