Semantic Web

The semantic web effort is aimed at transforming the web, currently constructed so to be browsed, sought, and used by humans, in a platform that allows the automatic retrieval and invocation of resources by machines themselves. To this aim, the first necessary step is to enrich the representation of web resources by means of semantic information represented so to be machine-interpretable. A second aspect of the transformation to which the web is undergoing, is that resources more and more often are functionalities, software or hardware devices, such as weather forecast services or web-cams. Hardware/software devices accessible via the web are called “web services”. In this context, there is is a growing need of allowing the users to perform tasks that require the retrieval of services based on the description of their function and also their composition, aimed at executing complex tasks. For instance, organizing a trip might require the use of services for booking train tickets, reserving a room at a hotel and checking bus schedules. These tasks are currently executed by the user him/herself, but it is desirable to develop techniques for retrieving and composing services in an automatic way. One possibility is to use the techniques, developed in Artificial Intelligence, for performing symbolic

manipulation (e.g. reasoning techniques). To this aim, it is necessary to have access to a high-level description of the functionalities of the service and, in particular, to how it works. In the literature it is already possible to find a few proposals of languages for web service description and for the description of their interactions, i.e. OWL-S [54] and WSDL/BPEL4WS [17, 13].

Languages for Web Services representation OWL-S, BPEL4WS

As the huge amount of information on the web urged the development of standard languages for representing the semantics behind the HTML (e.g. RDF [57], OWL [53]), recently some attempt to standardize the description of web services has been carried on (OWL-S –previously DAML-S– [54, 18], WSDL [68], BPEL4WS). The use of standard descriptions is aimed at allowing the automatic discovery of web services, their automatic execution and monitoring, and (the task we will focus on in this paper) automatic composition.

While the BPEL/WSDL initiative is mainly carried on by the commercial world, with the aim of standardizing registration, look-up mechanisms and interoperability, OWL-S is more concerned with providing greater expressiveness to service description in a way that can be reasoned about [15]. In particular, a service description has three conceptual levels: the profile, used for advertising and discovery, the process model, that describes how a service works, and the grounding, that describes how an agent can access the service.

More precisely, three parties are involved in a web service transaction: the service requester, the provider, and some infrastructure components. The service requester seeks a service provider to which delegate the execution of a task. In an open environment such as the Internet, the requester may not know ahead of time of the existence of the provider; in order to find one, it relies on infrastructure components, that act like registries. Within the OWL-S framework, the service profile provides a way to describe the services offered by the providers, and the services needed by the requesters. An OWL-S profile describes a service as a function of three types of information: which organization provides the service (contact information), what function the service computes (the performed transformation described in terms of required inputs and produced outputs, plus conditions on the environment that must be satisfied in order for the transformation to occur and produce results), and the characteristics of the service (the categorization of the service w.r.t. to a reference ontology).

A service profile provides a concise description of the service to a registry, and ideally its only purpose is advertisement. Once the service has been selected, however, the requester will control the interaction with the service by means of the process model. In particular, the process model describes a service as an atomic, a simple or a composite process in a way inspired by the language Golog and its extensions [44, 28, 48]. Atomic processes are directly invocable, they have no subprocesses, and execute in a single step. Simple processes, instead, conceived of as elements of abstraction; for instance they can be considered as a simplified view of a composite process. Composite processes are decomposable into simpler processes. Their structure can be specified by using the following control constructs: sequence, split, split + join, choice, unordered, condition, if-then-else, iterate, repeat-while, and repeat-until. Such a decomposition normally shows, among other things, how the various inputs of the process are accepted by particular subprocesses, and how its various outputs are returned by particular subprocesses.

In this perspective, a wide variety of agent technologies based upon the action metaphor can be used. In fact, we can view a service as an action (atomic or complex) with preconditions and effects, that modifies the state of the world and the state of agents that work in the world.

The process model can, then, be viewed as the description of such an action; therefore, it is possible to design agents, which apply techniques for reasoning about actions and change to web service process models for producing new, composite, and customized services.

The task of web service composition in the OWL-S context has been faced by some re-searchers. The most relevant work has been carried on by McIlraith et al. [15].

The basic idea is that services correspond to atomic actions, whose composition is based on their preconditions and effects. In particular, the precondition and effect, input and output lists are flat; no relation among them can be expressed, so it is impossible to understand if a service can follows an interaction protocol that allows various interactions. Indeed, the advantage of working at the protocols level is that by reasoning about protocols agents can personalize the interaction by selecting a course that satisfies user- (or service-) given requirements. This process can be started before the actual interaction takes place and can be exploited for web service composition as well as for web service search.

An alternative language to OWL-S is BPEL4WS (Business Process Execution Language for Web Services [13]), a notation for specifying business process behavior based on Web Services.

In this approach, a business process is either executable, and in this case it models the actual behavior of a participant in a business interaction, or it is a so called business protocol, i.e. a description of the mutually visible message exchange behavior of each of the involved parties, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. BPEL4WS was born to overcome the limits of WSDL, the W3C standard language for web service description. The interaction model supplied by WSDL is essentially a stateless model of synchronous or asynchronous interactions. However, models for business interactions typically assume sequences of (either synchronous or asynchronous) message exchanges, within stateful, long-running interactions involving two or more parties.

To define such interactions, a formal description of the used message exchange protocols is needed, in which the mutually visible message exchange behavior of each of the parties is clearly specified, without revealing the internal implementation of the involved processes. BPEL4WS separates “transparent” data, i.e. data relevant to public aspects, as opposed to “opaque”

data, that internal/private functions use. Transparent data directly affects the public business protocol, whereas opaque data is significant to back-end systems and affects the protocol only by creating nondeterminism. Going back to the ticket booking example, the (non)availability of a sufficient number of seats would be opaque data, and cause nondeterminism. BPEL4WS explicitly allows the use of nondeterministic data values to make it possible to capture the essence of public behavior while hiding private aspects. The language is layered on top of several XML specifications (WSDL 1.1, XML Schema 1.0, and XPath1.0) but makes no use of semantic information; in particular, WSDL messages and XML Schema type definitions provide the data model used by BPEL4WS processes. The language is quite rich and, for each received message, it allows the definition of activity to execute by means of the following operators:

receive, reply, invoke, assign, throw, terminate, wait, empty, sequence, switch, while, pick, flow, scope, compensate.

Research on the use of planning techniques for composing web services described by means of BPEL4WS has been carried on by some researchers, such as the one by Pistore, Traverso and Bertoli.