Figure 1. Workflow Identification
A major challenge of Dynamic reconfiguration technique is to maintain Quality of Service, which is meant to reduce application disruption during the system transformation. Dynamic reconfiguration [4] technique involves the ability to change the system's functionality or topology while the system is running. This technique involves safe dynamic reconfiguration such as insertion, removal and replacement of components. Dynamic reconfiguration technique looks very much like traditional control system model of 'sense-plan-act'. Wei li [1] discussed the problem for componentbased software systems. In [1] the authors have defined the spectrum of QoS characteristics, the requirements for QoS characteristics are analyzed and solutions proposed to achieve them. They further classified the prior work based on QoS characteristics and then realized by abstract reconfiguration strategies. First-in-first-out order is important to some applications like Railway Reservation Systems which is not discussed in [1]. The Proposed work concentrates on ensuring the order of requests during reconfiguration. The concept can be proved by simulating it on the online applications to detect the QoS violations. The most important conclusion from our investigation is that the classified QoS Characteristics can be fully achieved under some acceptable constraints.
The reconfiguration of software systems is important in order to fix bugs, improve performance, and extend functionality [7], [8], [11]. Static Reconfiguration Approach requires shutting down, recompiling, and rebooting the system in the middle of the process. Vandewoude et al. [10] 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 proposed as an alternative to static reconfiguration. Dynamic reconfiguration is a synonym of runtime evolution [3], the ability to change a system's functionality and/or topology while it is running.
Application consistency and Service continuity while the system is being updated are the benefits of dynamic reconfiguration. Adaptiveness and High availability are the motivation for dynamic reconfiguration. The two aspects are both Quality of Service driven. An adaptive system is capable of runtime reconfiguration and works in unanticipated environments. In order to achieve high reliability and availability, the distributed component [6] software has to support dynamic reconfiguration in order to avoid downtimes caused by rebooting the system. The objective is to freeze only the part of the application concerned by the modification so that the overall penalty on the running application is minimized. Ubiquitous and Mobile systems also require dynamic reconfiguration in the form of system updates while the system is active. This dynamic reconfiguration output was to enable safely changing of the system at runtime. The affected part is suspended for reconfiguration [2] and the unaffected components are operational. A core concept relating to node which is the software components is that of quiescence. Where a node is not involved in a transaction it will neither receive nor initiate any new transactions. The typical distributed adaptation scenarios are outlined by Truyen et al. [12], based on a case study of multiple protocol instant messaging systems. In such systems, message fragmentation services, distributed caching services, and reliability requirements are subject to dynamic adaption. In order to maintain system responsiveness, services should only be removed or deployed under certain conditions, and thus dynamic adaptation is needed. In Dowling and Cahill [3], a selfadaptive application (a 3-in-1 phone) is presented. For mobility, the phone can function as a cellular phone in a cellular network, cordless phone within a Bluetooth network, and a walkie-talkie within range of another Bluetooth phone. Dynamic adaptation is needed in this application to reconfigure its (software) components to function as different phones to deliver appropriate quality of service, depending on the bit rate of the network connection.
This paper argues that the true benefit from dynamic reconfiguration is to minimize application disruption. It is the QoS assurance feature of dynamic reconfiguration that essentially differentiates it from any other static techniques. Otherwise, the poor QoS of a dynamically reconfiguring system has no significant advantage over the unavailability of a statically reconfiguring system.
Kramer and Magee [7] proved that quiescence is a sufficient condition to preserve application consistency for updating a running system. Quiescence is a status in which a node (software component) is both passive and has no outstanding transactions. A quiescent node [5] is therefore both frozen and consistent for a safe update. To provide application consistency for dynamic reconfiguration quiescence has become the de facto standard.
Ajmani et. al [2] proposed modular upgrades of distributed systems to fulfill the requirements: coexistence of different versions of components and communication using incompatible protocols, legacy behavior retirement, state transfer, automated update deployment, controlled deployment of updates at appropriate times, and limiting of service disruption. To preserve application consistency, the approach needs to shut down a node before changing its codes. The main concern of Warren et. al [10] is application consistency, defined as conformance to a set of architectural constraints. They presented a method for automated verification of whether constraints can hold under reconfiguration.
Zhang et al. [13] modeled global consistency as component dependency, and the safety of adaptation was defined as the absence of violation of dependency and interruption on atomic communication. To demonstrate dependency between components, the encoding and decoding chain was used as a case study. This approach requires that part of the system be blocked in order to ensure that the last packet processed by the encoder can be decoded by the corresponding decoder. Then, it is safe to swap the system to use the new encoding and decoding chain. The most recent articles on dynamic reconfiguration include Guay et. al [14], Leger et. al [15], Surajbali et. al [16 ], and Wurthinger et. al [17]. The common feature of these approaches is still to apply quiescence to preserve reconfiguration consistency, while individual approaches use different reconfiguration operations for achieving a quiescent status.
A recent important work to address availability is by Vandewoude et. al [10], in which the concept tranquility is proposed. Tranquillity is an improvement over quiescence because it significantly reduces disruption on the running program. Tranquillity makes use of a minimal passivated set of nodes to minimize the affected area of disruption by quiescence. Tranquillity is still a sufficient condition for application consistency. Tranquillity can occur naturally, but once it holds for a node, all interactions between the node and its environment must be blocked in order to keep the node in a tranquil status for the duration of update. Tranquillity is not proven to be reachable in bounded time. As a result, a dynamic reconfiguration system based on tranquillity must also use quiescence as a backup.
Wei Li [1] proposed RCM model that provide QoS Assurance for Dynamic Reconfiguration of Component Based Systems. The Coexistence property [9] has been identified as a necessary condition for QoS Assurance because it logically removes blocking operations.DVM has been attempted as an effective mechanism to preserve application consistency and availability in the face of coexistence of the old and new subsystem.RCM has no control over the order of request processing but in some situations there is a necessity to follow the order. The Proposed System adapt the RCM for the FIFO order application and amend changes to detect the FIFO Violations.
The Proposed Work concentrates on implementing the new strategy for dynamic reconfiguration to ensure the request received into the system is strictly processed in FIFO order. The proposed mechanism is based on identifying work flow in the system, request reprocessing and scheduling of components for dynamic reconfiguration to ensure FIFO ordering on the processing of requests. We develop the proof of concept of our strategy on a railway reservation application and prove that our mechanism is able to ensure FIFO ordering of requests.
The Blocking operation is the method proposed to keep the system online during reconfiguration and ensures the requests received into the system are strictly processed in FIFO order.
Our methodology consists of 3 steps.
In the following section, each step is explained in more detail.
Workflow is the processing steps on the requests in terms of component involved in a serial order.
For the case study Railway reservation application, the components are given below.
The workflow of the system for the request to book the ticket is shown in Figure 1.
Figure 1. Workflow Identification
Check Availability, Block Availability, Payment Collection, Ticket generation. A request flows through all these components to complete its operation. Any of this component patches comes at any time and dynamic reconfiguration has to be applied.
For each request, information has to be maintained at each stage the request is currently in. Once the request cross the stage, the reconfiguration can be applied on any component before it, but no reconfiguration must be applied on components which are further in the chain as in Figure 2.
Figure 2. Scheduling of Reconfiguration of Components
Say a request is accepted for processing at time T1 and the component reconfiguration is done at time T2 , with T2 > T1 , then request should have processed through all the components available before the time of T2. If the reconfiguration is applied, the request must be revoked and re-processed after T2.
Our scheduling of component reconfiguration is based on reducing the number of reprocessing of requests.
We keep the workflow queue and the request at each stage is complemented in its corresponding queue.
From the last queue following operation is done.
If the queue has the maximum element than any other queue, no reconfiguration after this stage must be done, but reconfiguration before it can be done is based on the previous queue operation result. This operation is done recursively to find the components to be reconfigured.
If at any stage, it is decided that components after that stage has to be applied reconfiguration, then all the request at this stage has to be started from beginning. The transaction must be revoked and processing of request must start from the beginning.
The proposed solution is implemented in JAVA. The response time of the system is tested out by applying reconfiguration at a fixed interval of time. The response time is measured in terms of the latency in processing of requests and we found that latency meets the QoS condition defined. In some applications there is a necessity to process the requests in order i.e. in FIFO manner which has been achieved even though the response time is more to reconfigure the components.
The number of FIFO violations is compared under Dynamic Reconfiguration and FIFO policies are shown in Figure 3. In Dynamic Reconfiguration the components can be reconfigured at any time which does not process the requests in order, so the number of FIFO violations is more in this policy. In FIFO based policy the components can be reconfigured and process the requests in order.
Figure 3. The FIFO Violations is compared under Dynamic Reconfiguration and FIFO Policy
The time to reconfigure the components in processing of the requests is compared under Dynamic Reconfiguration and FIFO policy which is shown in Figure 4. Some applications like Railway Reservation System need to process the requests in order which is achieved even though the response time is more in FIFO Policy.
Figure 4. The Average Time to reconfigure the components is compared under Dynamic Reconfiguration and FIFO Policy
We have proposed and evaluated our reconfiguration scheme and proved that its response time meets the QOS criteria. Adaptive scheduling should be investigated for the case when system resource usage varies between saturation and non saturation which constitute future work.
To make the proposed QoS assurance framework more applicable to distributed environments, component state migration will be the biggest challenge. The applicability of state-sharing policy is worth for further investigation, and also relaxation of the constraints on state sharing is an issue for further research.