Article Preview
TopIntroduction
Service-oriented architecture (SOA) is the prevailing software paradigm for dynamically integrating loosely-coupled services into one cohesive business process (BP) using a standard-based software component framework (Bichler & Lin, 2006; Huhns & Singh, 2005). SOA-based systems may integrate both legacy and new services, created by either enterprises internally or external service providers.
However, current SOA solutions have not addressed the strict predictability demands that many enterprise applications require, from banking and finance to industrial automation and manufacturing. Such enterprises, many of whom already embrace SOA for a large part of their systems, would greatly benefit from a comprehensive SOA solution that can also encompass their real-time applications. In other words, as SOA gains prominence in many domains, the confluence of real-time and SOA systems is inevitable. We must prepare SOA for meeting the predictability requirements of real-time enterprise systems.
For example, the auto industry is looking at applying SOA to their development of the AUTOSAR (AUTomotive Open System ARchitecture) standardization project (AUTOSAR, 2008) to address the needs of future automotive systems, called “service integrated systems”. Such systems can facilitate: 1) the integration of various on-board services (e.g., cruise control, brakes, etc.), 2) both vehicle-to-vehicle and vehicle-to-roadside for traffic information, and 3) communication with the dealer about vehicle maintenance. This must be accomplished while also maintaining the real-time requirements of such systems, particularly with on-board service integration.
SOA brings both advantages and challenges to real-time integration. By its very nature, SOA was designed to be flexible to deal with dynamic environments. As such, different service component candidates may have very different timing behaviors. Moreover, the distributed nature of execution environments makes it almost impossible to make any kind of “guarantees.” However, such flexibility and dynamism may be leveraged to allow 1) different choices of candidate services to better meet deadlines during BP composition and 2) dynamic run-time adjustments to reconfigure a BP to make up for lost time when some services have taken much longer than expected. We therefore want to study the real-time support in SOA both to realize its benefits and to meet its challenges.
In this paper, we present the RT-Llama project (as an extension of Llama (Lin, Panahi, Zhang, Zhang, & Chang, 2009; Zhang, Lin, & Hsu, 2007)) which meets the real-time enterprise challenge by enabling SOA users to schedule an entire BP, thus eliminating the risk of missed deadlines due to the over-utilization of resources. RT-Llama differs from previous service-oriented architectures (Panahi et al., 2008) in that it allows end-to-end BP deadline guarantees through advance reservations of local resources.
In order to make this work, we 1) design global resource management and composition components that reserve resources in advance for each service in a BP to help guarantee its end-to-end deadline; 2) leverage an efficient data structure for managing reservation utilization data, a dynamic adaptation of the TBTree (Moses, Gruenwald, & Dadachanji, 2008) called the dTBTree; 3) implement a CPU bandwidth management system for each host, dividing a CPU into multiple temporally-isolated virtual CPUs, allowing different classes of service with various levels of predictability; and 4) develop pre-screening mechanisms to decrease the likelihood of unsuccessful distributed service reservations.
The rest of the paper is organized as follows. We first review the challenges of bringing real-time to SOA and describe the RT-Llama RT-SOA architecture. We then present the performance study of the RT-Llama implementation. Finally, we compare our work on RT-Llama to related efforts.