A Goal Oriented Approach for Web Services
Selection and Composition
Sana Baccar Mohsen Rouached
CES Research Unit College of Computers and Information Technology
National school of Engineers of Sfax Taif University
Sfax, Tunisia Taif, Saudi Arabia
Email: sana.baccar@ceslab.org Email: m.rouached@tu.edu.sa
AbstractDiscovering and composing atomic Web services
into more complex ones is still a hot research topic presenting
serious challenges that much efforts tried to resolve. These
challenges are related especially to the dynamic feature of the
service world, the complexity of the user query and the continuous
growth in the number of the Web services evolved in the Web. In
this paper, we provide a new solution to address these challenges
and offer a composite service that meets the user requirements
as well as his/her preferences in an automatic way. We propose
a goal-oriented composition framework that consists on two-level
architecture: Type-level and Instance-level. The type-level module
supports dynamicity using a declarative language that formulates
the composition process from specification to plan generation
using a dynamic description logic (DDL) language. Taking the
generated plan and the existing service instances as inputs, the
instance-level module provides an optimal executable plan using
a QoS-aware selection engine.
KeywordsWeb Services Composition, Dynamic Description
Logic, planning, QoS.
I. I NTRODUCTION
Although the rapid growth of the Web services, atomic
services, in some cases, can not be sufficient to meet the
users needs. This shortfall, therefore, can be overcame by
composing two-to-many atomic services and producing a more
meaningful and complex functionality that can efficiently
handle the user requirements as well as his preferences such
as quality of service (QoS) criteria. Such composition is
considered as a challenging task and its realization suffers from
various difficulties especially with the continuous increase
of the existing services in the Web, which may generate
several possible composition scenarios and make identifying
an optimal composition that meets the user functional and
non-functional requirements more and more difficult and time
consuming. Another issue that need to be taken into account
is the dynamic feature of the environment that should be
supported by the composition system especially with the non
deterministic effects of the Web services, which requires re-
planning and compensation mechanisms in case of unexpected
events during the composition process.
To solve these issues and provide a practical Web services
composition system, different contributions have been intro-
duced such as [1][2][3][4]. In general, these approaches are
classified into two main categories: workflow-based compo-
sitions and AI planning-based compositions. Although their
benefits, the proposed approaches still suffer from three main
978-1-4799-0615-4/13/$31.00 2013 IEEE 102
Mohamed Abid
CES Research Unit
National school of Engineers of Sfax
Sfax, Tunisia
Email: mohamed.abid ces@yahoo.fr
issues: 1) how to systematically represent both the static on-
tology information and the dynamic Web services information;
2) how to provide a decidable reasoning for determining
whether a certain goal can be satisfied after the execution
of all component services of the generated plans and 3)
how to combine the two first mentioned issues in the same
composition framework to provide an optimal composition
scenario that takes into account many performance criteria
such as checking for correctness, low time consumption and
minimal composition length.
To address these issues, we propose in this paper a two-
level Web services composition approach: Type-level and
Instance-level. We use the terms type and instance to rep-
resent respectively the service functionality and the service
implementation. The staged approach is considered the best
engineering practices of modularity, conciseness, and scal-
ability. For that, we adapted such design in our proposed
framework to automate the composition task and ensure an
optimal composition in highly dynamic environments under
time constraints. Moreover, we believe that achieving these
requirements requires a declarative, expressive and dynamic
language that supports the dynamic and non deterministic
features of the Web services and enables to identify what
a Web service expect to hold before execution and how its
execution may affect the world. Furthermore, there is a need
to decide whether a service can be executed in the current
state of the world and predict the resulted state after the
action execution. These motivations encourages us to use
the Dynamic Description Logic (DDL) language, extension
of the description logics (DLs) with a dynamic dimension
[5][6][7][8]. Thus, in the Type-level, the Web services are
considered as a set of actions that transform the world from
one state to another and the composition process is reduced
to checking formulas satisfiability. More details about the
syntax and the semantics of the DDL languages are given
in our previous work [9]. Then, taking the generated plans,
the user preferences and the service instances repository as
inputs, the Instance-level generates an executable composition
that closely meets the user requirements and preferences by
selecting the optimal instance for each service type in the
abstract plan. Moreover, this level ensures failures recovery
using an optimization technique based on QoS-aware selection
engine. This separation enables to reduce the complexity of
the composition process and ensures more accuracy in the
composite service.
 The rest of this paper is organized as follows. In section
2, we describe the main efforts that have been introduced
to resolve the service composition problem. Section 3 briefly
reviews the main features of the DDL formalism and explain
how these features can be used to specify and compose Web
services. In Section 4, we formalize the service composition
problem and explain the composition approach. Finally, Sec-
tion 5 concludes the paper and outlies the future work.
II. R ELATED W ORK
Several efforts have led to the development of platforms
and languages to support composition and deployment of
services. The Artificial Intelligence (AI) planning techniques
are considered as a cornerstone for a large amount of service
composition approaches. For example, in [10] the authors
proposed a two-stage composition process: the first stage
handles the functional requirements through a logical plan,
while the second stage is deduced to concretizate the logical
plan by generating an executable compositions according to
the non-functional preferences. On one side, such approach
is beneficial in terms of search time consumption as well as
unexpected failure recovery. On the other side, this approach
is a semi-automatic composition technique that requires man-
ual intervention. Moreover, changes adaptation and decision-
support tools based on declarative languages are still underway
over such system. The frameworks proposed in [11] and
[12] consist of two phases: in the first phase, the framework
classifies candidate services based on their QoS according
to the users preferences through an associative classification
algorithm. The second phase uses the resulted classification
to rank the filtered QoS-optimal services focusing on their
semantic functional matching. Such framework is beneficial in
terms of increasing accuracy and identifying an optimal com-
position. On the other part, it suffers from some limits when it
comes to its semi-automatic classification and there is no tool
to support dynamic nature of the Web services. Furthermore,
the selection of Web services in these approaches takes the
QoS criteria as the selection basis and pays more attention on
service evaluation than the functional-based selection, which
leads to increase the time consumption and provide a useless
exhausted calculation.
Other efforts such as [13] and [14] tried to provide an
efficient model for the description, publication, discovery, com-
position and execution of Web services in a semantic way using
DL languages. Although the benefits of these approaches in
increasing the decidability of the composition process through
the DL-reasoners, they suffer from a major gap when it comes
to time consumption and reasoning about dynamic knowledge.
To handle such composition shortfalls and enhance dynamicity
support, some other approaches [5][6][7][8] considered to use
DDL languages . G.Shen et al. propose in [15] a formalism
for modeling and reasoning about Web services and their
behaviors based on DDL language that combines semantic
and formal reasoning in highly abstract level. Moreover, ser-
vice realizability and executability are reduced to checking
formulas satisfiability and consistency through a simple DDL-
based service model. This enables to increase the decidability
but the expressiveness is still underway. Another DDL-based
composition approach is proposed in [16] and consists of
two phases: the first phase generates a partial order diagram
and the second phase runs the composition process using a
103
fast algorithm according to the generated diagram. Although
its linear time complexity, the potential of the DDL is not
exploited to calculate matching concepts, to discover services
and dynamically compose Web services.
Other composition efforts take the service composition
problem as a quality engineering problem that ranges from
the preferred composite services to the most preferred ones.
But such approaches still suffer from some limitations. For
example [17],[18], and [19] are almost QoS local optimization
or mono-objective based, and can not resolve the problem
of Web services selection with multi-objective QoS global
optimization. These methods assume that the work plan is pre-
defined and require enumerating all viable solutions.
III. DDL BASED S ERVICE AND Q UERIES S PECIFICATION
A. DDL overview
Due to the unsufficiency of the description languages (DLs)
[20] to handle the dynamic knowledge such as services and
behaviors, the DDLs, which are an extension of the DLs with
a dynamic dimension, were proposed. In fact, the DDL is based
on the idea that the occurrence and the development of actions
can influence the world evolution from one state to another.
With this logic, description logic concepts can be used for
describing the state of the world, and the preconditions and
effects of atomic actions; Complex actions can be modeled
with the help of standard action operators, such as the test,
sequence, choice, and iteration operators; And both atomic
actions and complex actions can be used as modal operators
to construct formulas.
The primitive symbols of a DDL language contain a set
of concept names (NC ), a set of relation names (NR ), a set
of individual names (NI ) and a set of atomic action names
(NA ) included in construction operators named TBox. Atomic
action is defined as the couple < P, E > where P is a finite
set of formulas specifying the preconditions required for the
execution of the action and E is a finite set of formulas speci-
fying its effects. Both atomic and complex actions are actions
that are built up as follows: , |?| |; | .
Where , , are atomic actions, and is a formula (refer
to [6][8] for more details).
The domain specification is defined as a tuple: DS = <
T Box, ABox, ActBox >, where TBox consists of domain
constraints; ABox (with no semantic conflicts) is the initial
world and ActBox is a finite set of atomic actions that captures
the dynamic knowledge about the world evolvement.
Semantics of DDL are detailed in [6]. For space reasons,
we just introduce the main reasoning strategies in what follows:
An action is executable in a possible world w satisfying its
preconditions stated in P , and its execution reaches a possible
world w=w E, with a minimal change w.r.t the previous
world. For more details, please refer to our previous work
presented in [9].
B. User Queries Specification
A user query Q is modeled as a tuple Q =<
I, O, A, qos >, where I is a finite set of inputs of the
query; O is a finite set of outputs of the query; A is a
finite set of desired actions. Each action consists of a fi-
nite set of pre-conditions P and effects or post-conditions
E. qos is a set of quality of service constraints such
that qos = {(q1 , v1 , w1 ), (q2 , v2 , w2 ), ..., (qk , vk , wk )}, where
qi (i = 1, 2, ..., k) is a quality criterion, vi is the required value
P qi , wi is the weight assigned to this criterion
for criterion
such that ki=1 wi = 1, and k the number of quality criteria
involved in the query.

C. Service Specification
An atomic service is a tuple S =< I, O, P, E, qos >,
where I, O are, respectively, a set of inputs and outputs of the
service S; P is a finite set of precondition formulas of S; E is a
finite set of the service effects, which is the facts holding in the
newly-reached world by the services execution and qos is a set
of provided quality criteria. The formulas in both P and E are
conferred with well-defined semantics encoded in some T Box,
which specifies the domain constraints in consideration.
Composite services are constructed from atomic services
with the help of classic constructors in dynamic logics. Both
atomic and composite services are services. Complex services
are built up with the following formula: , |?|
|; | |((; )(()?; ))|(?; ) ; (?) where , ,
are atomic services, and is a formula. Based on formulas
and atomic services, complex services can be constructed with
the help of four standard atomic services operators: the test
(?) , sequence (; ), choice ( ), iteration operators
( ), if formula is verified then is invoked, else invoking
is an abbreviation of (((; ) (()?; )), and if do
is an abbreviation of (?; ) ; (?).

IV. M ODELING F RAMEWORK FOR W EB S ERVICES Fig. 1. Modeling Framework for Web Services Composition
C OMPOSITION
The overall architecture of our modeling framework for
Web services composition and execution is depicted in figure 1.
As shown in this figure, this architecture mainly consits of two
modules, which are the type level module and the instance level
module. In what follows, we present and detail the components
of the proposed architecture.

A. Goal Specification
The graphical query editor enables end users to specify
and express their requirements and preferences by following
some instructions to build the query. This query is then parsed
and validated using a query parser that checks syntactic cor-
rectness and extracts functional requirements (inputs, outputs,
preconditions and effects) and QoS parameters.
The indexer component shown in figure 2 consists of a Fig. 2. Type Ontology Builder
parser and an ontology builder. The parser takes a set of se-
mantic Web services as inputs and stores them in a single data
structure. Given this generated data structure and the domain
ontology, the ontology builder provides a corresponding type
ontology. The type ontology is an abstract representation of the service types as input, if there is no service type that has the
the available capabilities organized in a hierarchical structure similar capability (functionality) to the instance, a new service
reflecting the relations between service capabilities according type will be created and inserted into the service type set and
to the domain ontology. the instance will be inserted into the new type. Otherwise, the
instance will be inserted into the corresponding service type.
Algorithm 1 shows the main body of the type ontology This process will be iterated for each service instance in the
construction. Taking the service instance and the initial set of service repository.

104
 Algorithm 1: Type Ontology Construction Algorithm
Input: Semantic Web service set: WS; Service type set
AS0
Output: Service type set: AS;
begin
for each Web service wsi WS do
for each service Type ASj AS0 do
if ASj so that
(wsi .capabilityName=ASj .capabilityName
and wsi .preconditions ASj .preconditions
and wsi .effects ASj .effects) then
Form ASk ;
Insert ASk into AS0 ;
Insert wsi into [W S]ASk ;
if ASj then
Insert wsi into [W S]ASj ;
return AS;
End
B. DDL-based planning
Taking the domain ontology, the functional specifications
of the required service and the service type ontology as
inputs, the DL-reasoner provides a knowledge base KB =<
T Box, ABox, T ypeBox >, specifies the desired goal and
checks the availability of the required functionalities from
the candidate service types (TypeBox). Based upon these
specifications, the planner generates the set of plans using a
Filter component that helps in pruning the set of candidate
services before the planner uses DDL-planning techniques to
create the plan.
1) DL-Reasoner: The DL-reasoner captures the ontologies
and the goal specifications and converts them into an expres-
sive description Logic syntax. It is responsible for checking
the ontology consistency, entailment and instance retrieval,
in addition to handling the maintenance of state including
precondition evaluation and effect application. The reasoner
behaves as a matchmaker that checks if an existing service type
(capability) W S T can satisfy the functionality of the required
service W S Q . So that, this matching process is satisfiable
if and only in the cases where i) W Sin T
W Sin Q
and ii)
Q T
W Sout W Sout using the knowledge base (KB). Moreover,
this reasoner is responsible for the validation of the final
planning result. Such validation is achieved using the algorithm
2. Taking the generated plan, the goal and the initial state of
the world as inputs, this algorithm checks the satisfiability of
the preconditions of each service type of the plan according
to the ABox. In case of satisfiability of all the service type
preconditions, its effects will be added to the initial state and
a new state will be raised and will be considered as an initial
state for the successive service type. Such process will be
iterated for all the service type candidates of the plan. If the
satisfiability of all the plan is verified, the plan will be validated
and returned, otherwise, a failure message will be returned.
2) Filter: Given a set of service types that match to a goal
specification, the filter avoids redundancy from the plan by
identifying service types with potential relevance to the goal.
Such services can either be invoked using the initial state that
105
Algorithm 2: Satisfy algorithm
Input: Plan: P={AS1 , AS2 , .., ASn },
ASj =(P rej ,Ef fj ), Goal G, ABox A;
Output: Plan validated or False as failure;
begin
A1 A;
while in do
Fi Conj(A1 )Conj(P rei );
if Fi is unsatisfiable then
A1 (A1 (Ef fi )) Ef fi
return False;
ii+1;
FG Conj(A1 ) [P]Conj(G);
if FG is unsatisfiable then
return P
return False;
End
satisfies their preconditions, or can potentially contribute to
the goal using their effects. Moreover, this component checks
the dependency relationships between each two consecutive
service types AS1 and AS2 in the plan by simply checking the
unsatisfiability of the formula (1), which means that invoking
AS2 sequentially after executing AS1 requires that the inputs
and preconditions of AS2 have to be equivalent.
F : AS2 .I AS2 .P re (AS1 .O AS1 .Ef f ) (1)
So that, whenever the sequence of services is executed (satis-
fiability of the formula (2)); formula (1) must be unsatisfiable.
[AS1; AS2]F (2)
3) DDL-planner: The planner is responsible for composing
two or more service types in a declarative way to satisfy the
required composition. It uses the reasoner and the filter to
find the matching service types for a required goal. It checks
also the satisfiability of the generated plans and evaluate the
preconditions of actions of their services candidates.
To resolve the planning problem, two kinds of knowledge
are required: the domain description, which includes the ontol-
ogy (TBox) and the service type registry (TypeBox), and the
problem description that includes the description of the initial
state (ABox) and the final goal G. Thus, the planning problem
is reduced to finding a sequence of service types that transform
the world from the initial state to another state that satisfies
the goal. In short, the planner functionality is reduced to the
following two points:
1) An abstract sequence plan P={AS1 , AS2 , .. , ASk },
where ASj =(P rej , Ef fj )AS, 1jk), matches the
goal state G according to the ABox A if and only if
the following formula is unsatisfiable:
[(AS1 , AS2 , .., ASk ) ] S (< P > G) (3)
Where denotes the conjunction of the formula set
of preconditions (P rej ) of all service types ASij
in the plan Pi , with i N, 1jk and =
ki=1 Conj(P rej ) (< P rej , Ef fj > T rue). S is
 a formula set that consists of a conjunction of member
formulas Sj according to the ABox that describes the
initial state of the world: S = Conj(Sj ) | 1 j k.
2) A service type which is not a component of the
abstract control-flow sequence need to be integrated
if the formula (4) is satisfied.
[(AS1 , AS2 , .., ASk ) ] S (< P > T rue) (4) guarantees global QoS requirements at the same time. The
In summary, the abstract plan generation is given by algorithm
3. Starting with an empty plan, if the initial state of the world
Algorithm 3: Abstract Plan Modeling Algorithm
Input: Goal specification G; set of service types ASi
AS; KB
Output: Abstract service composition plan meeting
user requirements or nil as failure;
begin
Plan={}; A1 ABox;
while (Conj(A1 )Conj(G)) is satisfiable do
for each ASi AS do
if Match(ASi , G, KB) True then
if Conj(A1 ) ASi .Pre; then
A1 (A1 (Ef fi )) Ef fi ;
P P ASi ;
Initialize queue QueOfPlans with P;
while QueOfPlans is non-empty do
i=1;
for each Pk = headOf QueOfPlans do
for each ASi , ASi+1 Pk do
if Formula (1) is unsatisfiable and
Formula (2) is satisfiable then
i=i+1
; and reliability as QoS metrics.
if (Satisfy(Pk ,G))6=Nil then
return Pk as a successful plan;
headOf QueOfPlans= Pk+1 ;
remove Pk from QueOfPlans;
headOf QueOfPlans= Pk+1 ;
return nil
End
does not satisfy the goal; the composition process will be
launched. For each service type in the repository, if the service
type matches all or a part of the goal, the planner checks the
satisfiability of the preconditions of the matched type upon the
initial state. If it is verified, the effects of the type will be added
to the initial state and the service type will be integrated into
the plan. This process will be iterated until the goal will be
satisfied. Then the QueOf P lans list will be initialized by the
plan. For each plan in the QueOf P lans list two formulas F
and F1 will be tested for each two consecutive service types to
check dependency relationships and executability. If the plan
is checked correctly, it will be returned to the reasoner for
validation. If the satisfiability of all the plan is verified, the plan
will be validated and returned, otherwise, a failure message
will be returned and the planner retries another plan from the
QueOf P lans list.
106
C. QoS-aware composition
Taking the instances repository, the abstract plan as a
template and the non-functional requirements (NFR) as per-
missible QoS values, the Instance-Level Module selects an
optimal instance for each type component in the template until
generating an executable composition. This module not only
handles Multiple Criteria Decision Making (MCDM), but also
main components of this module are:
1) Assignment link between service type and instance:
The relationship between service type and service instance is
a kind of linking between a class and its instances. So that
a Web service type captures the core functionality, which the
individual instances belong to. We assume that the Web service
type remains valid when any of its Web service instance is
selected, which leads to facilitate the compensation in case
of planning failure or unavailability of the selected instance
during run-time. Such instanciation is based on two main
factors: a) ensuring that the preconditions of a Web service
type is more specific than that of some or all of its instances
and b) its effects are more general than that of any of its
instances. Formally, the relationship between the service type
and its instances are described as follow: a) S T ype .P re |=
S Instance .P re and b) S Instance .Ef f |= S T ype .Ef f .
2) QoS-Handler: It collects the QoS information from the
existing service instances and provides a QoS vector for each
instance. The handled values can be static or dynamic.
3) Selector: It is the main component of the instance-level
module. For space reasons, we just give a brief description
of this component and details can be found in [21]. The
selector picks exactly one instance from the set of matching
instances for each service type by taking into accountthe global
optimization of QoS criteria w.r.t the required QoS parameters.
In our model, we consider the cost, response time, availability
A constraint is associated with each QoS criteria. For
example, execution time and cost constraints require that the
aggregated time and cost of overall composition plan should
not be greater than the values given by the user. So that
each instance of each service type is selected according to
the following formulas:
Qk Ck ; if k {1, 2}
(
QoS constraints:
Qk Ck ; if k {3, 4}.
Where k is the index of QoS criteria so that: k= 1 for execution
cost,k=2 for response time, k= 3 for availability and k= 4
for reliability. Ck denotes the permissible value of the QoS
criteria k given by the user while Qk denotes the aggregated
value of the criteria k of the composition plan. After computing
the aggregated QoS criteria values, the composition plans are
evaluated in order to identify an optimal plan that minimizes
the constraint violation using the following objective function:
2 4
X Qk Ck X Ck Qk
min[{ wk .max( , 0)} + { wk .max( , 0)}]
Ck Ck
k=1 k=3
th
Where wk is the weight of the k QoS criteria defined by the
user to arrange the unsatisfied constraints in descending order
 4
and
P
wk =1. So that the QoS constraints with big weights
k=1
have more influence on the objective value than those with
small weights.
If the objective value is zero, it means that correspond-
ing service instances candidate satisfy all QoS constraints.
Otherwise, a neighbor plan P, in which some instances of
the current plan P are replaced with other instances, will be
evaluated. If P is better than the current plan in terms of the
objective function, the neighbor plan becomes the new current
plan. This kind of neighbor plan generation is iterated until
the objective value is zero or the number of iterations exceeds
a predefined limit.
4) Executable Composition Generator: The executable
Composition Generator is used to generate an executable
composition that can be deployed and executed onto a run-
time infrastructure.
V. C ONCLUSION
To address the problem of Web services composition and
provide an optimal value-add service, we propose in this
paper a two-level composition framework. Using a declarative
language based on Dynamic Description Logic (DDL), the
service type candidates are discovered by the DL-reasoner and
the planner automatically provides an abstract plan composed
of a two-to-many service types (capability) that corresponds to
a given goal. Then, the generated plan, the instances repository
and the user preferences (QoS criteria) will be taken as input
by the instance-level module to generate an optimal executable
composition.
Our future work includes improving our framework mainly
in the instance level and the QoS model and extending it
to work with WSMO ontology. In the absence of the model
differentiating service types from instances in WSMO, we aim
to show how some WSMO elements like ServiceProfile model
can be used to represent Web service type definitions. The task
of providing descriptions for specific Web service instances
will also be studied.
ACKNOWLEDGMENT
The work reported in this paper is supported by King Abdul
Aziz City for Sciences and Technology (KACST), Riyadh,
Kingdom of Saudi Arabia, under grant number 11-INF1776-
08.
R EFERENCES
[1] Li Kuang, Ying Li, Jian Wu, ShuiGuang Deng, and Zhaohui Wu.
Inverted indexing for composition-oriented service discovery. In ICWS,
pages 257264, 2007.
[2] Srividya Kona, Ajay Bansal, and Gopal Gupta. Automatic composition
of semanticweb services. In ICWS, pages 150158, 2007.
[3] Naiwen Lin, Ugur Kuter, and Evren Sirin. Web service composition
with user preferences. In Proceedings of the 5th European semantic web
conference on The semantic web: research and applications, ESWC08,
pages 629643, Berlin, Heidelberg, 2008. Springer-Verlag.
[4] Gerardo Canfora, Massimiliano Di Penta, Raffaele Esposito, and
Maria Luisa Villani. A framework for qos-aware binding and re-binding
of composite web services. J. Syst. Softw., 81(10):17541769, October
2008.
107
[5] Limin Chen, Hong Hu, and Zhongzhi Shi. Web service composition
as satisfiability checking in dynamic description logics. In Proceedings
of the 2009 Eighth International Conference on Grid and Cooperative
Computing, GCC 09, pages 5560, Washington, DC, USA, 2009. IEEE
Computer Society.
[6] Liang Chang, Fen Lin, and Zhongzhi Shi. A dynamic description
logic for representation and reasoning about actions. In Proceedings
of the 2nd international conference on Knowledge science, engineering
and management, KSEM07, pages 115127, Berlin, Heidelberg, 2007.
Springer-Verlag.
[7] Zhixiong Jiang, Leqiu Qian, Xin Pen, and Shisheng Zhu. Dynamic
description logic for describing semantic web services. In Computer and
Computational Sciences, 2007. IMSCCS 2007. Second International
Multi-Symposiums on, pages 212 219, aug. 2007.
[8] Liang Chang, Zhongzhi Shi, Lirong Qiu, and Fen Lin. Dynamic de-
scription logic: Embracing actions into description logic. In Description
Logics, 2007.
[9] Sana Baccar, Mohsen Rouached, and Mohamed Abid. A user require-
ments oriented semantic web services composition framework. IEEE
9th World Congress on Services 2013, To appear.
[10] Vikas Agarwal, Girish Chafle, Koustuv Dasgupta, Neeran Karnik, Arun
Kumar, Sumit Mittal, and Biplav Srivastava. Synthy: A system for
end to end composition of web services. Web Semant., 3(4):311339,
December 2005.
[11] Holleis. P. Programming interactive physical prototypes. 1st Intl
Workshop on Design and Integration Principles for Smart Objects
(DIPSO 07), 2007.
[12] Molood Makhlughian, Seyyed Mohsen Hashemi, Yousef Rastegari, and
Emad Pejman. Web service selection based on ranking of qos using
associative classification. CoRR, abs/1204.1425, 2012.
[13] Luokai Hu, Shi Ying, Kai Zhao, and Rui Chen. A semantic web service
description language. In Proceedings of the 2009 WASE International
Conference on Information Engineering - Volume 02, ICIE 09, pages
449452, Washington, DC, USA, 2009. IEEE Computer Society.
[14] Ronny Hartanto and Joachim Hertzberg. Fusing dl reasoning with
htn planning. In Proceedings of the 31st annual German conference
on Advances in Artificial Intelligence, KI 08, pages 6269, Berlin,
Heidelberg, 2008. Springer-Verlag.
[15] Guohua Shen, Zhiqiu Huang, Xiaodong Zhu, and Jun Yang. Reasoning
about web services with dynamic description logics. In Mark Burgin,
Masud H. Chowdhury, Chan H. Ham, Simone A. Ludwig, Weilian
Su, and Sumanth Yenduri, editors, CSIE (6), pages 106110. IEEE
Computer Society, 2009.
[16] Wei Liu Yu Yue Du Bao Qi Guo Chun Yan Qiang Xu. A fast
algorithm for web service composition based on dynamic description
logic. In Information Technology Journal, 9, 1150-1157. Asian Network
for Scientific Information, 2011.
[17] Zeina Azmeh, Maha Driss, Fady Hamoui, Marianne Huchard, Naouel
Moha, and Chouki Tibermacine. Selection of Composable Web Services
Driven by User Requirements. In IEEE Computer Society, editor,
ICWS11: 9th IEEE International Conference on Web Services - Ap-
plications and Experiences Track, page 8, Etats-Unis, Jul 2011.
[18] Wei Jiang, Charles Zhang, Zhenqiu Huang, Mingwen Chen, Songlin
Hu, and Zhiyong Liu. Qsynth: A tool for qos-aware automatic service
composition. In ICWS, pages 4249, 2010.
[19] Zachary J. Oster, Ganesh Ram Santhanam, and Samik Basu. Identifying
optimal composite services by decomposing the service composition
problem. In Proceedings of the 2011 IEEE International Conference
on Web Services, ICWS 11, pages 267274, Washington, DC, USA,
2011. IEEE Computer Society.
[20] Franz Baader, Ian Horrocks, and Ulrike Sattler. Description logics as
ontology languages for the semantic web. In Mechanizing Mathematical
Reasoning, pages 228248, 2005.
[21] Jong Myoung Ko, Chang Ouk Kim, and Ick-Hyun Kwon. Quality-
of-service oriented web service composition algorithm and planning
architecture. Journal of Systems and Software, 81(11):2079 2090,
2008.