DSCWeaver: Synchronization-Constraint Aspect Extension to Procedural
Process Specification Languages

Qinyi Wu
1
, Calton Pu
1
, Akhil Sahai
2
,

Roger Barga
3
, Gueyoung Jung
1

Jason Parekh
1
, Galen Swint
1
1
College of Computing, Gatech
{qxw, calton, galen.swint, jason.parekh,
gueyoung.jung }@cc.gatech.edu
2
HP Labs
akhil.sahai@hp.com

3
Microsoft Research
barga@microsoft.com

Abstract

BPEL is emerging as an open-standards language for
Web service composition. However, its procedural style
can lead to inflexible and tangled code for managing a
crosscutting aspect — synchronization constraints that
define permissible sequences of execution for activities in
a process. In this paper, we present DSCWeaver, a tool
that enables a synchronization-aspect extension to BPEL.
It uses DSCL, a synchronization expression language, to
specify constraints. DSCL has the desirable features of
declarative syntax, fine granularity, and validation
support. A designer can use DSCL to describe and
validate the synchronization behavior and rely on
DSCWeaver to generate BPEL code. We demonstrate the
advantages of our approach in a service deployment
process and evaluate its performance using two metrics:
Lines of Code (LoC) and Places to Visit (PtV). Evaluation
results show that our approach can effectively reduce
development effort of process designers while providing
performance competitive to un-woven BPEL code.
1. Introduction
The recent trend in web service composition
languages is to specify the structure of a process using
control constructs, such as And-split and And-join [25].
However, their procedural style may lead to inflexible and
tangled code in process specification for two reasons.
First, the procedural style is not effective in capturing
complex synchronization behavior. For example, in BPEL
the <link> construct results in scattered code among
activities nested in different concurrent subprocesses [22].
Second, the procedural style results in centralized
synchronization control. It has been shown that
centralized control may degrade process performance and
increase network load of the orchestration server [6]. In
sharp contrast, decentralized control has the advantage of
balancing workload among peers.
In this paper, we address these problems by applying
Aspect-Oriented Programming (AOP) techniques to the
problem of synchronization constraints on process models.
The advantages for modeling a process from multiple
aspects have been identified by Schmidt and Assmann as
simplified modeling complexity and increased robustness
of the process during adaptation [20]. The utility of AOP
on domain specific languages is also discussed in [9][17].
Our evaluation results further confirm their observations.
We introduce DSCWeaver, a tool that offers a
synchronization-aspect extension to BPEL, a popular Web
service composition language. BPEL may become
verbose and complex when modeling nontrivial processes
[2][8]. One contributing factor in our observation is
synchronization code that crosscuts the procedural
modeling code.
DSCWeaver has two unique features. First,
synchronization constraints for a process are specified in
the DAG Synchronization Constraint Language (DSCL)
[21]. This detangles synchronization code from the base
code of a process and provides flexible and expressive
primitives to describe synchronization relationships.
DSCL draws on synchronization research from parallel
programming [5][19]. As its name indicates, DSCL can be
used to specify a Directed Acyclic Graph (DAG) flow
model. It has a declarative syntax, fine granularity, and
validation support. DSCL defines three synchronization
relations (HappenBefore, HappenTogether, and Exclusive)
that operate on activity states (start, run, and finish). By
specifying relationships over activity states, DSCL can
describe a rich set of synchronization behaviors.
The second unique feature is that synchronization
constraints written in DSCL are automatically translated
into a set of messages tokens carrying the synchronization
data. Activities synchronize with each other by
exchanging these tokens asynchronously. The translation
relies on an intermediate Petri net representation [13].
DSCWeaver uses a Petri net for two reasons. One is to
simulate and validate the synchronization constraints. The
other reason is to map the transition firing logic of the
Petri net into a set of token messages. The advantage of
this approach is that the syntax of token messages is
language-independent and can be woven into any service
composition language that supports a messaging

mechanism. What is more, messages can be easily
exchanged among distributed processes, which facilitate
conversion from centralized control to decentralized
control for processes orchestration.
The rest of the paper is organized as follows. In
Section 2, we present an example to illustrate the
synchronization constraints in a nontrivial service
deployment process. In Section 3, we present an overview
of the DSCWeaver implementation and explain its major
modules. We then give a brief introduction to DSCL,
followed by a description of the translation from
synchronization constraints to token messages. In Section
4, we explain how to apply DSCWeaver to BPEL. In
Section 5, we revisit the example in Section 2 and show
our evaluation results. Related work and conclusion are
presented last.
2. A Motivating Example
Consider a service deployment process for the
PetStore e-commerce application. It is an online store
where customers can browse and purchase their favorite
pets. The PetStore application consists of a database tier
and an application server tier. To meet performance goals,
the database server and the application server are installed
on different hosts. The deployment consists of a set of
installation activities, each represented by a, each of
which interacts with its target host to perform part of the
installation task. The deployment process consists of three
subprocesses:
1) Middleware installation: It includes installing the
database (MySQL), runtime environment (Java, Ant)
and application server (Tomcat) denoted a
sql
, a
java
, a
ant
,
and a
tomcat
respectively.
2) Application installation. It includes installing the
application (PetStore) and its dependent libraries (Jdbc,
Struts, Dao, and SQLMap), propagating database with
PetStore workload data (configure MySql) and
configuring PetStore with database server information
(configure PetStore) denoted a
petstore
, a
jdbc
, a
struts
, a
dao
,
a
sqlmap
, a
c_sql
, and a
c_petstore
respectively.
3) Application ignition. It includes starting the database
and the application server denoted a
s_sql
and a
s_tomcat
.
The deployment process is orchestrated by a BPEL
engine on the deployment host. The target hosts for the
database and the application server are preconfigured with
a web service, InstallWS, which accepts installation
instructions from activities and performs the
corresponding tasks. Figure 1a depicts the centralized
control scenario. In this architecture, all synchronization
logic is managed by the deployment machine (Host A),
which interacts with target machines (Host B and Host C)
by sending them installation instructions in order. The
disadvantage of this approach is that Host A may become
overloaded by the synchronization traffic. However, it
Host A
BPEL
WS
Host B
WS
Host C
Installation
instruction
Installation
instruction
Host A
BPEL
WS
Host B
Host C
Synchronization
message
BPEL
Installation
instruction
WSBPEL
Installation
instruction
Synchronization
message
(a) centralized synchronization control
(b) decentralized synchronization control
Web service
BPEL engine
Synchronous message
Process specification

Figure 1. PetStore deployment architecture

turns out that we can reduce a portion of workload from
Host A by distributing deployment activities according to
their target hosts. This modification leads to the
decentralized deployment architecture in Figure 1b. In the
decentralized approach, the process is split into two
subprocesses, each of which is deployed on a target host
and interacts with that host to fulfill the installation task.
This means that all activities related to database
installation form a subprocess to be deployed at Host B,
while all activities related to application server installation
form another subprocess to be deployed at Host C. These
two subprocesses interact only with Host A to synchronize
with each other. In Section 5, we provide run-time
performance measurements for both architectures.
Synchronization constraints are created either by
installation dependencies or by user requirements. For
instance, an installation dependency arises when the
installation of one software package should be placed at
certain location within the directory structure of another
software package. An example is that PetStore code
should be placed in the directory $Tomcat/webapp.
User requirements come from design strategy or other
concerns. For example, a process designer may require
that the installation subprocess should finish before the
ignition subprocess starts.
Instead of describing the constraints procedurally, we
use two relations for declaring constraints as relationship
statements: HappenBefore(→) and HappenTogether(↔).
Unlike other synchronization expression languages
[5][19], these relations operate on activity state. An
activity progresses through three states: start(S), run(R)
and finish(F). The activities interact with each other as
they transit from one state to the next subject to the
relationship statements. We detail the relation and activity