Isolating Process-Level Concerns using Padus
Mathieu Braem
1
, Kris Verlaenen
2
, Niels Joncheere
1
, Wim Vanderp e rren
1
,
Ragnhild Van Der Straeten
1
, Eddy Truyen
2
, Wouter Joosen
2
, and Viviane
Jonckers
1
1
System and Software Engineering Lab (SSEL), Vrije Universiteit Brussel
Pleinlaan 2, 1050 Brussels, Belgium
{mbraem,njonchee,wvdperre,rvdstrae,vejoncke}@vub.ac.be
2
DistriNet, Katholieke Universiteit Leuven
Celestijnenlaan 200A, 3001 Leuven, Belgium
{kris.verlaenen,eddy.truyen,wouter.joosen}@cs.kuleuven.be
Abstract. Current workflow languages for web services suffer from poor
support for separation of concerns. Aspect-oriented software develop-
ment is a well-known approach to improve this. In this paper, we present
an aspect-oriented extension for the WS-BPEL language that improves
on current state-of-the-art by introducing an explicit deployment con-
struct, a richer joinpoint model, and a higher-level pointcut language.
In addition, the supporting technology is compatible with existing WS-
BPEL engines.
Classification. Business process modeling and analysis, processes and
service composition
1 Introduction
Over the last years, web services [1] have been gaining a lot of popularity as
a means of integrating existing software in new environments. By composing
a number of basic web services, new web services can be created that provide
more advanced functionality. These compound web services can then be reused
in even other web services, which further facilitates software reuse.
Originally, the only way to compose web services was by manually writing
the necessary glue-code in programming languages such as C and Java. It quickly
became clear, however, that a composition of web services is more naturally cap-
tured by dedicated workflow languages [2] than by general-purpose programming
languages.
To day, the most popular workflow language with regard to the composition
of web services is the Business Process Execution Language (WS-BPEL) [3]. WS-
BPEL builds on the foundations of WSFL [4] and XLANG [5], and can be used
to specify both e xecutable business processes and abstract business processes.
Executable processes model the behavior of one participant in a composition (i.e.
orchestration), while abstract business pro ce ss es specify the externally visible
behavior of a composition (i.e. choreography). WS-BPEL processes are platform-
and transport-independent, and are expressed using XML.
1.1 Separation of Concerns
In this paper we improve the modularization capability of WS-BPEL in order
to provide a better separation of concerns [6] in the workflow specification. In
WS-BPEL (and other workflow languages, for that matter) a large number of
concerns (such as authorization and billing) cannot be cleanly separated from
the main functionality of the workflow specification. WS-BPEL proce ss es suffer
from a problem that is named the “tyranny of the dominant decomposition” [7].
A WS-BPEL proce ss can only be decomposed according to the control flow
of the process, and concerns that do not align with this decomposition end
up scattered across the process specification and tangled with one another. For
example, billing requires invoking some billing service each time before and after
a certain functionality in the process is provided. This makes it difficult to add,
modify, or remove such concerns. Also, because WS-BPEL processes must be
specified in a single XML file, complex processes give rise to large XML files
which can become difficult to understand, maintain and evolve.
To solve the above problem, we propose to apply aspect-oriented decomposi-
tion and composition mechanisms to WS-BPEL. Aspect-oriented software devel-
opment (AOSD) [8] has been gaining a lot of popularity as a means of improving
separation of crosscutting concerns in software. Examples of such crosscutting
concerns are security concerns such as access control and confidentiality [9], de-
bugging concerns such as logging [10] and timing contract validation [11], and
business rules such as billing [12]. The goal of AOSD is to achieve a better sepa-
ration of concerns, by allowing crosscutting concerns to be specified in separate
modules called aspects, so that adding, modifying or removing these concerns
does not require changes to the rest of the system.
Traditional aspects consist of two main parts: pointcut definitions and ad-
vices. Points in the program execution where an aspect can be applied (e.g.
method invocations in object-oriented programming) are called joinpoints. Point-
cuts select sets of joinpoints where aspects should be applied; these pointcuts can
be expressed using declarative pointcut languages. An advice specifies the con-
crete behavior that should be executed at certain joinpoints — typically before,
after or around the original b e havior of the joinpoints. Inserting the behavior
defined by aspects at the correct locations in the main program is called weaving.
Initial research on AOSD has concentrated on applying its principles to the
object-oriented programming paradigm. However, as motivated by Arsanjani et
al. [13] and others [14–16], AOSD has a lot of potential in a web services context,
too.
1.2 Web Service Composition in Telecom
The research described in this pap er is part of a larger research project, which
is named WIT-CASE and is performed in collaboration with Alcatel, and which
addresses composition of web services on a telecom service delivery platform. We
will therefore illustrate the motivation for our approach by providing examples
from within this context. Typical use case s for a telecom service delivery platform
include setting up and executing a multi-party conference call. Such use cases
mostly have the same general characteristics. For example, the platform needs
to check whether the user is allowed to access the functionality he has requested
before providing this functionality (authorization), and the user needs to be
billed for his usage according to some billing scheme (billing).
Both the authorization and billing concerns are typically crosscutting. There-
fore, an aspect-oriented approach can improve the modularization of web service
compositions on a telecom service delivery platform. Without support for AOSD,
nearly every WS-BPEL process on our platform would start with some autho-
rization code before executing its main functionality, and would perform some
billing functionality before and/or after certain resources are used. This means
that, when some part of the authorization or billing policies changes, all these
processes need to be modified. The presence of more than one authorization or
billing policy would even further complicate this situation.
If, on the other hand, support for AOSD is available, crosscutting concerns
such as authorization and billing can be expressed separate from the processes’
main functionality in dedicated aspects. If authorization or billing policies would
change, this would only require changes to the corresponding aspects, and not
to the main processes. If one would like to support more than one authorization
or billing policy (e.g. fixed fee billing as well as duration billing), it is sufficient
to simply implement an additional aspect.
In this paper, we propose an aspect-oriented programming extension for WS-
BPEL, named Padus, in order to provide a better separation of concerns. The
characteristics of the telecom service delivery platform and the goals of the WIT-
CASE project have had a profound impact on the design and implementation of
Padus. First of all, the overall workflow specification language should be suffi-
ciently expressive and should support creation of higher-level composition prim-
itives. Moreover, adding AOP support to WS-BPEL should be as less disruptive
as possible to the existing tool chain and should introduce as less run-time per-
formance overhead as p oss ible. For these reasons we have chosen to follow an
approach in which the design of Padus is based on a logic-based programming
language (in order to increase expressive power and ability to construct higher-
level com position primitives) and the implementation of Padus is based on a
static transformation approach (in order to be compatible with existing to ol
chain and minimize run-time performance overhead).
The paper is structured as follows. Section 2 describes our AOP language for
WS-BPEL, while section 3 describ es how this language is implemented. A brief
case study is provided in section 4. We present related work in section 5 and
state our conclusions in section 6.
2 The Padus Language
We present Padus, an aspect-oriented extension to WS-BPEL, which aims to
overcome its lack of support for modularization of crosscutting concerns. It al-
lows introducing crosscutting behavior to an existing WS-BPEL proce ss in a
modularized way. Developers can augment WS-BPEL processes with additional
behavior at specific points during their execution. These points can be selected
using a logic pointcut language, and the Padus weaver can be used to combine
the behavior of the core process with the behavior specified in the aspects. Us-
ing Padus, the complexity of the core process can be controlled by specifying
crosscutting concerns like sec urity and billing in separate aspects.
In this section, we describe the design of the Padus language. We follow the
template for describing AOP languages proposed in AOSD-Europe’s survey on
aspect-oriented programming languages [17]. We describe the language along
five dimensions: the joinpoint model (section 2.1), the pointcut and advice lan-
guages (sections 2.2 and 2.3), the aspect modules (section 2.4), and the aspect
deployment language (section 2.5).
2.1 Joinpoint Model
Joinp oints are well-defined points during the execution of a WS-BPEL process
where extra functionality could be inserted. They are related to the activities
that are provided in WS-BPEL. Table 1 lists the kinds of joinpoints that are
available. Each type is related to a specific WS-BPEL activity, which can be
easily deduced from the type’s name. The joinpoint mo del does not only allow
behavioral joinpoints but also includes structural joinpoints related to structural
WS-BPEL activities (which contain one or more activities themselves).
Behavioral joinpoints Structural joinpoints
invoking replying sequencing switching
receiving assigning lo oping (“while”) picking
throwing terminating flowing scoping
comp ensating doingNothing (“empty”)
Table 1. Types of joinpoints available in Padus
Joinp oints are associated with properties relevant to that particular join-
point. Some of these properties are related to the attributes and elements of the
corresponding WS-BPEL activity. For example, table 2 provides the attributes
of “invoking” joinpoints. Additional prope rties specify, among others, in which
WS-BPEL process or s tructural ac tivity a joinpoint o c curs. Dynamic proper-
ties, like in which process instance a joinpoint occurs and the value of certain
variables, are defined too. Using these properties, one can more precisely select
interesting joinpoints.
2.2 Pointcut Language
A pointcut selects a specific set of joinpoints. Pointcuts can be used to specify the
joinp oints where additional behavior should be inserted. The pointcut language
of Padus is base d on logic meta-programming [18, 19]. A pointcut can be seen as
Attribute Type Description
name String An optional name for the WS-BPEL activity
partnerLink String The partner link used by the invoke
portType String The port type used by the invoke
operation String The operation of the port type that is invoked
inputVariable String The message that should be sent
outputVariable String The variable that should contain the reply mess age
Table 2. Attributes of “invoking” joinpoints
invoking(Joinpoint, ‘smsService’, ‘smsServicePT’, Operation),
startsWith(Operation, ‘send’).
Listing 1. Simple p ointcut that captures “invoking” joinpoints that invoke an
operation of which the name starts with “send”
a collection of constraints on the type and properties of allowed joinpoints. In
addition, a pointcut is able to expose certain information (e.g. argument values)
so that the advice can exploit this.
The pointcut language defines a predicate for each type of joinpoint. The
attributes of the predicate refer to the attributes of that specific type of joinpoint.
Table 3 shows the exposed bindings of the invoking predicate. Only the version
with the most variables is really required. The others can be written in function of
the larger one. The predicates with less variables simply offer e xtra convenience.
Predicate binding Description
invoking(Joinpoint, Name, PartnerLink, PortType, All allowed attributes
Operation, InputVariable, OutputVariable)
invoking(Joinpoint, Name, PartnerLink, Input and output variable
PortType, Operation) names not bound
invoking(Joinpoint, PartnerLink, PortType, Only Partnerlink, PortType
Operation) and Operation bound
Table 3. Bindings for the “invoking” predicates
By constraining the attributes of a joinpoint predicate, certain joinpoints
can be selected. Pointcuts can combine these predicates with standard predi-
cates that are available in Prolog [20], for comparing basic data types, searching
lists, etc. Pointcuts can include negations, and predicates can be combined with
conjunctions or disjunctions. The small example in listing 1 denotes a pointcut
that covers all “invoking” joinpoints of operations on the smsServicePT port
type of the smsService partner link of w hich the name of the operation starts
with “send”.
The pointcut language also offers predicates for constraining or expos ing ad-
ditional (possibly runtime) properties of joinpoints, like for instance the process
