Complexity Analysis at Design Stages of Service Oriented Architectures as a Measure of Reliability Risks

Introduction

Service Oriented Architecture (SOA), which is prompting a variable shift in the distributed computing history, is subsisted in modern computing environments and is at critical risks due to permanent and transient faults in computing structures (Lakhal, Kobayashi, & Yokota, 2006). Permanent faults such as node stuck-at-1/0, transistor open, shorted transistors, etc., arise during fabrication or result from aging, and destroy the intended function of the circuit (Timor, Mendelson, Birk, & Suri, 2008). Transient faults, in contrast, do not damage the chips physically but are catastrophic for desired functionalities of the system (Mukherjee, Emer, & Reinhardt, 2005), (F. Wang, 2008), (Iyer, Nakka, Kalbarczyk, & Mitra, 2005). Both of these faults are severe for those SOA where reliability is a great concern(Narayanan & Xie, 2006), (Tosun, 2005). For example, online banking transactions where a single bit change (1→0) in the most significant bit of the data storing register, may cause a huge difference in balance. Due to processor scaling, reduction in operation voltages, exponential growth of number of transistors in a single chip, increase in clock frequencies, and/or device shrinking, the rate of these faults are moving upwards day by day (Saggese, Wang, Kalbarczyk, Patel, & Iyer, 2005), (Crouzet, Collet, & Arlat, 2005).

Prior research to cope with transient faults (which in turn create soft errors) mostly focuses on post-design phases, such as circuit level solutions, logic level solutions, spatial redundancy, temporal redundancy, and/or error correction codes. Early detection and correction of such problems during the design phase is much more likely to be successful than detection once the system is operational (Cortellessa et al., 2005). Estimating reliability (or at least identifying failure-prone components) early in the life-cycle of a design is therefore preferable (Jurjens & Wagner, 2005), (A. Bondavalli, 2001). From a pure dependability viewpoint, complex components attract more attention of soft errors tolerant approaches than others do, since reliability of a system is correlated with the complexity of the system (Khoshgoftaar, 1996), (Yacoub & Ammar, 2002). To minimize the risks of system failure, it is a requirement to flag those components of SOA that are likely to have higher faults. Clearly, the degree of protection or prevention of faults mechanism is not same for all components. Hence, an approach is needed at the design stage to highlight those complex components and suggest the designers for possible changes in the design if there remains any risk of affecting desired functionalities.

This chapter flags complex components at early design stage and investigates how to encourage the designer to explore changes that could be made in the existing model. For example, how the complexities of the components could be minimized, or how these components could be replaced with alternatives and/or with less complex components are examined. The objective is to keep the functionality and other constraints of the system unaffected or to make a trade-off between them, with the goal to minimize the reliability risks. Case studies illustrate the effectiveness of the proposed approach in determining components’ complexity ranking and then lowering their complexities. The model is expressed in Unified Modeling Language (UML) since this allows the modeler to describe different views on a system, including the physical layer (Wood, Akehurst, Uzenkov, Howells, & McDonald-Maier, 2008), (L. Wang, Wong, & Xu, 2007).