09-02-2013, 03:05 PM
QoS Assurance for Dynamic Reconfiguration of Component-Based Software Systems
QoS Assurance for Dynamic.pdf (Size: 1.91 MB / Downloads: 25)
INTRODUCTION
PREVIOUS authors have highlighted the importance of
reconfiguration of software systems to fix bugs, improve
performance, and extend functionality [20], [34], [36]. Static
approaches require shutting down, recompiling, and rebooting
the system. Vandewoude et al. [34] have identified three
significant disadvantages with static approaches with
respect to Quality of Service (QoS): 1) Shutting down could
cause the system to lose accumulated state during the
ongoing execution of the system; 2) unavailability is
unacceptable for long-lived or mission-critical systems;
and 3) unavailability promotes poor self-adaptation.
Dynamic approaches are hence proposed as an alternative
to static reconfiguration. In this paper, Dynamic
reconfiguration is a synonym of runtime evolution [10], the
ability to change a system’s functionality and/or topology
while it is running. Dynamic reconfiguration typically
involves changes at runtime via addition, deletion, and
replacement of components, and/or alteration of the
topology of a component system. The benefit is application
consistency and service continuity for the system while it is
being updated. The motivation for dynamic reconfiguration
comes from two aspects: adaptativeness and high availability,
which are both QoS driven. An adaptive system works in
unanticipated environments and frequently adapts its
behavior in response to a changing environment.
PREAMBLE: AN ABSTRACT COMPONENT MODEL
AND RECONFIGURATION
To provide a discussion context for dynamic reconfiguration,
we first describe the assumptions about components,
connectors, and services, and the terms used for reconfiguration.
Consequently, we can introduce the dependent
concepts in terms of QoS characteristics in later sections.
Component Systems and Reconfiguration
A component is a processing entity that encapsulates a set
of functionality and data. Furthermore, a component has a
provided-interface to specify a set of services that it provides
for use by other components. Similarly, a component has a
required-interface to specify a set of services that it needs. A
service is a set of functionality, along with the policies that
dictate its usage. A connector is a directed connection from
a required-service of a component to a provided-service of
another component, indicating the client/server relationship
between the components. For an individual component,
the client of its services can be an internal
component of the same system or an external software
agent, as long as they follow the service specification to
make a request.
An Example Component System
To abstract the problems in dynamic reconfiguration and
present the corresponding terms, the example in Fig. 2 is
extended into a more complex component system as the
explanatory context. The system is named Data Encryption
and Digital Signature System (DEDSS), which is a secured
data transmission system with one sender and multiple
receivers. The security is ensured by symmetric and asymmetric
key encryption and digital signature. Fig. 4 illustrates
DEDSS with the sender and only one receiver.
The application scenario is: The sender generates a
session key and uses it to encrypt (Encryption) a data-item;
the session key is then encrypted by the receiver’s public key.
The same data item is digitally signed (Signing): producing
(Message Digest) the message digest of the data-item and
then encrypting (Digest Encryption) the message digest with
the sender’s private key. The sender then delivers (Delivery)
the ciphertext, encrypted session key, and signature in a
data-package.
Availability
Definitions
Definition 2. A reconfiguration preserves availability if the
system under reconfiguration keeps its servicing online when
accommodating the changes.
The blocking operation [20] is the original technique
proposed to keep the system online during updating.
Blocking maintains a FIFO queue of incoming requests for
the affected part of the system. Theoretically, the queue
length is infinite so that queued requests are not dropped.
Consequently, the system’s consistency can be preserved,
and at the same time the unaffected part of the system can
still function.
In DEDSS, if Encryption and Decryption are updated, an
encryption request can be blocked until the update of
Encryption is completed. Similarly, a data item that is
encrypted by the new algorithm is delayed for decryption
before all the data items that are encrypted by the old
algorithm are decrypted by the old Decryption, and the new
Decryption can be put in use.