QoS-Aware Parameterized Semantic Matchmaking Framework for Web
Service Composition
Salem Chakhar, Alessio Ishizaka and Ashraf Labib
Portsmouth Business School, University of Portsmouth, Portsmouth, U.K.
Keywords:
Web service, Service Composition, Matchmaking, Quality of Service.
Abstract:
The paper presents a parameterized and highly customizable semantic matchmaking framework. The match-
making approach on which this framework is based distinguishes three types of matching: functional attribute-
level matching, functional service-level matching, and non-functional matching. The functional matching per-
mits to eliminate web services that fail to meet the user functional requirements. The non-functional matching
permits to categorize web services instances into different ordered QoS classes. A series of algorithms are ad-
vertised for the different types of matching. These algorithms are designed to support a customizable matching
process that permits the user to control the matched attributes, the order in which attributes are compared, as
well as the way the sufficiency is computed for all matching types.
1 INTRODUCTION
Individual web services are conceptually limited to
relatively simple functionalities modeled through a
collection of simple operations. However, for certain
types of applications, it is necessary to combine a set
of individual web services to obtain composite web
services (Chakhar et al., 2011). A crucial issue within
web service composition is related to the selection of
the most appropriate one among the different candi-
date web services.
In this paper we propose a semantic match-
making framework for web service composition.
We distinguish three types of matching: func-
tional attribute-level matching, functional service-
level matching, and non-functional matching. The
functional attribute-level matching implies capability
and property attributes and associates with each at-
tribute a similarity measure that should be satisfied
by the corresponding attribute in the advertised ser-
vice. The functional service-level matching supports
attribute-level matching and adds a service similarity
measure that should be satisfied by the advertised ser-
vice as a whole. The non-functional matching implies
Quality of service (QoS) attributes.
The work presented in this paper is included in a
layered system for web service composition that we
proposed in (Chakhar, 2012). The matching opera-
tion intervenes in different levels of this system, as
explained in Section 2.4.
The paper is structured as follows. Section 2 sets
the background. Sections 3, 4 and 5 detail the frame-
work. Section 6 provides illustrative examples. Sec-
tion 7 presents experimental results. Section 8 dis-
cusses related work. Section 9 concludes the paper.
2 BACKGROUND
2.1 Example Scenario
This example scenario is freely inspired from a case
use scenario described in the WSC Web Services Ar-
chitecture Usage Scenarios (Hao et al., 2004). A
company (travel agent) offers to people the ability
to book complete vacation packages: plane/train/bus
tickets, hotels, car rental, excursions, etc. Service
providers (airlines, bus companies, hotel chains, etc.)
propose web services to query their offerings and per-
form reservations. The user provides a destination
and some dates to the travel agent service. The travel
agent service inquires service providers about deals
and presents them to the user.
2.2 Basic Definitions
We introduce some basic definitions of a service and
other service-specific concepts. Several definitions
are due to (Doshi et al., 2004).
50
Chakhar S., Ishizaka A. and Labib A..
QoS-Aware Parameterized Semantic Matchmaking Framework for Web Service Composition.
DOI: 10.5220/0004858100500061
In Proceedings of the 10th International Conference on Web Information Systems and Technologies (WEBIST-2014), pages 50-61
ISBN: 978-989-758-023-9
Copyright
c
 2014 SCITEPRESS (Science and Technology Publications, Lda.)

Definition 1 (Service). A service S is defined as a
collection of attributes that describe the service. Let
S.A denotes the set of attributes of service S and S.A
i
denotes each member of this set. Let S.N denotes the
cardinality of this set.
Example 1. The travel agent company provides a
web service, bookVacation, that is defined by the fol-
lowing attributes: service category, input, output, pre-
conditions, postconditions, response time, availability,
cost, security, and geographical location.
Definition 2 (Service Capability). The capability of
a service S.C is a subset of service attributes (S.C ⊆
S.A), and includes only functional ones that directly
relate to its working.
Example 2. The capability of bookVacation is:
S.C = {input, output, preconditions, postconditions}.
Definition 3 (Service Quality). The quality of a ser-
vice S.Q, is a subset of service attributes (S.Q ⊆ S.A),
and includes all attributes that relate to its QoS.
Example 3. The Quality of bookVacation is: S.Q =
{response time, availability, cost, security}.
Definition 4 (Service Property). The property of a
service, S.P, is a subset of service attributes (S.P ⊆
S.A), and includes all attributes other than those in-
cluded in service capability or service quality.
Example 4. The property of bookVacation is: S.P =
{service category, geographical location}.
2.3 Composition Approach
The key elements of the composition approach that
we proposed in (Chakhar, 2012) are: the composition
graph, potential executable plans and executable plan.
The composition graph is an abstract representation
of functional requirements provided by the user. It
models the invocation relationships between the indi-
vidual web services contained in the composite web
service. The set of potential executable plans is the
composite service instances which are obtained by re-
placing each service type in the composition graph
by its instances using a set of transformation rules.
The objective of the transformation operation is to in-
clude the different semantics of BPEL constructors.
Among the different potential executable plans only
one—called executable plan—should be selected and
transformed to a workflow for effective execution.
The composition operation starts by user specifi-
cation of functional and non-functional requirements
and leads to an executable plan that can be handed off
to runtime environment for execution. The proposed
approach to support the composition operation con-
tains three phases:
1. Logical composition: First, the functional require-
ments provided by the user are used to generate
the composition graph.
2. Physical composition: Second, the composition
graph is transformed to obtain the set of potential
executable plans.
3. Evaluation and selection: Third, the different po-
tential executable plans are evaluated and com-
pared in order to select one executable plan. The
latter is then transformed into a workflow and then
deployed, discovered and invoked.
The service composition approach is implemented
by a layered system called QoSeBroker (for QoS-
enhanced Broker). The architecture of QoSeBroker is
given in Figure 1. A detailed description of QoSeBro-
ker is given in (Chakhar, 2012). At this level, we just
mention that the matching operation intervenes in the
logical and physical composition phases, as briefly
explained in the next subsection.
Figure 1: QoSeBroker architecture.
2.4 Service Matching Types and Process
The input for a web service composition is a set of
specifications describing the capabilities of the de-
sired service. These specifications can be decom-
posed into two groups (Chakhar et al., 2011): (i)
functional requirements that deal with the desired
functionality of the composite service, and (ii) non-
functional requirements that relate to the issues like
cost, performance and availability. These specifica-
tions need to be expressed in an appropriate language.
In this paper, we adopt an extended version of Ontol-
ogy Web Language (OWL) (Agarwal et al., 2005) for
expressing functional requirements and the QoS for
non-functional requirements.
QoS-AwareParameterizedSemanticMatchmakingFrameworkforWebServiceComposition
51

Furthermore, we may distinguish three types of
service matching (Chakhar, 2013):
• Functional Attribute-level Matching: This type
of matching implies capability and property at-
tributes and consider each matching attribute in-
dependently of the others.
• Functional Service-level Matching: This type
of matching implies capability and property at-
tributes but the matching operation implies at-
tributes both independently and jointly.
• Non-functional Matching: This type of match-
ing implies QoS attributes.
These different matching types intervene in differ-
ent composition phases. The functional matching in-
tervenes in the logical composition phase. Indeed,
the construction of the composition graph needs first
the identification of candidate service types. This
operation requires matching the preconditions of a
web service with the effects of another up front dur-
ing filtering by using only functional requirements.
The functional matching takes as input all candidate
web services and outputs a set of web services that
meet the user functional matching criteria. During
logical composition phase, service types that fail to
meet the user functional requirements are automat-
ically eliminated. At this level, it is important to
mention that functional service-level matching sup-
ports jointly attribute-level and service-level match-
ing. Hence, the user should select either functional
attribute-level matching only or functional service-
level matching only.
The non-functional matching intervenes during
the physical composition phase. In fact, the first step
in this phase is to identify, for each service type in
the composition graph, the set of the corresponding
instances. For this purpose, the matching operation
uses the composition graph and queries the service
instances registry to associate to each service type
a set of potential instances (at last one instance per
type is needed). The second step is then to use non-
functional attributes in order to classify web service
instances into different QoS ordered classes. It is easy
to see that there is no elimination of web service in-
stances at this level.
In (Chakhar, 2013) we discussed functional
attribute-level and functional service-level match-
ing. However, the functional attribute-level match-
ing presented in (Chakhar, 2013) assumes only con-
junctive or disjunctive logical relationships between
matching attributes. This paper enhances our pro-
posal in (Chakhar, 2013) by adding generic func-
tional attribute-level matching and non-functional
QoS-oriented matching.
3 FUNCTIONAL
ATTRIBUTE-LEVEL
MATCHING
Functional matching may be defined as the process
of discovering a service advertisement that sufficiently
satisfies a service request (Doshi et al., 2004). Func-
tional matching is based on the concept of sufficiency,
which itself is based on the similarity measure.
3.1 Similarity Measure
A semantic match between two entities frequently in-
volves a similarity measure. The similarity measure
quantifies the semantic distance between the two en-
tities participating in the match. As in (Doshi et al.,
2004), a similarity measure is defined as follows.
Definition 5 (Similarity Measure). The similarity
measure, µ, of two service attributes is a mapping
that measures the semantic distance between the con-
ceptual annotations associated with the service at-
tributes. Mathematically,
µ : A × A → {Exact, Plug-in, Subsumption,
Container, Part-of, Disjoint}
where A is the set of all possible attributes.
The mapping between two conceptual annotations is
called:
• Exact map: if the two conceptual annotations are
syntactically identical,
• Plug-in map: if the first conceptual annotation is
specialized by the second,
• Subsumption map: if the first conceptual annota-
tion specializes the second,
• Container map: if the first conceptual annotation
contains the second,
• Part-of map: if the first conceptual annotation is
a part of the second, and
• Disjoint map: if none of the previous cases ap-
plies.
A preferential total order is established on the above
mentioned similarity maps.
Definition 6 (Similarity Measure Preference).
Preference amongst similarity measures is governed
by the following strict total order:
Exact ≻ Plug-in ≻ Subsumption ≻ Container ≻
Part-of ≻ Disjoint
where a ≻ b means that a is preferred over b.
WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies
52

3.2 Computing the Similarity Measure
The computing of the similarity measure is based
on the conceptual annotations associated with the re-
quested and advertised web services. The matching
process uses ontological representation of web ser-
vices to infer the submission hierarchy which leads
to the recognition of semantic matches despite their
syntactic differences and difference in modeling ab-
stractions between requests and advertisements.
The similarity measure, which represents the de-
gree of match, is defined along a discrete scale in
which the ’Exact’ match is the highest level and is
the preferable while ’Fail’ is the lowest level and it
represents an undesirable result. Note that the labels
used to define the different similarity measures can be
mapped to numerical values. However, only compar-
ison operations are authorized (since we assumed that
these values are ordinal).
Let now explain how the similarity measure µ is
computed. For this purpose we consider the travel
agent scenario example given in Section 2.1. Figure 2
shows a fragment of the Travel Agent Ontology. We
consider an Advertisement for the travel agent web
service who permits the client to book Accommoda-
tion in the specified Destination. Assume that the Ad-
vertisement has the following Inputs and Outputs:
Inputs: Destination
Outputs: Accommodation, Sport, Cost
We consider a Query from a client who planning
a vacation. The client wants to make reservations for
a Hotel and an Excursion at the specified Destination.
As shown in Figure 2, the Hotel is a subclass of the
concept Accommodation and Excursion is a subclass
of the concept Entertainment. The Query has the fol-
lowing Inputs and Outputs:
Inputs: Destination
Outputs: Hotel, Excursion
Figure 2: Travel Ontology extract.
Let now focalize on the process of matching
Query outputs. The same reasoning applies to the
process of matching the inputs. The matching pro-
cess iterates over the list of output concepts of the
Query and looks to find a match to an output con-
cept in the Advertisement. Intuitively, any concept
in the output represents a candidate for the match.
In this particular example, the initial candidate list is
{Accommodation, Sport, Cost}. The matching pro-
cess first looks to see if there is a match for Ho-
tel. Based on Figure 2, the match between Hotel
and Accommodation will be flagged Exact. Then, the
matching process looks a match for Excursion. Based
on Figure 2, the match for Excursion with respect
to Accommodation, Sport and Cost will fail (since
there is no relationship between these concepts and
Excursion concept). Hence, we can conclude that
µ
(
outputR
,
outputA
)=’Fail’ where
outputR
and
out-
putA are the output attributes of requested and adver-
tised services, respectively. Using the same reason-
ing, we obtain an Exact match for the input concept
Destination, i.e., µ(inputR,inputA)=’Exact’ where in-
putR and inputA are the input attributes of requested
and advertised services, respectively.
3.3 Conjunctive/Disjunctive Matching
Let S
R
be the service that is requested, and S
A
be the
service that is advertised. A first customization of
functional matching is to allow the user to specify a
desired similarity measure for each attribute. A suf-
ficient match exists between S
R
and S
A
in respect to
a given attribute if there exists an identical attribute
of S
A
and the values of the attributes satisfy the de-
sired similarity measure. A second customization of
the matching process is to allow the user specifying
which attributes should be utilized during the match-
ing process, and the order in which the attributes must
be considered for comparison. In order to support
both customizations, we use the concept of Criteria
Table, introduced by (Doshi et al., 2004), that serves
as a parameter to the matching process.
Definition 7 (Criteria Table). A Criteria Table, C, is
a relation consisting of two attributes, C.A and C.M.
C.A describes the service attribute to be compared,
and C.M gives the least preferred similarity measure
for that attribute. Let C.A
i
and C.M
i
denote the ser-
vice attribute value and the desired measure in the ith
tuple of the relation. C.N denotes the total number of
tuples in C.
Example 5. Table 1 shows a Criteria Table example.
A sufficient functional attribute-level conjunctive
match between services is defined as follows.
Definition 8 (Sufficient Functional Conjunctive
Match). Let S
R
be the service that is requested, and
QoS-AwareParameterizedSemanticMatchmakingFrameworkforWebServiceComposition
53

S
A
be the service that is advertised. Let C be a criteria
table. A sufficient conjunctive match exists between
S
R
and S
A
if for every attribute in C.A there exists
an identical attribute of S
R
and S
A
and the values of
the attributes satisfy the desired similarity measure as
specified in C.M. Formally,
∀
i
∃
j,k
(C.A
i
= S
R
.A
j
= S
A
.A
k
) ∧µ(S
R
.A
j
,S
A
.A
k
) ≽ C.M
i
⇒ SuffFuncConjMatch(S
R
,S
A
) 1 ≤ i ≤ C.N. (1)
Table 1: An example Criteria Table.
C.A C.M
input Exact
output Exact
precondition Subsumes
postcondition Subsumes
The functional attribute-level conjunctive match is
formalized in Algorithm 1 in (Chakhar, 2013). A less
restrictive definition of sufficiency consists in using a
disjunctive rule on the individual matching measures.
Definition 9 (Sufficient Functional Disjunctive
Match). Let S
R
be the service that is requested, and
S
A
be the service that is advertised. Let C be a crite-
ria table. A sufficient disjunctive match exists between
S
R
and S
A
if for at least one attribute in C.A it exists
an identical attribute of S
R
and S
A
and the values of
the attributes satisfy the desired similarity measure as
specified in C.M. Formally,
∃
i, j,k
(C.A
i
= S
R
.A
j
= S
A
.A
k
) ∧ µ(S
R
.A
j
,S
A
.A
k
) ≽ C.M
i
⇒ SuffFuncDisjMatch(S
R
,S
A
). (2)
The functional attribute-level disjunctive match is
formalized in Algorithm 2 in (Chakhar, 2013).
3.4 Generic Matching
In this section we extend the algorithms proposed in
(Chakhar, 2013) to generic binary connectors by al-
lowing the user to specify the conditional relation-
ships between the capability and property attributes.
First, we need to introduce the concept of sufficient
single attribute match.
Definition 10 (Sufficient Single Attribute Match).
Let S
R
be the service that is requested, and S
A
be the
service that is advertised. Let C be a criteria table. A
sufficient match exists between S
R
and S
A
in respect to
attribute S
R
.A
i
if there exists an identical attribute of
S
A
and the values of the attributes satisfy the desired
similarity measure as specified in C.M
i
. Formally,
∃
j,k
(C.A
i
= S
R
.A
j
= S
A
.A
k
) ∧ µ(S
R
.A
j
,S
A
.A
k
) ≽ C.M
i
)
⇒ SuffSingleAttrMatch(S
R
,S
A
,A
i
). (3)
The single attribute matching is formalized in Al-
gorithm 1 that follows directly from Sentence (3).
Algorithm 1: SuffSingleAttrMatching.
Input : S
R
, // Requested service.
S
A
, // Advertised service.
C, // Criteria Table.
i, // Service attribute index.
Output: Boolean// success/fail.
while
(
j ≤ S
R
.N
)
do
if
(
S
R
.A
j
= C.A
i
)
then
Append S
R
.A
j
to rAttrSet;
end
Assign j ←− j + 1;
end
while
(
k ≤ S
A
.N
)
do
if
(
S
A
.A
k
= C.A
i
)
then
Append S
A
.A
k
to aAttrSet;
end
Assign k ←− k +1;
end
if (µ(rAttrSet[i],aAttrSet[i]) ≽ C.M
i
) then
return success;
end
return fail;
The sufficient functional generic match is then de-
fined as follows.
Definition 11 (Sufficient Functional Generic
Match). Let S
R
be the service that is requested, and
S
A
be the service that is advertised. Let C be the
criteria table. Let T be a complex logical clause
where operands are the attributes related by logical
operators (e.g. or, and, not). A sufficient functional
generic match between S
R
and S
A
holds if and only
the logical clause T holds. Formally,
Parse(T ) ∧ Evaluate(T )
⇒ SuffAttrGenericMatch(S
R
,S
A
) (4)
where Parse and Evaluate are functions devoted re-
spectively to parse and evaluate the logical expres-
sion T .
The functional generic match is formalized in Al-
gorithm 2, which follows directly from Sentence (4).
Example 6. A example of a logical expression is
“T = A
5
or (A
2
and A
3
)”. In this example, the match-
ing holds when either (i) the matching in respect to
attribute A
5
holds, or (ii) the matching in respect to
attribute A
2
and the matching in respect to attribute
A
3
hold jointly.
3.5 Computational Complexity
Let first focalize on the complexity of Algorithm 1.
The complexity of the two while loops in Algorithm
1 is equal to O(S
R
.N) + O(S
A
.N). Since we gener-
ally have S
A
.N ≫ S
R
.N, hence the complexity of the
WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies
54

two while loops is equal to O(S
A
.N). Then, the worst
case complexity of Algorithm 1 is O(S
A
.N)+α where
α is the complexity of computing µ. The value of
α depends on the approach used to infer µ. As un-
derlined in (Doshi et al., 2004), inferring µ by onto-
logical parse of pieces of information into facts and
then utilizing commercial rule-based engines which
use the fast Rete (Forgy, 1982) pattern-matching al-
gorithm leads to α = O(|R||F||P|) where |R| is the
number of rules, |F| is the number of facts, and |P|
is the average number of patterns in each rule. In
this case, the worst case complexity of Algorithm 1 is
O(S
A
.N)+O(|R||F||P|). Furthermore, we observe, as
in (Doshi et al., 2004), that the process of computing µ
is the most “expensive” step of the algorithms. Hence,
we obtain:
O
(
S
A
.
N
) +
O
(
|
R
||
F
||
P
|
)
≍
O
(
|
R
||
F
||
P
|
)
.
The complexity of Algorithm 2 depends on the
complexity of functions Parse and Evaluate. The
complexity of these functions depends on the data
structure used to represent the logical expression T
(graph, truth tables, etc.). Clearly the complexity of
Evaluate function is largely greater than the complex-
ity of Parse function. Hence, the complexity of Al-
gorithm 2 is O(|R||F||P|) + O(γ) where O(γ) is the
complexity of Evaluate function.
Algorithm 2: SuffAttrGenericMatch.
Input : S
R
, // Requested service.
S
A
, // Advertised service.
C, // Criteria table.
T , // Logical expression.
Output: Boolean// success/fail.
if (NOT(Parse(T))) then
return fail;
end
T
′
←− T ;
Z ←−
/
0;
for (each A
l
∈ T
′
) do
if (A
l
/∈ Z) then
t ←− false;
t ←− SuffSingleAttrMatch(S
R
,S
A
,A
l
);
replace all A
l
∈ T by the value of t;
Z ←− Z ∪ {A
l
};
end
end
if (Evaluate(T)) then
return success;
end
return fail;
4 SERVICE-LEVEL MATCHING
The service-level matching allows the client to use
two types of desired similarity: (i) desired similar-
ity values associated with each attribute in the criteria
table, and (ii) a global desired similarity that applies
to the service as a whole. The service-level similar-
ity measure quantifies the semantic distance between
the requested service and the advertised service enti-
ties participating in the match by taking into account
both attribute-level and service-level desired similar-
ity measures.
Definition 12 (Sufficient Functional Service-Level
Match). Let S
R
be the service that is requested, and
S
A
be the service that is advertised. Let C be a crite-
ria table. Let β be the service-level desired similarity
measure. A sufficient service-level match exists be-
tween S
R
and S
A
if (i) for every attribute in C .A there
exists an identical attribute of S
R
and S
A
and the val-
ues of the attributes satisfy the desired similarity mea-
sure as specified in C.M, and (ii) the value of overall
similarity measure satisfies the desired overall simi-
larity measure β. Mathematically,
[∀i (SuffSingleAttrMatch(S
R
,S
A
,A
i
)) 1 ≤ i ≤ C.N]∧
[∃ j
1
,··· , j
i
,··· , j
N
(ζ(s
1, j
1
,··· ,s
i, j
i
,··· ,s
N, j
N
) ≽ β)]
⇒ SuffFuncServiceLevelMatch(S
R
,S
A
) (5)
where ζ is an aggregation rule; and for i = 1,··· ,N
and j
i
∈ { j
1
,··· , j
N
}:
s
i, j
i
= µ(S
R
.A
i
,S
A
.A
j
i
).
The parameter β may be any of the maps given
in Section 3.1. The functional service-level matching
in formalized Algorithm 4 in (Chakhar, 2013). The
aggregation rule ζ used in the definition above is a
tool to combine the similarity measures into a single
similarly measure. In (Chakhar, 2013), we defined ζ
as follows:
ζ : F
1
× ··· × F
N
→ {Exact, Plug-in, Subsumption,
Container, Part-of, Disjoint}
where F
j
={Exact, Plug-in, Subsumption,Container,
Part-of, Disjoint} ( j = 1, · · · , N); and N is the number
of attributes included in the criteria table. The sim-
ilarity maps and the corresponding strict total order
given in Section 3.1 still apply here. Since the simi-
larity measures are defined on an ordinal scale, there
are only a few possible aggregation rules that can be
used to combine similarity measures (Chakhar, 2013):
Minimum, Maximum, Median, Floor and Ceil. The
Floor and Ceil rules apply only when there is an even
number of similarity measures (which leads to two
median values).
5 QoS-ORIENTED MATCHING
The QoS-oriented matching concerns QoS attributes
only and applies to service instances that verify func-
tional requirements. The objective of QoS matching
QoS-AwareParameterizedSemanticMatchmakingFrameworkforWebServiceComposition
55

is to assign to each instance an overall QoS level. In-
stead of sorting services from best to worst, we pro-
pose to categorize them into an ordered set of QoS
classes Cl = {Cl
1
,··· ,Cl
p
}, such that the higher the
class, the higher the QoS level.
The computing of overall QoS level for each in-
stance requires the use of a multicriteria aggregation
rule. In this paper, we distinguish two types of ag-
gregation rules: (i) simple majority, and (ii) simple
majority with veto.
5.1 Simple Majority-based Matching
To formalize the first version of QoS matching, we
need to introduce some new concepts.
Definition 13 (QoS Attribute Table). A QoS At-
tribute Table, Q, is a relation consisting of three at-
tributes, Q.A, Q.T and Q.S. Q.A describes the ser-
vice attribute to be compared, Q.T gives the attribute
type and Q.S specifies the scale type. Two types of at-
tributes are distinguished: gain and cost. The gain
attributes are those to be maximized while cost at-
tributes are those to be minimized. The scale may be
nominal, ordinal, cardinal or ratio. Let Q.A
i
, Q.T
i
and Q.S
i
denote the service attribute value, the at-
tribute type and the scale type of the ith tuple of the
relation. Let Q.N be the total number of tuples in Q.
Example 7. Table 2 shows a QoS Attribute Table ex-
ample. It specifies the parameters of four QoS at-
tributes: response time (A
1
), availability (A
2
), secu-
rity (A
3
) and cost (A
4
).
Table 2: An example QoS Attribute Table.
Q.A Q.T Q.S
A
1
: Response time cost Cardinal
A
2
: Availability gain Cardinal
A
3
: Security gain Ordinal
A
4
: Cost cost Cardinal
Definition 14 (Boundary Matrix). A Boundary Ma-
trix, B, consisting of a pairwise matrix composed of
p − 1 columns B
1
,···,B
p−1
and N rows correspond-
ing to the number of QoS attributes.
Example 8. An example of Boundary Matrix is given
in Table 3. It specifies three boundaries in respect to
the QoS given in Table 2. Table 3 defines four QoS
classes.
The attribute type and scale parameters should be
used to control input data, especially the definition of
boundaries.
Definition 15 (Weight Table). A Weight Table, W , is
a relation consisting of two attributes, W.A and W.V .
W.A describes the service attribute and W.V specifies
the weight of this attribute. Let W.A
i
and W.V
i
denote
the service attribute and the attribute weight value in
the ith tuple of relation W . The weights values must
sum to 1.
Table 3: An example Boundary Matrix.
Q.A
i
B
1
B
2
B
3
Response time 11 9.25 8
Availability 0.2 0.3 0.51
Security 2 3 4
Cost 4 3.5 3
Example 9. An example of Weight Table is given in
Table 4.
Table 4: An example Weight Table.
W.A W.V
Response time 0.325
Availability 0.325
Security 0.175
Cost 0.175
Definition 16 (Concordance Power). Let h ∈
{1,··· , p}. The concordance power for the outrank-
ing of advertised service S
A
over boundary B
h
is com-
puted as follows:
Φ(S
A
,B
h
) =
∑
i∈L
1
(S
A
,h)
W.V
i
where: L
1
(S
A
,B
h
) = {i : S
A
.A
i
≽ B
h
.A
i
∧ Q.T
i
=
’gain’} ∪ {i : S
A
.A
i
≼ B
h
.A
i
∧ Q.T
i
= ’cost’} ∪ {i :
S
A
.A
i
= B
h
.A
i
∧ Q.S
i
= ’nominal’}.
Example 10. Let consider the service instances given
in Table 5. Based on the definition above we ob-
tain L
1
(s
8
,B
1
) = {1, 3, 2,4}, L
1
(s
8
,B
2
) = {2, 3, 4}
and L
1
(s
8
,B
3
) = {4}. This leads to: Φ(s
8
,B
1
) = 1,
Φ(s
8
,B
2
) = 0.675 and Φ(s
8
,B
3
) = 0.175.
Table 5: Web service instances.
s
i
A
1
A
2
A
3
A
4
s
8
12.82 0.34296 3 2.74
s
9
10.92 0.15 1 2.08
s
10
9.52 0.51 4 2.5
Definition 17 (Sufficient Simple Majority-based
QoS Matching). Let S
R
be the service that is re-
quested and S
A
be the service that is advertised. Let
S
R
.Q be the list of QoS attributes to be utilized for
matching. Service S
A
is assigned to QoS class Cl
h
if
for every QoS attribute of S
R
there is exists an identi-
cal attribute of S
A
and the value of the Concordance
WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies
56

Power is greater or equal to the credibility threshold
λ and Φ(S
A
,B
h
) ≥ Φ(S
A
,B
h
′
) for every h < h
′
. For-
mally,
Argmax
h
[∃
j,k
(Q.A
i
= S
R
.A
j
= S
A
.A
k
) ∧ Φ(S
A
,B
h
) ≽ λ]
⇒ QoSMajorityMatch(S
R
,S
A
,Cl
h
). (6)
where λ ∈ [0.5,1].
The parameter λ, called credibility threshold, en-
sures that at least 50% of attributes are in favor of the
assignment of the advertised service to the considered
QoS class. Hence, a service S
A
is assigned to class
Cl
h
if and only if there is a “sufficient” majority of
attributes in favor of assigning S
A
to Cl
h
.
This first version of QoS matching is formalized
in Algorithm 3. This algorithm compares S
A
to each
of the boundaries staring from the highest one and
stops once a sufficient QoS measure holds. The func-
tion ConcordancePower, which computes the concor-
dance power as in Definition (16), is given in Algo-
rithm 4.
Algorithm 3: QoSMajorityMatching.
Input : S
A
, // Advertised service.
λ, // Credibility threshold.
Q, // QoS Table.
B, // Boundary Matrix.
W , // Weight Table.
Output: Cl = {Cl
1
,··· ,Cl
p
}// Global QoS classes.
p ←−number of QoS classes;
Cl
i
←−
/
0, ∀i = 1, · ·· , p;
U
′
←− instances of S
A
;
for (all u ∈ U
′
) do
h ←− p − 1;
assigned ←− False;
while (h ≥ 0 ∧ NOT(assigned)) do
if (ConcordancePower(u, h) ≥ λ) then
Cl
h+1
←− Cl
h+1
∪ {u};
assigned ←− true;
end
h ←− h − 1;
end
end
Cl ←− {Cl
1
,··· ,Cl
p
};
return Cl;
Example 11. Let λ = 0.65. Based on the previous
example, we conclude that s
8
in Table 5 is assigned
by Algorithm 3 to QoS class level 3 since Φ(s
2
,B
3
) =
0.175 < λ and Φ(s
8
,B
2
) = 0.675 > λ.
5.2 Simple Majority and Veto Based
QoS Matching
A further customization consisting in the support of
the veto effect by taking into account the opposition of
Algorithm 4: ConcordancePower.
Input : S
A
, // Advertised service.
h, // Integer (Boundary index).
Output: Φ(S
A
,B
h
)// Concordance Power.
s ←− 0;
for (all Q.A
i
∈ Q.A) do
switch Q.T
i
do
case (’gain’)
if
(
S
A
.A
i
≥ B
h
.A
i
)
then
s ←− s +W.V
i
;
end
end
case (’cost’)
if
(
S
A
.A
i
≤ B
h
.A
i
)
then
s ←− s +W.V
i
;
end
end
case (’nominal’)
if
(
S
A
.A
i
= B
h
.A
i
)
then
s ←− s +W.V
i
;
end
end
end
end
return s;
minority attributes, i.e., attributes that do not belong
to set L
1
. The definition of QoS matching with sup-
port of veto effect requires the introduction of some
new concepts.
Definition 18 (Discordance Power). Let
h ∈ {1, · · · , p}. The discordance power for the
outranking of advertised service S
A
over boundary
B
h
is computed as follows:
Ψ(S
A
,B
h
) =
k=N
∏
k=1
Z
k
(S
A
.A
k
,B
h
.A
k
)
where:
Z
k
(S
A
.A
k
,B
h
.A
k
) =





1−W.V
k
1−Φ(S
A
,B
h
)
, if W.A
k
> Φ(S
A
,B
h
))
∧ k ∈ L
2
(S
A
,B
h
)
1, otherwise.
with L
2
(S
A
,B
h
) = {i : S
A
.A
i
≺ B
h
.A
i
∧ Q.T
i
=
’gain’} ∪ {i : S
A
.A
i
≻ B
h
.A
i
∧ Q.T
i
= ’cost’} ∪ {i :
S
A
.A
i
̸= B
h
.A
i
∧ Q.S
i
= ’nominal’}.
Example 12. Let consider the service instances given
in Table 5. Based on the definition above we obtain
L
2
(s
8
,B
1
) = {1}, L
2
(s
8
,B
2
) = {1} and L
2
(s
8
,B
3
) =
{1,2}. This leads to: Ψ(s
8
,B
1
) = 0.818, Ψ(s
8
,B
2
) =
0.818 and Ψ(s
2
,B
3
) = 0.670.
Definition 19 (Credibility Index). Let
h ∈ {1,··· , p}. The credibility index for the
outranking of advertised service S
A
over boundary
B
h
is computed as follows:
σ(S
A
,B
h
) = Φ(S
A
,B
h
) · Ψ(S
A
,B
h
).
QoS-AwareParameterizedSemanticMatchmakingFrameworkforWebServiceComposition
57

Example 13. Based on Examples 10 and 12, we
obtain σ(s
8
,B
1
) = 0.818, σ(s
8
,B
2
) = 0.552 and
σ(s
8
,B
3
) = 0.117.
Definition 20 (Sufficient Majority With Veto Based
QoS Matching). Let S
R
be the service that is re-
quested and S
A
be the service that is advertised. Let
S
R
.Q be the list of QoS attributes to be utilized for
matching. Service S
A
is assigned to QoS class Cl
h
if
for every QoS attribute of S
R
there is exists an iden-
tical attribute of S
A
and the value of the Credibility
index is greater or equal to the credibility threshold λ
and σ(S
A
,B
h
) ≥ σ(S
A
,B
h
′
) for every h < h
′
. Formally,
Argmax
h
[∃
j,k
(Q.A
i
= S
R
.A
j
= S
A
.A
k
) ∧ σ(S
A
,B
h
) ≥ λ]
⇒ QoSMajorityVetoMatching(S
R
,S
A
,Cl
h
). (7)
where λ ∈ [0.5,1].
According to this definition, a service S
A
is as-
signed to class Cl
h
if and only if: (i) there is a “suf-
ficient” majority of attributes in favor of assigning S
A
to Cl
h
, and (ii) when the first condition holds, none of
the minority of attributes shows an “important” oppo-
sition to the assignment of S
A
to Cl
h
.
The algorithm for the second version of QoS
matching is similar to Algorithm 3. We simply need
to replace the test “ConcordancePower(u, h) ≥ λ” by
“CredibilityIndex(u,h) ≥ λ”. The function Credibil-
ityIndex, which computes the credibility index as in
Definition (19), is given in Algorithm 5.
Algorithm 5: CredibilityIndex.
Input : S
A
, // Advertised service.
h, // Integer (Boundary index).
Output: σ(S
A
,B
h
)// Credibility Index.
z ←− 1;
s ←− ConcordancePower(S
A
,h);
for (all Q.A
i
∈ Q.A) do
switch Q.T
i
do
case (’gain’)
if
(
S
A
.A
i
< B
h
.A
i
∧W.A
i
> s
)
then
z ←− z ·
1−W.A
i
1−s
;
end
end
case (’cost’)
if
(
S
A
.A
i
> B
h
.A
i
∧W.A
i
> s
)
then
z ←− z ·
1−W.A
i
1−s
;
end
end
case (’nominal’)
if
(
S
A
.A
i
̸= B
h
.A
i
∧W.A
i
> s
)
then
z ←− z ·
1−W.A
i
1−s
;
end
end
end
end
return s · z;
Example 14. Let λ = 0.65. Based on the data and
results of the previous example, we conclude that s
8
in Table 5 is assigned by majority with veto Algorithm
to QoS class level 2 since σ(s
8
,B
1
) = 0.818 > λ, and
σ(s
8
,B
2
) = 0.552 < λ and σ(s
8
,B
3
) = 0.117 < λ.
The previous example shows that the QoS of in-
stance s
8
has decreased (from 3 to 2) in comparison to
Example (11). This because the weights of attributes
which are against the assignment of instance s
8
to
QoS class 3 have been taken into account.
5.3 Computational Complexity
Algorithm 3 runs in O(mp × |U|), where m is the
number of QoS attributes and p is the number of QoS
classes. The second version of Algorithm 3 based on
simple majority with veto and which is not provided
in this paper, runs in O(2mp × |U|). Note that Algo-
rithm 4 runs in O(m) and Algorithm 5 runs in O(2m).
6 ILLUSTRATION
Consider again the example given in Section 3.2. As-
sume that the Criteria Table is as in Table 6. Based
on the discussion given in Section 3.2, the desired
similarity specified by this table holds only for Desti-
nation and Hotel. Hence, the attribute-level conjunc-
tive matching algorithm will fail but the attribute-level
disjunctive matching algorithm will success.
Table 6: Criteria Table.
C.A C.M
input Exact
output Exact
Let now assume that the user has specified the fol-
lowing logical expression:
expression: Destination and (Hotel or Excursion)
The desired similarity specified by the Criteria
Table holds only for Destination and Hotel. But
since the expression “Destination and (Hotel or Ex-
cursion)” will be flagged true, the functional generic
matching algorithm will success.
Let now focalize on service-level functional
matching. Suppose that the Advertisement has the fol-
lowing Inputs, Outputs and Categories:
Inputs: Destination
Outputs: Accommodation, Entertainment, Cost
Categories: AirplaneModel
WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies
58

Suppose also that Query has the following Inputs,
Outputs and Categories:
Inputs: Destination
Outputs: HotelType, Excursion
Categories: AirplaneModel
Based on the same reasoning as earlier, the match
for Destination, Excursion and AirplaneModel con-
cepts will be flagged Exact; and the match for con-
cept
HotelType
will be flagged Plug-in. Assume that
the Criteria Table is as in Table 7.
Table 7: Criteria Table.
C.A C.M
input Exact
output Exact
service category Subsumption
The instantiation of the aggregation rule ζ (see
Section 4) will then look like ζ(Exact, min{Plug-in,
Exact}, Exact) which leads to ζ(Exact, Plug-in, Ex-
act). Then, the result of aggregation according to dif-
ferent aggregation rules (except Median which does
not apply here) is given in Table 8.
Table 8: Result of aggregation.
Aggregation rule(ζ) Minimum Maximum Floor Ceil
Result Plugin Exact Plugin Exact
Let now focalize on non-functional matching and
consider the list of potential compositions given in Ta-
ble 9. We assume that these compositions have meet
the functional requirements of the user. Table 9 shows
the evaluation of the compositions in respect to four
QoS attributes (i.e. response time (A
1
), availability
(A
2
), security (A
3
), and cost (A
4
) attributes) given in
Table 2. The objective is to classify the compositions
into different ordered categories. For the purpose of
this example, we assume that the four categories de-
fined by Table 3 and the weights given in Table 4 have
been used.
The final classifications obtained by the simple
majority and simple majority with veto algorithms
where the credibility threshold is λ = 0.65 are given
in Table 9. In this table, we can see that both simple
majority and majority with veto algorithms (denoted
Algo 3 and Algo 3’ in Table 9, respectively) assign
instances s
3
and s
10
to the best QoS class. We remark
also that both algorithms assign instances s
5
and s
9
to
the worst QoS class. Which is interesting to see in Ta-
ble 9 is the role of veto effect in the assignment of in-
stances s
8
and s
13
. Indeed, the QoS of both instances
have been decreased (from 3 to 2 for instance s
8
and
from 2 to 1 for instance s
13
) by the majority with
veto algorithm. This happens because the weights
of attributes which are against the assignment—of in-
stance s
8
to QoS class 3 and instance s
13
to QoS class
2—have been taken into account.
Table 9: Potential compositions and final classification for
λ=0.65.
s
i
A
1
(s
i
) A
2
(s
i
) A
3
(s
i
) A
4
(s
i
) Algo 3 Algo 3’
s
1
9.2 0.45946 1 2.48 3 3
s
2
8.12 0.41817 1 2.68 3 3
s
3
8 0.53 4 2.78 4 4
s
4
8.19 0.46967 2 3.24 3 3
s
5
11.15 0.19 1 2.74 1 1
s
6
7.42 0.40317 2 3.38 3 3
s
7
7.72 0.36676 2 3.18 3 3
s
8
12.82 0.34296 3 2.74 3 2
s
9
10.92 0.15 1 2.08 1 1
s
10
9.52 0.51 4 2.5 4 4
s
11
10.12 0.53294 3 2.68 3 3
s
12
10.42 0.48356 1 2.32 2 2
s
13
12.52 0.2 1 3.14 2 1
s
14
8.42 0.48 1 2.82 3 3
s
15
10.32 0.48 4 2.16 3 3
7 EXPERIMENTAL RESULTS
For the purpose of experimental tests, we adopted
the same architecture proposed by (Bellur and
Kulkarni, 2007). We used the Protege editor
Protege (http://protege.stanford.edu/) to browse and
edit OWL ontologies. The Mindswap OWL-S
API has been used to load the OWL ontologies
into the Knowledge Base and parse the OWL-S
Queries and Advertisements. We used the Pel-
let reasoner Pellet (http://pellet.owldl.com/) to clas-
sify the loaded ontologies and Jena API JENA
(http://jena.sourceforge.net) to query the reasoner for
concept relationships. To test the algorithms, we used
14 ontologies from the OWTLS-TC (service retrieval
test collection from SemWebCentral) in our Knowl-
edge Base. About 700 advertisements from OWLS-
TC were loaded into the advertisement repository. All
measurement points shown are average results taken
from 30 runs. The data sets for clients and providers
were randomly generated.
The result of experimental tests is given in Fig-
ures 3 and 4. Figure 3 shows the execution time of
Algorithms 1, 2 and 3. Two versions (denoted Algo 3
and Algo 3’ in this figure) of Algorithm 3 have been
tested: the first version (Algo 3) uses the simple ma-
jority and the second version (Algo 3’) uses simple
majority with veto. Figure 4 shows the evolution of
execution time in respect to the number of instances
for the two versions of Algorithm 3. As shown in this
figure, it is easy to see that the execution time varies
QoS-AwareParameterizedSemanticMatchmakingFrameworkforWebServiceComposition
59

asymptotically for both versions of Algorithm 3. We
note, however, that the second version (Algo 3’) is
more expensive in execution time. This because the
second version of Algorithm 3 needs to execute Al-
gorithms 4 and 5 (for computing the concordance and
discordance powers) while the first version (Algo 3)
of Algorithm 3 needs to execute only Algorithm 4.
Figure 3: Execution time of algorithms.
Figure 4: Execution time vs number of instances.
8 RELATED WORK
In this section we discuss some matchmaking frame-
works in respect to several characteristics. The first
characteristic is related to the support of customiza-
tion which is an important issue in practice, as rec-
ognized by (Doshi et al., 2004). Most of proposed
matching systems ignore this point and only a few
ones take into account this aspect. (Doshi et al.,
2004), for instance, present a parameterized seman-
tic matchmaking framework that enables the user to
specify the matched attributes and the order in which
attributes are compared. In (Doshi et al., 2004), the
sufficiency condition defined by the authors is very
strict. This problem has been addressed in (Chakhar,
2013) and in this paper by relaxing matchmaking con-
ditions and supporting three types of matching.
The second characteristic concerns the type of at-
tributes used in the matching operation. Most of ex-
isting matchmaking frameworks (Ben Mokhtar et al.,
2006; Guo et al., 2005; Li and Horrocks, 2003) use
only service capability as the criteria for the match.
The authors in (Doshi et al., 2004) distinguish two
types of matching attributes: capability and prop-
erty. (Ludwig, 2011) proposes two approaches to
service selection based on QoS attributes. (Sathya
et al., 2011) discuss various techniques of QoS based
service selection. (Krithiga, 2012) proposes a QoS-
based web service selection based on a stochastic op-
timization. (Xia et al., 2011) propose a QoS-aware
web service selection algorithm based on clustering.
The framework presented in this paper identify three
types of matching attributes (capability, property, and
QoS) by subdividing property attributes set into two
sets of attributes: those directly related to the QoS
and those which are not. We think that the proposed
framework enhances the above cited proposals, espe-
cially the work of (Doshi et al., 2004).
The third characteristic is related to the method
used to compare the requested and advertised ser-
vices. Most of existing proposals use simple syntac-
tic and strict capability-based search. (Doshi et al.,
2004) present a semantic matchmaking framework
that avoids the limitations of strict capability-based
matchmaking. (Fu et al., 2009) transform the prob-
lem of matching web services to the computation of
semantic similarity between concepts in domain on-
tology using a semantic distance measure. (Bellur
and Kulkarni, 2007) improve (Paolucci et al., 2002)’s
matchmaking algorithm and propose a greedy-based
algorithm that relies on the concept of matching bi-
partite graphs. In this paper we adopted and extended
the semantic matchmaking framework proposed by
(Doshi et al., 2004).
The fourth characteristic concerns the support of
the multicriteria evaluation. There are a few pro-
posals that explicitly support multicriteria evaluation,
e.g. (Cui et al., 2011; Jeong et al., 2007; Menasc
´
e,
2004; Menasc
´
e and Dubey, 2007; Zeng et al., 2003).
Most of them use weighted-sum like aggregation
techniques. (Zeng et al., 2003) use linear program-
ming techniques to compute the optimal execution
plans for web service. (Menasc
´
e, 2004) considers two
evaluation criteria (time and cost) and assigns to each
one a weigh. The best composition of Web services
is then decided on the basis of the optimum combined
score. (Menasc
´
e and Dubey, 2007) propose a service
selection QoS broker by maximizing a utility func-
tion. We note, however, that this type of methods have
two main shortcomings: (i) they accept only numeri-
cal data and (ii) may lead to the compensation prob-
lem since low values may be counterbalanced by high
values. The approach used in this paper accepts any
type of data and resolves the compensation problem.
WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies
60

9 CONCLUSION
We presented a QoS-aware semantic matching frame-
work. The framework supports three types of match-
ing: functional attribute-level matching, functional
service-level matching, and QoS-based matching. A
series of highly customizable algorithms are adver-
tised for each type of matching.
Several issues need to be further investigated.
First, the reduction of the number of parameters re-
quired from the user by automatically generating the
boundaries of QoS classes. Second, the use of the
rough sets theory-based classification (Greco et al.,
2001) for assigning instances to QoS classes. Third,
the use of multicriteria ranking/choice approaches in-
stead of the classification approach used in this paper.
REFERENCES
Agarwal, V., Chafle, G., Dasgupta, K., Karnik, N., Kumar,
A., Mittal, S., and Srivastava, B. (2005). Synthy: A
system for end to end composition of web services.
Journal of Web Semantics, 3:311–339.
Bellur, U. and Kulkarni, R. (2007). Improved matchmaking
algorithm for semantic web services based on bipartite
graph matching. In IEEE International Conference
on Web Services, pages 86–93, Salt Lake City, Utah,
USA.
Ben Mokhtar, S., Kaul, A., Georgantas, N., and Issarny, V.
(2006). Efficient semantic service discovery in perva-
sive computing environments. In ACM/IFIP/USENIX
2006 International Conference on Middleware, pages
240–259, Melbourne, Australia.
Chakhar, S. (2012). QoS-enhanced broker for compos-
ite web service selection. In Eighth International
Conference on Signal Image Technology and Inter-
net Based Systems (SITIS 2012), pages 533–540,
Sorrento-Naples, Italy.
Chakhar, S. (2013). Parameterized attribute and service
levels semantic matchmaking framework for service
composition. In Fifth International Conference on Ad-
vances in Databases, Knowledge, and Data Applica-
tions (DBKDA 2013), pages 159–165, Seville, Spain.
Chakhar, S., Youcef, S., Mousseau, V., Mokdad, L., and
Haddad, S. (2011). Multicriteria evaluation-based
conceptual framework for composite web service
selection. Working Paper, Lamsade, University Paris-
Dauphine, France. http://basepub.dauphine.fr/ xm-
lui/bitstream/handle/123456789/5283/multicriteria
mokdad.PDF?sequence=2.
Cui, L., Kumara, S., and Lee, D. (2011). Scenario analy-
sis of web service composition based on multi-criteria
mathematical goal programming. Service Science,
3(4):280–303.
Doshi, P., Goodwin, R., Akkiraju, R., and Roeder,
S. (2004). Parameterized semantic matchmaking
for workflow composition. IBM Research Report
RC23133, IBM Research Division.
Forgy, C. (1982). Rete: A fast algorithm for the many pat-
terns/many objects match problem. Artificial Intelli-
gence, 19(1):17–37.
Fu, P., Liu, S., Yang, H., and Gu, L. (2009). Matching algo-
rithm of web services based on semantic distance. In
International Workshop on Information Security and
Application (IWISA 2009), pages 465–468, Qingdao,
China.
Greco, S., Matarazzo, B., Slowinski, R., and Stefanowski,
J. (2001). An algorithm for induction of decision rules
consistent with the dominance principle. In Ziarko, W.
and Yao, Y., editors, Rough Sets and Current Trends
in Computing, volume 2005 of LNCS, pages 304–313.
Springer Berlin Heidelberg.
Guo, R., Le, J., and Xiao, X. (2005). Capability matching
of web services based on OWL-S. In Sixteenth Inter-
national Workshop on Database and Expert Systems
Applications, pages 653–657.
Hao, H., Haas, H., and Orchard, D. (2004). Web services
architecture usage scenarios. W3C Working Group
Note 11, IBM Research Division.
Jeong, B., Cho, H., Kulvatunyou, B., and Jones, A. (2007).
A multi-criteria web services composition problem. In
IEEE International Conference on Information Reuse
and Integration( IRI 2007), pages 379–384.
Krithiga, R. (2012). QoS-aware web service selection us-
ing SOMA. Global Journal of Computer Science and
Technology, 12(10):46–51.
Li, L. and Horrocks, I. (2003). A software framework for
matchmaking based on semantic web technology. In
12th International World Wide Web Conference, pages
331–339, Budapest, Hungary.
Ludwig, A. (2011). Memetic algorithm for web service se-
lection. In Third Workshop on Biologically Inspired
Algorithms for Distributed Systems, BADS ’11, pages
1–8, New York, NY, USA. ACM.
Menasc
´
e, D. (2004). Composing web services: A QoS
view. IEEE Internet Computing, 8(6):88–90.
Menasc
´
e, D. and Dubey, V. (2007). Utility-based QoS bro-
kering in service oriented architectures. In IEEE In-
ternational Conference on Web Services (ICWS 2007),
pages 422–430.
Paolucci, M., Kawamura, T., Payne, T., and Sycara, K.
(2002). Semantic matching of web services capabili-
ties. In First International Semantic Web Conference
on The Semantic Web, pages 333–347, Sardinia, Italy.
Sathya, M., Swarnamugi, M., Dhavachelvan, P., and
Sureshkumar, G. (2011). Evaluation of QoS based
web-service selection techniques for service composi-
tion. International Journal of Software Engineering,
1(5):73–90.
Xia, Y., Chen, P., Bao, L., Wang, M., and Yang, J. (2011). A
QoS-aware web service selection algorithm based on
clustering. In IEEE International Conference on Web
Services (ICWS), pages 428–435.
Zeng, L., Benatallah, B., Dumas, M., Kalagnanam, J., and
Sheng, Q. (2003). Quality driven web services com-
position. In 12th International Conference on World
Wide Web, pages 411–421, New York, NY, USA.
ACM.
QoS-AwareParameterizedSemanticMatchmakingFrameworkforWebServiceComposition
61