Dynamic Service Composition Using Semantic Information
Keita Fujii
School of Information and Computer Science
University of California
Irvine, CA 92697, USA
+1-949-824-4105
kfujii@ics.uci.edu
Tatsuya Suda
School of Information and Computer Science
University of California
Irvine, CA, 92697 USA
+1-949-824-4105
suda@ics.uci.edu

ABSTRACT
Dynamic composition of complex services from primitive
components brings flexibility and adaptability to future
applications. By properly selecting and combining components on
demand, applications would adapt to individual user preference
and would consider available context information.
Existing service composition systems often require users to
request services in strict syntax formats, such as data types,
service templates or logic formulas. This requirement may become
an obstacle for end-users to use such systems. Instead, service
composition should be semantics-based so that a service is
requested and composed not by its syntax but by its semantics.
In order to enable semantics-based dynamic service composition,
both the modeling of components as well as the service
composition mechanism must support semantics. To satisfy the
requirement of semantic support in the component modeling, we
have designed a new model named Component Service Model
with Semantics (CoSMoS). CoSMoS integrates the semantic
information of a component and the functional information of a
component into a single semantic graph representation. A unified
interface named Component Runtime Environment (CoRE) is
developed to convert different component implementations onto
the CoSMoS representation. Using the semantic support of
CoSMoS, we have developed a semantics-based service
composition mechanism named Semantic Graph based Service
Composition (SeGSeC). SeGSeC generates the execution path of
the requested service, and checks the semantics of the path against
the request. We have implemented a service composition system
using the above techniques, and demonstrated that our system
supports semantics-based dynamic service composition.
Categories and Subject Descriptors
I.2.2 [Artificial Intelligence]: Automatic Programming –
program synthesis; I.2.4 [Artificial Intelligence]: Knowledge
Representation Formalisms and Methods – Semantic networks;
D.2.10 [Software Engineering]: Design – Representation.
General Terms: Algorithms, Design
Keywords: Dynamic service composition, component model,
semantic graph, CoSMoS, CoRE, SeGSeC
1. INTRODUCTION
Distributed component technologies such as CORBA and Web
Service bring a new vision of a future network environment where
a large number of components representing software services,
devices, or resources are distributed and transparently accessible.
In such an environment, a new application may be composed from
a set of components. This concept of composing complex
services (or applications) from primitive components is called
service composition. Service composition enables quick
development of new application functionality through the reuse of
the components for multiple compositions [14].
Service composition techniques can be categorized into two types:
static service composition, and dynamic service composition [5].
Static (or proactive) service composition is an approach in which
application designers implement a new application manually by
designing a workflow or a state chart describing the interaction
pattern among components. BPEL4WS [2] or WSCI [17], for
example, are primarily designed for supporting this approach. The
static service composition supports applications involving
complex interaction patterns, such as branch or iteration, but
requires those applications to be manually designed before being
deployed. Therefore, the static service composition is suitable for
B2B type applications where interactions among components are
often complex but static and easy to provision.
Dynamic (or reactive) service composition, on the other hand,
composes an application autonomously when a user queries for an
application. eFlow [4] and SWORD [13] are the examples of
dynamic service composition systems. Because the dynamic
service composition does not depend on a human to compose an
application, it may have difficulty in composing applications with
complex interaction patterns. Nevertheless, the dynamic service
composition has the potential to realize flexible and adaptable
applications by properly selecting and combining components
based on the user request and context. The dynamic service
composition may also elicit a number of useful applications that
are not envisioned at the design time. Therefore, the dynamic
service composition is suitable for end-user applications in
ubiquitous, mobile environments where available components are
dynamic and expected users may vary. Since we believe that the
dynamic service composition is the key technology for enabling
future ubiquitous applications, this paper focuses its topics on the
dynamic service composition.

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
ICSOC'04, November 15–19, 2004, New York, New York, USA.
Copyright 2004 ACM 1-58113-871-7/04/0011...$5.00.

39

To illustrate the benefit and issues of the dynamic service
composition, let us give an example scenario here. Suppose Tom
wants to take his family to a restaurant he recently found on the
web. Since he is unsure of the direction from his home to the
restaurant, he decides to print out and carry the directions with
him. Assume that 1) the restaurant’s Web server stores the
restaurant’s information such as its address or menus in a
structured document (e.g., in XML), 2) Tom’s PC stores the
information about Tom and his house, such as its address, phone
number etc, in a database, 3) there is a Web service which, given
two address information, generates an image showing the
direction from one address to another, and 4) Tom has a printer
which is connected to his home network. With the current
technologies, Tom can print out the direction from his home to the
restaurant. However, he has to perform each step, i.e. get the
address of the restaurant and his home, invoke the direction
generator Web service, and print out the resulted image, manually
by himself. If the dynamic service composition is available, Tom
can simply type (or speak) a command “print out a direction from
home to the restaurant” onto his PC, and he can receive the
printed direction as he requested.
There already exist several dynamic service composition systems
researched and developed (e.g. eFlow, STONE). However, those
existing systems often require users to request services in strict
syntax formats, such as data types (e.g. string, image/jpeg, etc),
service templates (e.g. pass address data to a direction service) or
logic formulas (e.g. address (X) & address(Y) Æ direction(X,Y)).
This requirement may become an obstacle for end-users to use
such systems. Instead of using such syntax information, a user
should be able to request a service using its semantics, and the
dynamic service composition should be able to compose the
requested service based on the semantics of the user request.
In order to enable semantics-based dynamic service composition,
both modeling of components as well as the dynamic service
composition mechanism must support semantics. A component
model must be able to represent not only the functional
information of a component (i.e. data type, input/output etc) but
also the semantic information of a component (i.e. what
component represents etc). At the same time, such a component
model should keep as much compatibility as possible with
existing component technologies. Also, a dynamic service
composition mechanism should allow a user to request a service
by its semantics, and should be able to compose a service based
on the semantics of the user request by taking advantage of the
semantic representation of the component model.
To satisfy the above requirements, we have developed (1)
Component Service Model with Semantic (CoSMoS), (2)
Component Runtime Environment (CoRE), and (3) Semantic
Graph based Service Composition (SeGSeC). CoSMoS integrates
the semantic information of a component and the functional
information of a component into a single semantic graph
representation. CoRE acts as middleware to convert different
component implementations onto CoSMoS representation.
SeGSeC allows a user to request a service using a natural
language sentence, and generates the execution path of the
requested service based on the user request. SeGSeC also
performs semantic matching to confirm that the semantics of the
generated path matches the semantics of the user request. Figure 1
shows the architecture of our semantics-based dynamic service
composition system.
CoRE
Various Component Technologies
SeGSeC
CoSMoS
Various Component Technologies
arious Co ponent Technologies

Figure 1. Architecture of the proposed system
The remaining sections of this paper will give details of the
proposed work as follows. Section 2 describes CoSMoS. Section
3 presents CoRE. Section 4 illustrates SeGSeC. Section 5
concludes this paper.
2. COMPONENT SERVICE MODEL WITH
SEMANTICS (CoSMoS)
This section introduces a new component model named
Component Service Model with Semantics (CoSMoS). CoSMoS
is an abstract model that represents a component as a single
semantic graph. CoSMoS is designed to integrate the functional
information of a component and the semantic and logical aspects
of the component. This section first gives an overview of
CoSMoS, which is followed by the detailed design of CoSMoS.
2.1 CoSMoS Overview
2.1.1 CoSMoS Domains
Many existing component models (e.g. WSDL, JavaBeans/EJB,
COM, CCM etc) often lack the capability of representing the
semantics of components. Therefore, those models require human
application designers to understand, judge and match semantics of
components, which prevents autonomous composition of
applications. Instead, a component model should be able to
represent not only the functional information but also the
semantics information of a component. In order to satisfy this
requirement, CoSMoS defines four domains, namely, data type
domain, semantics domain, logic domain, and component domain
(Figure 2).
Semantics domain Data type domain Logic domain
Component
domain
Concepts
Data
types
Logics

Figure 2. CoSMoS domains
Each domain captures a different aspect of a component. The data
type domain defines data types, i.e., data formats of components,
and relationships among data types. The semantics domain
defines concepts, i.e., entities representing abstract ideas or
actions, and ontologies, i.e., relationships among concepts. The
logic domain defines logics, i.e., knowledge or rules about
components’ service. The component domain defines components
by combining data types, concepts and logics defined in the other
40