context of open environments like Internet. Many changes of
requirements and environments are not predicted before the
systems being deployed. In this context, an Internet-based system
developed on the assumptions might behave normally at one time,
but can fail in another.
Runtime variability is supposed to be evolvable at runtime to
handle the changes of requirements or environments, regardless
of their predictability. This means that the variability elements
(i.e., variation points and their associated variants) can be
changed even at runtime in terms of their number, attributes and
relation (i.e., constraint dependency [15]).
Hence, the issue motivates us to find a way to realise evolvable
runtime variability of an Internet-based service system during its
execution in a limited manner. By limited, we mean that the
changes of requirements and environments that can be handled
are limited (not all of them), the type and number of variability
elements to be changed on requirements is constrained in a range
and the ways in evolving runtime variability is enumerable. This
point is embodied in the following text.
There are two basic points to be concerned in the context, i.e.,
how to construct systems with the evolvable runtime variability
and how to evolve it. On the one hand, if runtime variability is
needed to be evolved, the software architecture is supposed to
support the dynamic software update [5] of the system (e.g.,
(re)configuring system [9] or online code modification, the reason
for this is discussed later) with regards to different concerns of
stakeholders which partially result in the evolution of
requirements and environments. We need to know what such
architecture is and how to design the system with it. On the other
hand, there are naturally some mechanisms on how to carry out
dynamic update to further evolve runtime variability.
Consequently, we propose a reference architecture along with the
related mechanisms for Internet-based service systems in the
paper.
The rest of the paper is organized as follows. In Section 2,
evolvable runtime variability is further discussed in terms of
space and time, and an example case is described to show the
need for evolvable runtime variability with a scenario. In Section
3 and 4, the model view of the reference architecture and the
corresponding mechanisms is specified. The issues on evolvable
runtime variability are solved using our approaches in Section 5.
In Section 6 and 7, we compare the related works with ours,
conclude this paper and discuss the future work.
2. ISSUES ON EVOLVABLE RUNTIME
VARIABILITY
In this section, the evolvable software variability in a general
software system is further characterised and discussed from
special and temporal perspectives. Based on this, evolvable
runtime variability to be solved in this paper is defined. Then an
example case of Personal Data Resource Network is specified to
embody the need for evolvable runtime variability.
2.1 Evolvable Runtime Variability
Software variability of a system is the extent to which the system
is capable of being changed. As described in [15], it can be
discussed from special and temporal perspectives. Software
variability in space means the existence of different
configurations of a system
2
at the same time. At this rate, there
are three levels for realisation of software variability [3], i.e.,
architecture level, component level, code level. This means that
variation can occur in a code piece, an individual module or even
the entire system. Software variability in time refers to the
different models of a single system in its life cycle or different
versions in its evolution. In this context, software variability
exists in requirement specification, modules from architectural
design and detailed design, running instances, test cases and so
on [15].
We argue that software variability can be evolvable at any
location of the system or any point of its life cycle and the
evolution can occur in terms of number, attributes and/or relation.
From an implemental perspective, number of variability elements
can be changed by increasing and decreasing it, i.e., by adding
some new variability elements into the system or removing some
existing ones from it. Changing an attribute of a variability
element can be realised through replacing the element with the
old and undesired attribute with a new one with the new and
desirable attribute. The last but not the least, the relation (e.g.,
exclusion between two variants) is also viewed as the special
attribute of two variability elements, and we can changing it by
replacing one of the two, or both of them.
Based on the above discussion, what we concern is the software
variability that occurs and can be improved or impaired at
runtime. In the context, the number, attribute and relation of
variability elements can be changed at code level, component
level and architectural level by adding, removing or replacing
them. We view such runtime variability as evolvable one.
As to runtime, there are some more points worth discussing. On
the one hand, runtime may be the most desirable time for the
software elements to be added, removed or replaced, as long as
services of the system are not interrupted while evolving. Besides,
we can immediately observe the effect of the changes made on
software variability to achieve better performance, higher
flexibility or other goals. On the other hand, changing runtime
variability during system execution is the much more difficult
than that at any other time (i.e., typically design time). It needs
support from well-designed software architecture and
mechanisms, which are given in this paper as a possible solution
to the issue how to construct an Internet-based service system
with evolvable runtime variability.
2.2 An Example Case of Evolvable Runtime
Variability
Personal Data Resource Network (PDRN) is a service system
established upon a personal cloud
3
, which is devoted to give a
unitized view on a person’s (or a family’s) data resource and
provide related services to he/she or them (e.g. storage,
2
In the area of software product line (SPL), variability in space
means the existence of difference among a product family
belonging to a SPL. Such variability is called product line
variability, which is different from software variability.
3
http://personal-clouds.org/wiki/Main_Page