Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
Web Services Composition with Traceability Centered on Dependency
Jong Woo Kim and Radhika Jain
Department of Computer Information Systems
Georgia State University, Atlanta, GA 30303
Email :{ jkim, rjain}@cis.gsu.edu
Abstract
Web services composition is becoming increasingly
important as organizations are now getting ready to
provide more complex service-based applications.
Contemporary literature on the web services composition
primarily addresses various aspects of composition for
example,
automated
composition,
quality-driven
composition, and semantic composition. These
approaches, however, do not adequately address the
various dependencies among the tasks performed by the
web services. Such dependencies could potentially affect
how the web services are composed. Additionally
business rules play a crucial role for achieving dynamic
composition of web services. In this article we present our
task dependency approach for web services composition
driven by business rules.
1. Introduction
As web services mature to become basic building
blocks of Service Oriented Architecture (SOA), the web
services composition is becoming one of the main
concerns of the application development process [7]. SOA
is an architectural style whose goal is to achieve loose
coupling among interacting software agents. To achieve a
complex service-based application in SOA environment,
orchestration and composition of web services is crucial.
Modularized, self-describing nature of web services
makes them a promising technology for realizing SOA.
Both provider and consumer roles are played by the
software agents on behalf of their owners [13]. We argue
that capturing and managing rationale behind web
services composition will be critical as application
development continues to incorporate multitude of
modularized, atomic web services. While the current
literature on the web services composition addresses
various aspects of composition such as automated,
quality-driven, and semantic composition, they do not
adequately address the various dependencies among the
tasks performed by the web services. Dependency links
are considered to be one type of the traceability links,
which is seen as one of the essential quality factors to
improve software development efforts [30]. As web
services emerge as a new paradigm for the software
development, traceability needs to be taken into
consideration for the better composition of modular web
services-based applications. In SOA environment, the
applications will be comprised of large number of
modular web services. One of the major issues in
developing such applications is how to compose these
web services in a meaningful way to satisfy business
needs of an organization in a dynamic environment.
In this article, we present our task dependency based
approach for web services composition driven by business
rules. Business rules play a crucial role for achieving
dynamic composition of web services. The research
presented here addresses three primary issues: 1) how to
capture the rationale behind the composition of web
services, 2) what kind of dependencies exist among the
business rules and tasks, and 3) how dependency among
business rules and tasks affects web services composition.
Outline of the paper is as follows. In the next section,
we briefly review SOA and web services literature. We
then present a brief review of the extant literature on web
services composition and point out limitations of these
existing approaches. In Section 3, we briefly review the
traceability and dependency literature that forms the basis
of our conceptual model. We then present business rules
literature, identify various types of dependencies among
the business rules, and suggest how dependencies among
the business rules can affect the web services composition.
We then identify various dependencies among the tasks
that could potentially affect the web services composition
and present our conceptual model for the web services
composition to manage such dependencies. Section 4
illustrates an e-commerce scenario and demonstrates how
dependencies among the business rules as well as tasks
affect web services composition. We then identify various
features of our web services composition manager tool to
support such dependency based approach to the web
services composition.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
1
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
2. Web services and service oriented
architecture (SOA)
A web service is an interface that describes a collection
of operations that are network accessible through
standardized XML messaging specifications such as
Simple Object Access Protocol (SOAP), Web Services
Description Language (WSDL) and Universal Description,
Discovery and Integration (UDDI) [17]. These XML
specifications (SOAP, WSDL and UDDI) provide open
XML-based mechanisms for application interoperability,
service description, and service discovery. Many
researchers and vendors provide early implementations of
technologies and have either proposed or drafted various
standards to support the development of web services.
These efforts are focused on areas such as security,
composition and semantic web to enable their effective
and complete development [7, 18].
Service Oriented Architecture (SOA) is a collection of
services on a network that communicate with each other
[2, 8]. In other words with SOA, enterprise software
systems and applications can discover and make
themselves avail of various resources on a network as
services and provide functionality to business while
hiding the underlying implementation details [9]. SOA
entails changing a way of structuring applications,
organizing IT infrastructure and standardizing business
functionalities. While SOA is not a new idea but the
culmination of decades of evolution in existing practices
such as object oriented programming, component-based
software development and integration middleware, it is
receiving renewed attention in the light of maturity of
web services and the related technologies.
Loosely coupled web services provide for modularity
and flexibility in complex, distributed IT environment
[35], emerging as a catalyst for SOA. A well designed
SOA is therefore likely to be comprised of a relatively
large number of modular web services. Web services
become the basic building blocks from which new
applications can be composed. This suggests for service
composition as one of the main concerns in the software
application development process [36].
There is a growing amount of interest and literature on
various web services composition mechanisms [23-25,
29]. As the business needs of an organization change as a
result of change in its environment and emerging IT
innovations, its IT infrastructure also needs to be
reconfigured dynamically to accommodate such changes.
This process of making such changes can involve
substantial system integration and/or development efforts,
resulting in difficulties with keeping track of all the
changes made to the service-oriented IT infrastructure.
The rationale embedded behind implementing these
changes needs to be captured, which otherwise may be
lost during the development process. As the web services
composition changes from one given specific
configuration to another to accommodate changing
business needs, knowledge associated with this process
would be lost without any mechanism for recording such
rationale. In a full fledged web services enabled SOA
environment, managing the composition of various
modularized services will become a top concern.
In the next subsection we briefly review the web
services literature on standards such as BPEL4WS,
DAML-S, and relevant research literature on the web
services composition.
2.1. Related work on the web services
composition
To support web services composition, web services
standards regulation organizations are working on various
composition standards. Various standards (XLANG and
WSFL) initially competed with each other [23] although
now BPEL (also known as BPEL4WS) is gaining
momentum. The popularity of BPEL is primarily the
result of the fusion of the features from XLANG from
Microsoft and WSFL from IBM [26] as the two giants
combined their forces on these standards development.
While BPEL offers definition of business protocols and
supports fault handling and compensation, it does not
address conformance and quality of service issues [24].
Additionally using BPEL alone, the properties of
composition cannot be verified [24]. Furthermore, BPEL
is not well suited to many of the automated reasoning
tasks envisioned by semantic web services [4, 22].
While BPEL provides for syntactic composition,
OWL-S supports ontology-based semantic approach for
the composition of web services. OWL-S is an initiative
of semantic web community to facilitate automatic
discovery, invocation, composition, interoperation and
monitoring of web services through their semantic
description. OWL-S (formerly DAML-S) [21] provides
web service providers with a core set of markup language
constructs for describing the properties and capabilities of
their web services in an unambiguous, computerinterpretable form with its well-defined semantics.
Although OWL-S provides semantics allowing for
reasoning about a service and takes an important step
toward the ultimate goal of dynamic service discovery
and usage, it is still not mature enough for use in
describing web services. Sabou et al. [31] based on their
experiences in using DAML-S suggest that DAML-S is
difficult to learn and has an imprecise underlying
conceptual model leading to multiple modeling
possibilities and parametric polymorphism. Also its
chosen mapping to WSDL often limits the expressability
of DAML-S [31].
Mandell and Mcllraith [20] suggest combining BPEL
and semantic standards like DAML-S to achieve 1)
automatic, runtime binding of service partners, 2)
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
2
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
selection between multiple service partners based on userdefined preferences and constraints, and 3) integration of
service partners with syntactically distinct but
semantically translatable service descriptions. Zeng et al
[37] suggest that the selection of component web services
during composition should be carried out during the
execution of a composite web service, rather than at the
design-time. They consider multiple criteria such as price,
duration, and reliability and also take into account global
constraints and preferences such as budget constraints set
by a user for the composition purposes. Kim and Gil [16]
argue for interactive composition of semantic web
services when developing complex applications.
These approaches focus primarily on finding
appropriate web services for carrying out various tasks
and automating their composition. While such approaches
may work as long as the existing composition is
unchanged i.e. to say that these approaches assume the
presence of the predefined steps of various tasks and
activities. However, the existing composition may need to
change for a variety of reasons for example, due to
changes in the market conditions or changes in the
customer requirements. Such changes in the business
environment are usually reflected in the organization’s
business rules. These changes result in the modification of
the existing web services composition underlying the
service-oriented IT infrastructure. Before such recomposition can take place, one needs to pay attention to
and manage various dependencies among the tasks [19].
These dependencies among the tasks need to be managed
to preserve the rationale behind various decisions taken.
Without appropriate tools, finding, recording, and
managing rationale behind them could become a daunting
task [30]. Managing abstract objectives is becoming more
important than ever in web services oriented software
development environment. Mandell and Mcllraith [20]
acknowledge that to achieve automated web services
composition requires a fundamental shift in industrial
frameworks from executing predefined process models to
computing and adapting execution plans from abstract
objectives.
In the next section we provide brief review of
traceability and dependency literature. We then present
our conceptual framework for task dependency based
approach driven by the business rules.
3. Traceability
Traceability is the ability to describe and follow the
lifecycle of the conceptual or physical artifact in both
backward (pre-traceability) and forward (posttraceability) direction. [10] For example, in the field of
requirements engineering traceability helps demonstrate
that all the requirements are addressed by the various
artifacts/features/components created during the system
development life cycle and that the requirement can be
traced back to its origin. It enables the capture of the
rationale behind various decisions taken which are
essential sources of reuse. This rationale helps alleviate
many complications faced during the change integration
process. Requirements traceability facilitates better testing,
inspections, system acceptance, and maintenance
activities [28] and communication among various
stakeholders by linking the requirements to various
sources and artifacts [30].
The efficiency and effectiveness of traceability support
are determined by object types and traceability link types
[30]. Ramesh and Jarke [30] classify traceability links
into four categories: rationale, dependency, satisfies, and
evolves-to traceability link. Of these four link types,
dependency and rationale links are the most commonly
observed link types. Here we focus on the dependency
links for web services composition as it enables tracing of
the composition and object hierarchies and managing
effect of changes in one object on other objects that
depend on it [30]. Therefore, developing dependency
support mechanisms at an appropriate abstract level will
be valuable in automatic web services composition. In
addition to expressing dependency links, the strength of
dependency links needs to be identified for better
understanding the effects of changes in dependency. In
the next subsections we focus on business rules, tasks,
and dependencies among tasks as coordination means
[19] for managing dependencies.
3.1. Business rules
Business Rules Group [1] defines business rules from a
business perspective as a guidance that there is an
obligation concerning conduct, action, practice, or
procedure within a particular activity or sphere and as
programmatic implementations of the policies and
practices of an organization [11]. Business rules control
or influence various aspects of the business [11] such as
• When to restock inventory
• Whether or not to extend credit to a customer and
how much to extend
• Whether or not to compute sales tax, etc.
Business rules-driven approaches are getting much
attention recently due to various reasons such as (1)
maturity of emerging technologies such as web services,
(2) dramatically fallen cost of the IT processing power
needed for rules automation, and (3) the need for a
flexible and prompt reaction on the changing market
requirements. Rules-based interaction makes it easy both
to add capabilities to processes, and to customize the
interaction for individual users [12].
Unfortunately, too often business rules are inaccessible
or worse, unknown. This is the case when business rules
are buried in legacy code, for which there exists little or
no documentation. When such rules are inaccessible or
unknown, assumptions about them are made that may be
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
3
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
incorrect or inconsistent. Such assumptions lead to
behavior (human or electronic) that is not well
orchestrated, not effectively focused on common
objectives, and certainly not capable of easy changes and
adaptability.
Table 1 shows the two basic types of business rules for
the web services composition. Supporting business rules
such as computation and inference rules are not directly
involved with the web services composition. They support
the web services composition by providing interpretation
tools for operational business rules. These operational
business rules enable business tasks and processes
implemented with web services. For business rules to be
used for web services composition, they should be
modularized [12, 25]. As a result, the need to regulate the
relationship among the business rules in terms of
dependency exists.
Table 1: Basic type of business rules [12, 15]
Types
Supporting
Business
Rules
Definition
Rules to
support
operational
business
rules
Operational
Business
Rules
Rules to
support
business
tasks and
processes
Example
Computation Rules
(e.g. today-birth date
= age)
Inference Rules (e.g.
if customers are older
than 18, they are
adults)
Mandatory
Constraint Rules (e.g.
if customers are under
18, they cannot buy
products for adults)
Action Enabler Rules
(e.g. recommends
products based on
customers’
preference)
Finding and defining the mechanism of dependencies
among the related business rules can help the web
services composition as business rules capture rationale
behind the composition. Various web services usage
scenarios [3, 14] suggest that the composition of web
services is affected by user activities and other web
services. For example, the selection of a product or a
delivery option affects the composition of subsequent web
services.
In the next subsection, we briefly review various
dependency types among the business rules.
3.2. Business rules dependency
Here we employ the dependency classification
proposed by Bühne et al [5] for demonstrating the
dependency among the business rules in the context of
web services composition (Refer to Table 2). The most
common dependency type found in the business rules is
the requirement dependency. A business rule under this
dependency needs to be addressed before another
business rule is implemented. For example, if the user is
government, then tax calculation is not needed. If tax
calculation is not included, total calculation should not
include tax calculation.
Table 2: Dependency types among business rules
Dependency
Types
Requirement
Exclusive
Hint
Hinder
Example
The type of customer should be
known. (A)
The government customers do not
need to pay tax. (B)
Rule (B) requires rule (A).
Normal users should pay tax. (A)
Government users do not need to
pay tax. (B)
If rule (A) is selected, rule (B) will
be excluded.
Loosen the standards for the
selection of delivery company (A)
Provide as many delivery options
as possible (B)
Rule (A) has positive impacts on
rule (B)
Perishable products should be
delivered in a fast manner (A)
Company should provide
customers with many delivery
options (B)
With the following business rules, we can find
dependency among business rules. E-Product does not
require locating processes (A). If the locating processes
don’t exist, then delivery option shall not be provided (B).
In case of an e-product such as e-books, the business rule
A provides the reason why the business rule B can be
realized in case of A. Therefore, we can conclude that
there is a requirement dependency between business rules
A and B. As a result, a web service for delivery options
will be removed in case of e-books according to the
interpretation of the related business rules.
Business rules affect both the procedural and
provisional aspects of the web service composition. For
example, for the procedural composition of web services,
there are three logical location procedures according to
the location of the product – 1) store->warehouse>manufacturer (a basic procedure), 2) warehouse>manufacturer, 3) manufacturer. The related two business
rules are (A) the product location procedure should start
from the location of the product, and (B) the location of
the product is determined by the type of a product.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
4
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
Therefore, these two business rules affect provision of
three candidate procedures for the web service
composition from the procedural and provisional
perspective.
These dependencies among the business rules can
enrich the traceability links to maintain the consistency of
applications. They can also help avoid composing
redundant web services in advance. Likewise, application
developers can ascertain which web services would be
affected when the related business rules are changed. For
this purpose, relationship between business rules needs to
be defined and well organized.
In the next subsection, we discuss the task dependency
and how it can affect web services composition. We then
present our conceptual model that takes into account both
the business rules and the task dependency for the web
services composition.
3.3. Task dependency
Dependencies among the tasks need to be preserved
during the re-composition efforts to maintain the integrity
of the entire process. We briefly review the prominent
literature in the area of task-related dependencies.
Malone et al [19] in their study of coordination
mechanisms, suggests different types of dependencies
among the tasks and the resources consumed by these
tasks. These basic types are flow, sharing, and fit
dependencies. Flow dependency suggests that the output
of one task is input of another task. Furthermore, in such
case, it may be required to have the right input to be
available at the right time in the right place. Flow
dependency type is the most commonly occurring and is
present implicitly in other two dependency types. Sharing
dependency suggests that the same resource is used by the
multiple tasks or activities. Finally, fit dependency
suggests that multiple activities collectively produce one
resource or output. Different coordination mechanisms
[19] need to be implemented in order to manage these
different dependencies. These dependency types provide
an overall framework for our task dependency model.
As part of PRO-ART, a prototypical process-centered
requirements engineering environment developed in the
Esprit project NATURE, Pohl [27] identifies 18 different
types of dependencies in the context of the requirements
traceability. These are categorized in five disjoint link
classes, namely: condition, content, document,
evolutionary, and abstraction links.
Dependency types proposed by Yu and Mylopoulos
[33] provide various semantics to such dependencies. In
their actor dependency model [33], they classify types of
dependencies based on the ontological categories of the
dependum (the object around which two actors have
dependency) and suggest for various mechanisms such as
enforcement, assurance, and insurance to ensure their
viability. These categories are goal, resource, and task
dependencies. In goal dependency, a depender depends
upon a dependee to make a condition in the world come
true. In task dependency, a depender depends upon a
dependee to perform some activity, while the goal for
having performed activity is not given. Finally, in
resource dependency a depender depends upon a
dependee for the availability of an entity. They
additionally distinguish among the degrees of strength as
open, committed, and critical dependency.
Table 3: Dependency and coordination mechanisms
(adapted from [19])
Dependency Types
Coordination
Mechanisms
Flow
Prerequisite
Usability
Accessibility
Notification
Standardization
Transportation
Sharing
Resource allocation
Fit
Synchronization
* Dependency Strength: open, committed, critical
Revising definitions of these dependency types to
reflect the web services environment, goal dependency
can be re-defined as the task performed by one web
service depends upon the task performed by another web
service to make a condition in the world come true.
Similarly, task and resource dependencies can be redefined in the context of web services. Furthermore,
degree of strengths of these dependencies will play an
important role in the composition of web services.
In the service-oriented IT infrastructure enabled by
web services, tasks are likely to be performed by both the
web services as well as human actors. Thus, we now have
three different dependency types based on who performs
the task, namely: human-human, WS-WS, and humanWS dependency (Note: WS stands for web service).
Human-human dependencies among the tasks performed
arise when both the actors involved are humans.
Dependency types as proposed by the Yu and Mylopoulos
can be easily extended here. This is a scenario where
intensive human collaboration and coordination is
involved. Here human actors may in turn depend upon the
some other IT applications/services. Extant literature is
focused on what dependencies exist and how such
dependencies are to be managed when both the actors are
human. Second dependency type is when all the tasks are
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
5
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
being performed (or can be performed) by the web
services. This represents the case when all the tasks can
be automated and rarely any human intervention is needed
barring the situations involving exceptions. Finally, third
case represents a dependency scenario where some tasks
are performed by the human actors and others are being
performed by the web services. In such situation many
factors need to be taken into consideration. With the
growing importance and popularity of the web services
enabled IT infrastructure, however, attention needs to be
given to the latter two categories of dependencies viz.
human-WS and WS-WS dependencies. We explain WSWS dependency in detail. Here, we do not address the
third type of dependency, human-WS dependency.
In case of WS-WS dependency since all the tasks are
performed by the web services, different types of
dependencies come into play. While the dependency types
mentioned by Yu and Mylopoulos [33] apply in this case,
we identify three more dependencies here, namely:
interface dependency, quality of service (QoS)
dependency, and protocol mediation dependency. In
interface dependency scenario, since no human is
involved, tasks to be accomplished by the involved web
services need to be well-defined and their input and
output interfaces need to be well understood. This is
important in order to correctly achieve the desired
functionality. Such dependency can be potentially
handled by various match-making mechanisms. However,
it may not be sufficient to just provide the required
functionality. Depender web service may need to
guarantee various non-functional requirements in order
for it to be a desirable candidate to be involved in the web
services composition. Some examples of the non-
functional requirements include availability, reliability,
response-time, fidelity, accessibility, etc. These quality of
service dependencies become even more crucial when the
tasks to be performed exhibit fit and sharing dependencies
as described by Malone et al [19]. Furthermore, when
some of the web services are third party web services that
need to be accessed remotely, security becomes an
important consideration. QoS dependency could be
potentially handled by various negotiation and security
protocols that are currently under development. Finally,
protocol mediation dependency suggests that if the endpoints of the involved web services are not all SOAPbased, then this dependency arises. Some sort of adapter
mechanisms is needed before such web services are
chosen in the composition.
Figure 1 illustrates various dependencies among the
tasks as well as among the business rules for the web
services composition. It also captures the roles played by
various stakeholders. It also suggests that a task can be
performed by either a human entity or by a web service.
Business rules provide the overall context in which tasks
are to be performed and govern the task execution. We
use this conceptual framework to implement our
prototype Web Services Manger (WSM) that supports
business rules and task dependencies in the web services
composition. This prototype can instantiate various
building blocks of the conceptual model shown in Figure
1. We demonstrate the functionality of the prototype with
an e-commerce scenario for online shopping in the next
section. The scenario presented demonstrates the need to
take into consideration various business rules and task
dependencies in the due process of the web services
composition.
Figure 1: Conceptual model for the web services composition
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
6
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
4. E-commerce scenario
In an online shopping scenario, consumers typically
browse through the online catalog to view various
products/services offered by an online business before
making any purchase. Basic tasks involved in such a
scenario typically include determining consumer type
(revisiting user, first-time user, government, etc.),
providing check-out, and shipping and delivery services.
While the consumer is browsing through the catalog, one
might display the availability of the item. During checkout activity, various sub-tasks such as determining the
shipping method and rate, calculating the total price,
verifying the payment information, etc. need to be
completed. To enhance the customer service, online
business may offer approximate delivery date.
Determination of the delivery date depends upon the
shipping method, availability of the product, and the
weather at both the start and destination location. Figure 2
shows these various basic e-commerce tasks and subtasks. From the figure, it is clear that there exist a large
number of potentially possible combinations even for
such a simple scenario. This scenario highlights the
complexity involved in web services composition and the
need to capture the rationale behind various composition
efforts.
Some of these tasks may be performed by the web
services. For example, determination of delivery date can
be performed by a third party web service, which further
depends upon several other web services to get the
necessary information such as delivery method, product
availability, and weather check web services. It also
suggests a large number of combinations that can increase
the complexity of web services composition.
Figure 2: Various tasks involved in online shopping scenario and possible options for each task
We now discuss the two possible scenarios in which a
consumer makes an online purchase. In the first scenario
we assume the basic shopping process where before a
consumer can purchase an item, he/she needs to log-in.
Also in this scenario, consumer may not know the
approximate delivery date and total price unless he/she
logs-in and completes various activities within the checkout task. Figure 3 shows this basic scenario and detailed
breakdown of these various activities. Check-out task is
broken down into four main sub-tasks. After receiving the
choice of shipping method from the consumer,
determining delivery date requires the results from two
other sub-tasks (product availability and weather check,
fit dependency). Shipping services may be provided by
various shipping companies (e.g. Fedex, UPS, USPS).
The task of calculating total price is further broken down
into three other sub-tasks: tax calculation, shipping rate
calculation and validating coupon code (if any). Tax
calculation sub-task is potentially affected by various
business rules such as government users are not subject to
tax or state laws exempt sales tax for goods purchased
online or certain days are tax-exempt. Both tasks of
calculating shipping rate and validating coupon code are
dependent on the result of a previous task and user
activity.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
7
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
Figure 3: Tasks in basic online shopping e-commerce
scenario
Figure 4 shows the stakeholder ‘Smith’ managing
various business rules. Various dependencies among the
business rules as well as the dependencies among the
tasks are captured using the WSM prototype. Current
business rule ‘DisplayDeliverDateDuringCheckout’ is
dependent upon ‘ShippingMethodSelection’. It also
shows how the tasks performed by the web services are
dependent upon each other.
Few studies that examine online purchasing behavior
of the users suggest that by making the process more
‘effort-saving’ can result in the increased ratio of buyervisitors [6]. Some examples of such changes include
provision of approximate delivery date and total price
even before the consumer logs-in. Having such
information available without going through check-out is
likely to result in more buyers. This suggests for the
change in not only the business rule but also the change in
the basic sequence of tasks as shown in Figure 3. The
current business rule may suggest for providing the
delivery date and total price information only after the
consumer logs in. However, with this new market
information, new changed business rule may now require
providing the delivery date and total price information at
the same time as a consumer is browsing through the
online catalog.
This requires changes in the existing way of
performing check-out task. For example, calculation of
delivery date and price will need to be done at the same
time as browsing. This will require re-doing the web
services composition to reflect the same. Also during the
check-out, these selected options may be redisplayed if
the consumer needs to make any change and enter coupon
codes (if any). During such re-composition, dependencies
among the tasks will need to be addressed. For example in
this modified scenario, fit dependency between the web
services performing the task of ‘determine the delivery
date’ and the web services performing various sub-tasks
such as checking product availability, shipping method,
and weather check, need to be preserved.
In Figure 4, this change in business rule is shown and
how it affects the various tasks that are dependent on it.
Further, it shows how the dependencies between the tasks
‘DeliveryDateCalculation’
and
its
subtasks
‘ShippingMethodSelection’, ‘CheckProductAvailability,
and ‘WeatherCheck’ are preserved even though these
tasks are now performed before the user logs-in.
Figure 4: Managing business rules and task dependencies using WSM prototype
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
8
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
5. Contributions and future research
The primary contribution of our work is the
development of a representational framework and support
tools for managing dependencies among tasks driven by
business rules to reduce the complexity in the dynamic
web services composition. Rationale behind the selection
and composition of web services can be captured by
focusing on the relationships between the tasks driven by
business rules and web services. It can be used to
categorize and capture dependency among tasks driven by
business rules. With well organized tasks and business
rules based on dependency, agility of firm’s web services
enabled service-oriented IT infrastructure can be
enhanced. Agility of an organization’s IT infrastructure
has been considered as one of the crucial factors in
enabling and crafting competitive advantage when coping
with continuously changing business environment [34].
Furthermore with well defined and documented
dependencies, organizations can better understand and
improve their capabilities associated with managing their
sourcing strategies and relationships.
We are conducting further case studies to evaluate our
approach. We plan to extend our approach using
Dependency Markup Language (DML) [32] to express
our dependency model in XML and integrate it with other
composition protocols. Further research will focus on how
this dependency-based approach can be used for rulebased inference engine.
6. References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
Defining Business Rules...What is a Business Rule?
Available
at
http://www.businessrulesgroup.org/brgdefn.htm, 2004.
Service-oriented architecture (SOA), Barry & Associates,
Inc., 2004.
Anderson, S., et al., Supply Chain Management Use Case
Model,
http://www.wsi.org/SampleApplications/SupplyChainManagement/200312/SCMUseCases1.0.pdf, Web Services-Interoperability
Organization, 2003.
Aral, S., Automating Orchestration: Bridges toward
Semantic Web Services (Draft version) Available at
http://web.mit.edu/sinana/www/SemanticWebServicesSinanAral.pdf, 2004..m
Bühne, S., G. Halmans, and K. Pohl, "Modelling
Dependencies between Variation Points in Use Case
Diagrams", in Proceedings of Ninth International
Workshop on Requirements Engineering: Foundation for
Software Quality. In conjunction with CAiSE'03,
Klagenfurt/Velden, Austria, 2003.
Cho, J., "Likelihood to abort an online transaction:
influences from cognitive evaluations, attitudes, and
behavioral variables", Information & Management, vol. 41,
2004, p. 827-838.
[20]
[21]
[22]
[23]
[24]
[25]
Curbera, F., et al., "The next step in web services",
Communications of the ACM, vol. 46, 2003, p. 29-34.
Datz, T., "What You Need to Know About ServiceOriented Architecture", CIO, vol. 17, 2004, p. 1.
Deb, S., Web Services: Towards Realization of the
Service-Oriented Enterprise, 2004.
Gotel, O. and A. Finkelstein, "An Analysis of the
Requirements Traceability Problem", in Proceedings of
First International Conference on Requirements
Engineering, Colorado Springs, Colorado, 1994.
Gould, D., Virtual Organization: Business Rules, 2000.
Halle, B.v., Business Rules Applied: Building Better
Systems Using the Business Rules Approach, John Wiley
& Sons, 2002.
Hashimi, S., Service-Oriented Architecture Explained,
Available
at
http://www.ondotnet.com/pub/a/dotnet/2003/08/18/soa_ex
plained.html, 2003.
He, H., H. Haas, and D. Orchard, Web Services
Architecture
Usage
Scenarios,
Available
at
http://www.w3.org/TR/ws-arch-scenarios/, W3C Working
Group, 2004.
Kardasis, P. and P. Loucopoulos, "Expressing and
organising business rules", Information and Software
Technology, vol. 46, 2004, p. 701-718.
Kim, J. and Y. Gil, "Towards Interactive Composition of
Semantic Web Services", in Proceedings of First
International Semantic Web Services Symposium (AAAI
Spring Symposium Series), Palo Alto, CA, 2004.
Kreger, H., Web Services Conceptual Architecture (WSCA
1.0), IBM Software Group, 2001.
Leymann, F., D. Roller, and M.-T. Schmidt, "Web
services and business process management", IBM Systems
Journal, vol. 41, 2002, p. 198.
Malone, T., et al., "Tools for inventing organizations:
Toward a handbook of organizational processes",
Management Science, vol. 45, 1999, p. 425-443.
Mandell, D. and S. Mcllraith, "Adapting BPEL4WS for
the Semantic Web: The Bottom-Up Approach to Web
Service Interoperation", in Proceedings of the Second
International Semantic Web Conference (ISWC2003),
Sanibel Island, Florida, 2003.
Martin, D., et al., OWL-S 1.0 Release. 2003.
McIlraith, S., T. Son, and H. Zeng, "Semantic Web
services", IEEE Intelligent Systems (see also IEEE Expert
Systems), vol. 16, 2001, p. 46-53.
Medjahed, B., A. Bouguettaya, and A.K. Elmagarmid,
"Composing web services on the semantic web", The
VLDB Journal, vol. 12, 2003, p. 333-351.
Milanovic, N. and M. Malek, Ensuring Predictability and
Correctness of Web Services Composition (Draft version),
Available
at
http://www.informatik.huberlin.de/~milanovi/predictability-correctness.pdf. 2004. p.
1-8.
Orriens, B., J. Yang, and M.P. Papazoglou, "A Framework
For Business Rule Driven Web Service Composition", in
Proceedings of 4th VLDB Workshop on Technologies for
E-Services (TES'03), Humboldt-University zu Berlin,
Germany, 2003.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
9
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
[26] Peterson, D.M., "Power to the BPEL: A technology for
Web services", Business Communications Review, vol. 33,
2003, p. 54.
[27] Pohl, K., Process-Centered Requirements Engineering,
John Wiley & Sons, Inc., 1996.
[28] Pohl, K., et al., "PRIME - Toward Process-integrated
Modeling Environments", ACM Transactions on Software
Engineering and Methodology, vol. 8, 1999, p. 343-410.
[29] Ponnekanti, S.R. and A. Fox, "SWORD: A Developer
Toolkit for Web Service Composition", in Proceedings of
The Eleventh World Wide Web Conference, Honolulu,
Hawaii, 2002.
[30] Ramesh, B. and M. Jarke, "Toward reference models for
requirements traceability", IEEE Transactions on Software
Engineering, vol. 27, 2001, p. 58-93.
[31] Sabou, M., D. Richards, and S.v. Spluter, "An experience
report on using DAML-S", in Proceedings of The Twelfth
International World Wide Web Conference workshop on
E-Services and the Semantic Web (ESSW '03), Budapest,
Hungary, 2003.
[32] Tolksdorf, R., "A dependency Markup Language for Web
Services", in Proceedings of Net.ObjectDays 2002
Conference, Erfurt, Germany, 2002.
[33] Yu, E. and J. Mylopoulos, "Understanding Why in
Software Process Modelling, Analysis, and Design", in
Proceedings of 16th International Conference on Software
Engineering, Sorrento, Italy, 1994.
[34] Yusuf, Y., A. Gunasekaran, and M. Abthorpe, "Enterprise
information systems project implementation: A case study
of ERP in Rolls-Royce", International Journal of
Production Economics, vol. 87, 2004, p. 251-266.
[35] Zapthink, The Pros and Cons of Web Services, 2002.
[36] Zapthink, Service-Oriented Architecture: Why and How?
2003.
[37] Zeng, L., B. Benatallah, and M. Dumas, "Quality Driven
Web Services Composition", in Proceedings of the 12th
International Conference on the World Wide Web (WWW),
Budapest, Hungary, 2003.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
10