Automated Selection of Configurable Web Services.

Full text

Page 1

Automated Selection of Configurable Web Services
Steffen Lamparter, Anupriya Ankolekar
Institute AIFB
Universit¨ at Karlsruhe (TH)
Germany
{sla,aan}@aifb.uni-karlsruhe.de
Abstract
To bring service-oriented architectures to their full potential, automatic service discovery and
selectionmechanismsarerequired. Inthispaper, aserviceselectioncomponentispresentedthat
supports offers providing multiple configurations of a service. The selection algorithm ranks
the offered services and their configurations according to the requester’s preferences and thus
facilitates personalized selection strategies. In addition, the approach leverages existing Web
standards to provide a maximal degree of interoperability between service providers and their
customers leading to significant efficiency gains. The approach is implemented prototypically
and the performance is evaluated by means of a simulation.
1 Introduction
Service-oriented architectures (SOA) as a paradigm where applications are built by composing
loosely coupled, highly interoperable, reusable services have become increasingly popular in
recent years. This flexible style of implementing applications promises cost savings in software
development and faster adaption of business processes to changing environments. Realizing
such a flexibility requires automatic as well as efficient Web service discovery and selection
mechanisms. These mechanisms depend heavily on the way services are described. Approaches
that are solely based on WSDL-descriptions are inadequate since XML and XMLSchema do
not provide sufficient expressivity to create and relate rich datatypes [MM03]. Therefore, these
mechanisms are not amenable to a high degree of automation. In order to tackle this problem
several mechanisms have been proposed that depend on much richer service descriptions. Most
of them describe services using formal ontologies (e.g. WSMO [KLP+04], OWL-S [SPAS03],
WSDL-S [AFJ+05]). However, none of these approaches address the fact that Web services are
highly configurable products that can be offered by multiple parties (providers) with different
attributes and under different conditions. This enables a high degree of product differentiation
allowingproviderstocustomizetheirservicesaccordingtothespecificneedsoftheircustomers.
Clearly, this improves the utility of the transaction for both participants. Consider, for exam-
ple, a route planning web service, which offers the service of computing a road route between

Page 2

two locations. Various configurations of the service may take into account the current traf-
fic situation or weather situation when computing the route, or the service may be configured
to compute the shortest or quickest route, one that avoids small roads and so on. Naturally,
each configuration may have a different price attached. Decision making in markets with such
complex services generally requires that both seller pricing functions as well as buyer scoring
(preference) functions be taken into account.
In [LAO+06] a general policy framework is described that can be used to express pricing and
scoring functions. The framework relies on existing or emerging internet standards and thus
provides a high degree of interoperability. In this paper, we extend the work in several di-
rections. First, it is shown how the policy framework can be applied to describe configurable
Web service offers and requests. Second, the framework is augmented with an abstract selec-
tion model, which is independent from specific formalisms and implementations. Third, we
present an approach to rank offers in scenarios where both requests and offers are configurable.
In this context, we also show how preferences can be expressed directly within a query. The
selection algorithm in the previous work deals only either with configurable requests or con-
figurable offers, which are both stored in the knowledge base. Finally, we present a concrete
implementation and initial performance evaluations of the system.
The paper is structured as follows. In Section 2 an abstract selection model is presented. In
Section 3 this model is formalized with the standardized Web languages OWL, SWRL and
SPARQL in order to provide interoperablity between Web service requesters and providers.
After presenting an implementation and evaluation in Section 4, we discuss related work in
Section 5 and conclude the work with a short outlook in Section 6.
2 Abstract Selection Model
First, a selection is defined as a decision for the best available alternative, i.e. the Web service
that is most appropriate to fulfill a certain task. In general, decisions require a choice and criteria
by which different choices are judged. Hence, a selection can be regarded as an optimization
problem with a certain objective function resulting in an understanding of “better” and “worse”.
In this section, we first introduce an abstract notation of the fundamental concepts in the domain
and then present the optimization problem that has to be solved in order to derive a preference
structure over the service offers.
Definition 1 (Web Service Configuration) Let S = {s1,..., s|S|} be the set of all Web services.
Then, a Web service si∈ S is described by the tuple si= (Ii,Oi,Ci), where Iirepresent the
set of input messages that are required by the service siand Oithe set of output messages that
are returned by the service si, respectively. Furthermore, a Web service is characterized by a
set of feasible configurations Ciwith Ci⊆ C, where C is the cartesian product of the discrete

Page 3

service attributes A1,...,An, i.e. C =?
r∈{1,...,n}Ar. In this context, each c ∈ C is a vector
c = (a1k1,...,ajkj,...,ankn), where ajkjrepresents the kthvalue of attribute j.
Recall the route planing example mentioned in section 1. Here the set Iirepresents locations
and Oithe route between these locations. Moreover, we have three attributes: (i) The route type
which refers either to the quickest or cheapest route; (ii) one attribute that indicates whether
traffic information is taken into account; (iii) and one attribute that allows to include or ex-
clude weather information. These attributes are used to configure the service according to the
requesters preferences. For instance, one specific route service configuration is a routing func-
tionality that returns the quickest route including traffic and weather information. Note that
according to Definition 1, service functionality is solely defined by inputs as well as outputs
and attributes comprise only discrete and static non-functional service properties.
In order to enable Web service transactions between providers and customers, Web service
offers and requests have to be specified. Their main purpose is to attach prices as well as prefer-
ences to the service configurations. In the following, we formally define how offers and requests
canbespecifiedforconfigurableservices. Moregeneralapproach(e.g.includingdiscountrules)
see [BK05].
Definition 2 (Web Service Offer) Assume a set of providers P as well as a set of Web service
offers Θ. Then, p ∈ P is an arbitrary provider offering service op∈ Θ. A Web service offer
is characterized by a vector op= (sp,Gp), where sp∈ S represents the provided service and
Gp: Cp→ R the pricing function that assigns a certain price to each configuration c ∈ Cpof
the service sp. We assume that the pricing function is described by an additive function, where
gpjrepresents the pricing function of provider p for attribute j. wg
influence of the different attributes on the price.
jcan be used to adjust the
Gp(c) = Gp(a1k1,...,ajkj,...,ankn) =
n ?
j=1
wg
jgpj(ajkj) with
n ?
j=1
wg
j= 1(1)
That means an offer assigns an additive pricing function to a Web service description. The
pricing function maps the configurations contained in the service description to a certain price.
This approach allows for encoding pricing information in an efficient way. This is required
since adding price markup to each configuration would exhibit combinatorial features [BK05].
By means of Function 1, the provider has to define only n pricing functions instead of adding
?
eight configurations. Of course, for more complex services the efficiency gains are much higher.
In the following, a Web service request is defined analogously.
j=1,...,n|Aj| price markups. For instance, in the simple route planning example, pricing infor-
mation can be expressed via six attribute value/price-tuples instead of adding price markups to

Page 4

Definition 3 (Web Service Request) Given a set of customers B, a Web service request is de-
fined as a vector rb= (sb,Fb), where b ∈ B is the issuer of the request and sb∈ S the requested
service. The preferences of the customer are defined by a standard additive scoring function
Fb: Cb→ R that assigns a certain score to each requested configuration c ∈ Cb. A configu-
ration which is not requested leads to a score of zero. fbjis the scoring function of requester
b for attribute j. Attribute values that are forbidden a score of minus infinity is assigned, i.e.
fbj= −∞. wf
⎧⎪⎪⎪⎨⎪⎪⎪⎩
For the additive scoring function we have to assume mutual preferential independency between
the attributes [KR76]. However, as discussed in [LAO+06], from a technical perspective we can
express preferences over dependent attributes using a higher dimensional function. Of course,
specification of preferences is much harder for the requesters in this case.
In order to find the services that are suitable for a certain task, the inputs and outputs of the
requested service sbare compared with those of the offered services. This is done according to
the following matching rule.
jis the relative importance of attribute j.
Fb(c) =
?n
0
j=1wf
jfbj(ajkj)
if c ∈ Cb,
otherweise.
with
n ?
j=1
wf
j= 1 (2)
Definition 4 (Functional Match) Let rbbe a request for service sbwith the corresponding
inputs Iband outputs Ob. Analogously, opis a Web service offer containing the service spwith
the inputs Ipand outputs Op. Then, rbfunctionally matches opiff Ip⊆ Iband Ob⊆ Op. A
functional match is indicated by the notation rb =f op. The set Θr⊆ Θ contains the service
offers that functionally match a given request rb, i.e. Θr= {ob∈ Θ|rb=fob}
The intuition behind this approach is that only those Web service offers match that provide at
least the requested information while requiring at most the input specified in the request.
Finding the optimal service configuration involves two steps: selecting the best configuration
for each provider and choosing the best provider based on the optimal configurations. First,
we formulate the optimization problem that allows determining the best configuration c ∈ Cp
offered by a provider p ∈ P.
The objective function that has to be optimized represents the difference between the score
assigned to a certain configuration by the requester and the price of this configuration. The
corresponding optimization problem can be formulated as follows:
max
ci∈CpFb(ci) −Gp(ci) (3)
A naive approach to solve this problem is to iterate over all configurations, calculate the in-
dividual utilities and rank the configurations accordingly. The overall complexity of such an

Page 5

algorithm is given by |O|?
attributes this approach might be inefficient for very complex services. However, in a first step
such a naive approach seems to be appropriate, since current Web service descriptions usually
consider only relatively few non-functional properties.
Having determined the optimal configuration c∗
preference structure as follows:
j|Aj|, where |O| is the number of offers and?
j|Aj| the number of
possible configurations. Since the number of configurations is exponential in the number of
oand utility u∗
ofor each offer o, we derive a
Definition 5 (Preference Structure) A preference structure on O is defined by the complete,
transitive, and reflexive relation ?, which defines a weak preference order over the alternatives
as follows: ∀o1,o2∈ O: o1? o2⇔ o1is preferred to o2. Consequently, a preference structure
can be constructed from the requester’s utility as follows: o1? o2⇔ u∗
o1≥ u∗
o2.
Therefore, a reasonable selection rule would be to select o∗∈ O iff ∀o ∈ O : o∗? o. Of course,
depending on the application also other matching approaches might be required. For example,
one might want to select the ten best services to invite them for further negotiations.
Based on the abstract selection model introduced above, the next section deals with implement-
ing this model in an open and heterogenous environment using existing standards and tools.
3 Ontology-based Representation
In this section, we show how the abstract selection model introduced above can be implemented
with a standardized logical formalism providing a common understanding between providers
and customers. We realize this by means of ontologies, which became an important technology
for knowledge sharing in distributed, heterogeneous environments, particularly in the context
of the Semantic Web.1
3.1 Ontology formalism
An ontology is a set of logical axioms that formally define a shared vocabulary [Gru93]. By
committing to a common ontology, software agents can make assertions or ask queries that are
understood by the other agents.
In order to guarantee that these formal definitions are understood by other parties (e.g. in the
web), the underlying logic has to be standardized. The Web Ontology Language (OWL) stan-
dardized by the World Wide Web Consortium (W3C) is a first effort in this direction [W3C04].
OWL-DL is a decidable fragment of OWL and is based on a family of knowledge represen-
tation formalisms called Description Logics (DL) [BCM+03]. Consequently, our notion of an
ontology is a DL knowledge base expressed via RDF/XML syntax to ensure compatibility with
1http://www.w3.org/2001/sw/