The Service Oriented Architecture paradigm, and its implementation based on Web Services, have been the object of an intense research and standardization activity. One of the most challenging open research issues is the discovery of Web Services on the base of the functionality they o®er. Several proposals, including WSMO and OWL-S, rely on Semantic Web technologies to enrich service descriptions with semantic information about the o®ered functionalities. Current solutions however mainly focus on ontological aspects. In this paper we focus instead on aspects related to web service interaction. We present an application framework that addresses the service discovery problem by accommodating both the ontological and the interaction perspectives. It does so by reasoning with a number of ingredients that specify how web services and users interact: web service semantic descriptions and declarative rules, and user goals, parameters and policies. The aim of our framework is to discover and propose to user services which (1) ontologically ful¯ll the requested functionalities, and (2) allow the user to interact with the services and possibly achieve her goals, without violating her policies.
Service Oriented Architecture (SOA) and Web Services are rapidly emerging as
standard architectures for distributed application development. The adoptions
of well-known network protocols and communication standards have solved
interoperability and heterogeneity issues at the level of hardware and software.
Eventually, the use of o®-the-shelf solutions/services is becoming possible,
although concerns about the adoption of such components have been raised. In
particular, the search of software components on the basis of the
functionality they provide, rather than on some syntactical property, is still an open
research matter. To this end, some authors identify Semantic Web technologies as
a promising way to address this issue [
eShop2
eShop3 eShop1 eShop2
eShop1 eShop2 descriptions by semantic information that can be used to search for Semantic Web Services (SWS).
In our view, searching for a service means to identify such components that i) can potentially satisfy the user needs in terms of outputs and e®ects, and ii) can be invoked by the customer and interact with her without violating her interaction policies. An example of interaction policy could be a user constraint that prevents providing a credit card number to a service which is not certi¯ed, or a service constraint that prevents to accept credit card payments for items out of stock or with more than 30 % discount. Hence, a user request contains not only a description (given in semantic terms) of the user desires, but also the user policies, which we call the \behavioural interface."
We consider the search of a SWS as the process of identifying, among a given
set of services, those components that both satisfy the ontological requirements
(i.e., they provide the requested functionality), and the constraints on interaction
(i.e., they support the requested behaviour). Following [
In previous work [
Building on [
User Alice forgot to buy her brother a Christmas present and now she is desperately searching the Internet for an online shops that sells the last crime ¯ction novel featuring Inspector Montalbano. She is particularly worried because she needs to ¯nd a shop that delivers in 3 days, and o®ers a gift wrapping service. She can pay by Mastercard, PayPal, or bank transfer.
eShop1 is the biggest Internet book seller, and through its semantic web services it provides every type of books. Its services are advertised with the generic term \book". Moreover, it has some policies about the delivery: fast delivery (one working day) is allowed only if payment is performed by means of bank transfer; otherwise, standard delivery (one week) is the default option. Gift wrapping is possible, but only with standard delivery.
eShop2 is a small internet seller, specialized in crime ¯ction books only. Its service advertisements use again the generic term \book," and it accepts \credit card" payment. The shop o®ers fast delivery, and gift wrapping without restrictions.
eShop3 is a huge, consumer electronics chain, which advertise its internet service as \selling anything." It accepts any payment method, supports only fast delivery and gift wrapping.
We envisage a scenario in which Alice queries our search engine, looking for a solution for her problem. Our application performs the discovery step, and the shops eShop1 and eShop2 are selected as possible services providing what Alice is looking for. However, this is not enough to guarantee that an interaction is possible. Due to its policies, gift wrapping and fast delivery are incompatible options for eShop1. Our application, during the contracting phase, reasons upon the policies of the services and the customer. It tries to generate a possible interaction plan where all the constraints are respected, and if it fails, the service is simply discarded. In this example, the only service that has a chance to ful¯ll Alice's requirements is eShop2, which is returned as a result from the search process. 2
Several, di®erent solutions have been proposed in order to describe a Semantic Web Service, and a vast literature is available on the topic. However, up to now no solution has been widely accepted, and a proper standard for de¯ning the semantics of a Web Service is still a matter of research. This is indeed, in our opinion, one of the most limiting factor for the adoption of SWS standards.
The two major proposals, the Web Service Modeling Ontology (WSMO [
In the current implementation of our application framework, we made a compromise, by choosing to keep ontological and behavioural aspects separate from each other. They are represented by two di®erent sets of information and stored in two di®erent ¯les. Ontological aspects are represented by means of an OWL-S 1.1 pro¯le, while behavioural properties are de¯ned using the SRE language. This allows us to keep our architecture open to other SWS description solutions, without giving up the powerful SRE formalism for representing the interaction issues. 2.1
The SCIFF Reasoning Engine (SRE, [
Policies Pws describe a web service's observable behaviour in terms of events (e.g., messages). SRE considers two types of events: those that one can directly control (e.g., if we consider the policies of a web service ws, a message generated by ws itself) and those that one cannot (e.g., messages that ws receives, or does not want to receive). Atoms denoted by H denote \controllable" events, those denoted by E and EN denote \passive" events, also named expectations. Since SRE reasons about possible future courses of events, both controllable events and expectations represent hypotheses on possible events. We restrict ourselves to the case of events being messages exchanged between the two parties in play. The notation is: { H(ws; ws0; M; T ) denotes a message with sender ws, recipient ws0, and content M , which ws expects to be sending to ws0 at a time T ; { E(ws0; ws; M; T ) denotes a message with sender ws0, recipient ws, and content M , which ws expects ws0 to be sending at a time T ; { EN(ws0; ws; M; T ) denotes a message with sender ws0, recipient ws, and content M , which ws expects ws0 not to be sending at a time T .
In other words, H denotes messages that the sender expects to be sending, and E/EN denote messages that the recipient expects (not) to be receiving. For example, if eShop1's policies contain H(alice; eShop; hello; 10pm), the interpretation is: \alice expects to be saying hello to me at 10pm," or, more simply, since alice is in fact responsible for producing such an event, \alice says hello to me at 10pm."
Note that message content, sender, recipient, and time can also be partially or totally left (un)speci¯ed. For example, the notation allows us to express that service ws expects a message from some other web service, but does not know the message content, sender, nor time yet. Moreover, it is possible to pose constraints on such elements, for example it is possible to say that a message must match with a certain pattern, or that its time must fall within a certain interval.
More formally, web service speci¯cations in SRE are relations among
expected events, expressed in the SCIFF [
Each integrity constraint in Pws is a rule in the form Body ! Head. The Body of an IC is a conjunction of events, literals and CLP constraints; the Head is either a disjunction of conjunctions of events, literals and CLP constraints, or false. The operational reading of ICs is similar to that of forward rules: whenever the body becomes true, the head is also made true.
For example, eShop1's policy about gift wrapping being available only with standard delivery can be expressed as follow:
H(Customer; eShop1; request(Book id); Tr) H(Customer; eShop1; select option(gif t wrap); To) (eShop1) !E(Customer; eShop1; select delivery(standard); Td) ^ Td < To
^ H(eShop1; Customer; deliver(Book id; delivery(standard)); Ta) ^ Ta > To:
Policy eShop1 has the following meaning: if a Customer has requested an item
with id Book id, and the gif t wrap option, then eShop1 expects (i.e., requires)
that the Customer has beforehand selected standard delivery, and it expects
1 For an introduction to ALP, see [
SRE reasons by considering a goal, expressed as a conjunction of events and constraints (e.g., \alice expects (wants) to buy a book, and it wants it to be wrapped and delivered within 3 days"), and by ¯ring integrity constraints whose body is veri¯ed by matching events. 3
As in [
The contracting phase then focuses its attention on the interaction policies, i.e., on the set of rules that each partner has declared as representing its behavioural interface. Here the problem consists of deciding whether an interaction can e®ectively happen, with the further constraint that such interaction should also achieve the user goals. Besides the interaction issue, again an ontological problem must be faced: user and service policies could be de¯ned using di®erent terms (referring to di®erent ontologies or to related but di®erent concepts). Our framework uses ontological reasoners to cope with this problem. 3.1
In our framework the discovery phase has been implemented following the
algorithm proposed by Paolucci et al. in [
More speci¯cally, request and a service outputs match if for each output parameter of the request there is a matching output parameter in the service description. Inputs match if for each service input there is a matching request input. Each output parameter in the request is checked against all the output parameters of the service; similarly, each input parameter of the service is checked against all the input parameters in the user request.
Paolucci et al. propose to analyze user request and service description parameters pairwise, and to classify them into four categories according to their matching level (for example, exact match is stronger than subsumption). The levels are: exact, plugin, subsume and fail.
Our implementation slightly di®ers from the algorithm described in [
Our application framework exploits the SRE framework in the contracting phase. Roughly speaking, the SRE engine tries to establish if there exists a possible sequence of events (exchanged messages) that respect the constraints of both the service and the user. If such interaction is possible, SRE comes up with a sort of a plan indicating the messages that should be exchanged. Note that the reasoning process is driven by the user goals: not all the possible interactions are of interest, but only those that lead to satisfying the user's needs.
We extend the SRE architecture presented in [
Second, a simple (and not complete) alignment process is carried out over the terms used in the rules for describing the interaction policies. To this end, the knowledge base of the service description is augmented with a set of predicates is a/2, and the underlying uni¯cation mechanism of the SCIFF proof procedure has been slightly modi¯ed to accommodate ontological subsumption relations. 4
The framework has been organized as a set of web services, each of them providing one functionality. We aimed to realize a modular architecture, with the intention of using the framework as a proof of concept of our solutions, and in particular of the SRE approach. Our framework provides two facilities: registering and querying. The ¯rst if provided by a component used by service providers, which can register a service description given as the pair OWL-S pro¯le / SRE pro¯le. The second facility is provided by a component which enables the users
Service Description OWL-S Profile
SRE
Profile
User Request
IO SRE Requirements Profile
Matching Semantic Web Services e c i v r e S itr e s g e R e c i v r e S h c r a e S
Service Register OWL-S Profile
SRE Profile RDBMS
File
System Syntax Validator Service Seeker
Service Matcher SCIFF Reasoning Engine
MatchMaker (Ontology based) to submit their request, and which returns as an output a list of SWS that ful¯ll the user requirements.
The various web services composing our system are shown in Figure 2. Any interested Web Service can register itself at our application, by providing an OWL-S description together with a SRE description of the provided functionality and its behavioural policies. After a syntactic validation performed by the Syntax Validation module, the pair OWL-S description / SRE description are sent to the Service Register component who manages the storing procedures. In particular, it stores OWL-S pro¯les by means of a Relational Database, while SRE pro¯les are directly stored in the ¯le system. OWL-S pro¯les are pre-processed, and a summary of the pro¯le is extracted for each SWS: in particular, information about the referred ontology and the terms used for the inputs and the outputs description are explicitly stored in the database. This choice allows to simplify the matching algorithm described in Section 3.1 by means of ad-hoc, dynamically created SQL queries on the DBMS. If the storing procedure terminates successfully, an acknowledge is returned back to the service that required the registration of its pro¯les.
A user starts the query process by providing a request, composed of a
description of the functionality she is looking for, together with her behavioural
policies. The description of the desired service is given in terms of inputs and
outputs: however we assume such lists as a sort of \indication" of the needs of
the user, and a certain °exibility is adopted, as explained in Section 3.1. After
an initial syntactic validation step, is passed to the Service Seeker component,
who manages and coordinates the search process orchestrating the other
components. The input/outputl list is passed to the Service Matcher component that
selects, among the registered services, only those ones that could satisfy the user
request. To this end, the Service Matcher implements the algorithm explained
in Section 3.1. The ontology subsumption relation is evaluated by the
MatchMaker component, a simple wrapper for the Pellet reasoner [
The list of services selected by the Service Matcher is returned back to the Service Seeker, that in turn gives it to the SCIFF Reasoning Engine module. Such module reasons about the possibility and the existence of an interaction that could e®ectively satisfy the user needs, as explained in Section 3.2. Its outcomes consists of a restricted list of services together with, for each service, a possible interaction plan that i) justify why that service has been selected, and 2) shows how the user can successfully interact with the service. To overcome terminological issues, also the SCIFF Reasoning Engine module uses the MatchMaker and its integrated Pellet reasoner. Finally, the list of selected services is returned back to the user by the Service Seeker module. 5
Many authors tackled the service matching problem, considering both the
ontological and the interaction perspective. Among them, Kifer et al. propose a
comprehensive solution to the discovery and contracting problem in [
The architecture introduced in this paper is a ¯rst prototype, and from the software development viewpoint it is still in an alpha stage. Moreover, it suffers from many limitations we introduced to support °exibility and extensibility. E.g., we currently store service pro¯les using a relational DBMS. This enables a certain °exibility, but does not permit to take advantage of ontology-aware storing systems. We assumed also that all the service pro¯les and the user requests refer to the same set of ontologies, and that no alignment among ontology terms is required.
Nevertheless, the results of our preliminary test, conducted using OWL-S pro¯les available at http://projects.semwebcentral.org/, are encouraging. They show that our proposal for the service discovery and contracting problem is a viable solution, with the advantages of o®ering a powerful yet simple, declarative language for expressing service policies.
In the future, we intend to run a more comprehensive comparison with other
solutions, by considering both expressive power and computational performance.
We also plan to extend our application by providing support to other service
description languages, such as WSMO, SAWSDL and WSMO-Lite. Another
research direction we intend to pursue regards the integration between rules and
ontologies.This is perceived to be an important issue by the whole Semantic Web
community. Some initial work in this direction is presented in [
This research has been partially supported by the Italian MIUR PRIN 2007 project No 20077WWCR8, \Le Forme di Correlazione tra Italian Style, Flussi di Turismo e Trend di Consumo del Made in Italy", and by the Italian FIRB project TOCAI.IT. The prototype framework has been partially developed by F. Succi, M. Cavina, L. Acerbo and D. Pierangeli during their MEng project.