Architecture-Centric Software Generation: an Experimental Study on Distributed Systems Chung-Horng Lung Kamalachelva Selvarajah Dept. of Systems and Computer Engineering Carleton University Ottawa, Ontario, Canada K1S 5B6
Balasangar Balasubramaniam Poopalasinkam Elankeswaran Umatharan Gopalasundaram Nortel Networks Ottawa, Ontario, Canada
[email protected]
ABSTRACT Selecting the best architecture to fit the requirements, both functional and non-functional, is not an easy task, especially for distributed systems which are complicated and involve various techniques. Performance, in particular, is usually a challenging area for distributed systems. Generative approach at the architecture level is a useful method of supporting the exploration and evaluation of alternative architectures, and balancing different architectural qualities. This paper advocates an architecturecentric framework that consists of multiple architecture alternatives, from which the architect can select and generate a working system rather than building it from scratch. As a result, the generated working prototype system can provide key insights into both functional and non-functional requirements; these insights may be difficult to obtain otherwise. Such a framework can facilitate evaluation of architecture by providing performance profile, including latency, throughput, and etc. The framework is built with well-understood design patterns in distributed systems and through reengineering of an existing robust network system from the telecommunications industry. The concept can also be applied to other areas to support upfront analysis.
1. INTRODUCTION Rapid development and high quality are crucial elements in today’s successful enterprise software systems. The success or failure of a product can be determined by the time taken to develop the software in highly competitive areas. Unfortunately, software development time often runs over schedule, particularly for complicated systems such as distributed applications. Distributed systems may be involved in network protocols, lowlevel socket programming, concurrent programming, and highlevel applications or services. It is also common for application level requirements to be uncertain at the early stage. Another challenging issue often faced by the architect is estimating system or software performance. Many software products cannot be used as they are initially designed because of performance problems. The cost of performance failures can be tremendous [Williams03]. Software Performance Engineering
(SPE) [Smith90] has been recognized as a critical approach for addressing this issue. It is generally accepted that for higher benefits, SPE should be conducted early in the life cycle. Unfortunately, conducting SPE or performance modeling, especially at the early stages of the development, is difficult and requires a high skill level. To perform SPE effectively, the architect has to have intensive knowledge and experience in the application domain, software design, and performance engineering, which is usually unrealistic. The performance issue becomes even more challenging with respect to distributed systems. Distributed systems have become common in recent years and are built for various applications. Many design patterns in this area have been captured and documented [Schmidt00]. Design patterns present recurring and validated solutions to similar problems and could support software development to a great extent. However, some patterns, especially in distributed and concurrent areas, are specialized and may not be easy to understand or implement, especially for those who are not familiar with these areas or levels. In addition, designers may want to put their expertise primarily into the application level as opposed to the lower layers. Take a real industrial case of which one of the authors was a team member, as an example. The project was a study of an advanced network routing technique to support network traffic engineering using the MPLS (Multi-Protocol Label Switching) technologies [Awduche99]. MPLS has since become very popular in networks. Some features that MPLS supports include, among others, load balancing, resource utilization, and path protection and restoration. When the project started, there were no suitable simulation tools available and the customers requested a working prototype for concept demonstration. We also learned from the re-architecting experience that it can be a time-consuming task. In a case study, a system needed to be restructured to support additional quality-of-service (QoS) requirements. The existing system was limited due to its initial architecture: messages received from the network were processed non-preemptively. The Half-Sync/Half-Async architectural pattern [Schmidt00] was a natural fit for the restructuring. However, due to complicated concurrency controls and interactions with the application level, the restructuring itself took much longer than expected, even though the new design was wellunderstood and documented in the pattern literature. To mitigate problems such as the above, we advocate an architecture-centric generative framework to help the architect
Various factors such as applications, resource contentions, and platforms could affect the results. These systems were reengineered using those architectural and design patterns. A framework was then developed based on the previous studies.
rapidly or incrementally develop, and subsequently evaluate, the software architecture effectively. The framework is composed of multiple instantiatable architecture alternatives that are built with robust software components based on recognized patterns or existing solutions. The framework can then be used to instantiate specific types of software architecture, as selected by the user. The user can subsequently focus on the domain-specific issues. Such a framework facilitates rapid prototype development for comparison among different alternatives based on actual execution data measured from each alternative. In other words, the framework can generate quantitative and more concrete operational information, or collect more accurate or realistic data such as workload, processing speed, and packet loss.
The following describes the process in more detail, step by step. Note that these steps do not have to be carried out sequentially. Rather, this is an iterative process; some steps can also be executed in parallel. 1. Define the scope and conduct a variability analysis at the architecture level. For this project, the focus is on distributed and networked systems. In addition, we want to support comparisons of different architectural alternatives. Three commonly used architectural alternatives are selected from the concurrency management perspective. They are the traditional single thread (ST) approach using the Reactor pattern, HalfSync/Half-Asnyc (HS/HA), and Leader/Followers (LFs) [Schmidt00]. Single thread was selected, primarily due to its simplicity and, more importantly, because it was the style originally used in the existing software under study.
The structure of the rest of the paper is as follows: Section 2 discusses the building of the generative framework and the framework itself. Section 3 briefly describes the related work. Finally, Section 4 contains the summary.
2. ARCHITECTURE-CENTRIC SOFTWARE GENERATION
Lung [Lung03] conducted a preliminary variability analysis for various architectural alternatives in communications software. Figure 1 displays three of these alternatives at an abstract level. Schmidt, et al. [Schmidt00] illustrate those patterns in detail and discuss their pros and cons. Lung [Lung03] identified more variations based on those patterns. For instance, the queuing layer in Figure 1(b) could consist of multiple queues, each for one priority type for quality-of-service (QoS) requirement. QoS is a critical feature in network applications.
This section describes how the architecture-centric framework is developed, the structure and components of the framework, and how the framework is used. A brief evaluation of the framework follows.
2.1 Development Process of the Framework The framework was developed using existing working systems and well-known patterns in networked systems. An industrial software system developed by senior designers experienced in the area of network routing and a couple of working systems in a similar domain were used as the base. Extensive studies and evaluations of these systems [Alhussaini04, Lung04a, Lung04b] and relevant well-recognized patterns in this field [Schmidt00] were conducted for evolution. Based on the studies, there was no clear winner in terms of non-functional requirements.
Sync. Service Layer
The main extension of our work is integrating different architectural patterns into one framework at the architecture level. In other words, in our approach the variation points start at the architecture level. The framework can then be used to rapidly generate working systems based on different architectural patterns. As a consequence, the working systems can be used to collect operational data, e.g., number of messages processed (max and average), queue length (peak and average) and packet loss, as described earlier.
…
worker thread pool
Queuing Layer select()
select()
…
Asyn. Service Layer network
network
network (a) Single Thread
(b) Half-Sync/Half-Async
(c) Leader/Followers
Figure 1. Basic Networked and Concurrent Architectural Patterns
2. Conduct design recovery of existing robust software systems. A working network routing software system developed by industry, as well as a couple of well-tested client-server systems built for previous projects, were used for the detailed analysis. The main reason for choosing existing robust systems was to build a quality framework. Furthermore, similarities and differences among those systems were investigated and analyzed before the construction of the framework. 3. Reengineer existing systems using patterns. This step deals with reengineering the existing systems using patterns. Those patterns are at different levels. HS/HA and LFs were chosen for the architecture level because they represent different structural and execution models, as shown in Figure 1. We restructured the systems from the ST approach in C++ to HS/HA and LFs, separately [Alhussaini04, Lung04a, Lung04b]. Furthermore, other types of patterns were selected and implemented; those patterns include Monitor Object, Scoped Locking idiom, Reactor, Connector, and Acceptor [Schmidt00]. The first reengineering step was to convert ST to HS/HA in order to improve performance [Lung04b]. However, a lot of time was spent on program verification, due to complicated concurrency issues regarding the routing software. The second related task was to reengineer the HS/HA structure to support additional QoS requirements [Lung04a]. The queuing layer depicted in Figure 1(b) was restructured to accommodate multiple queues for different priorities of messages. In addition, a QoS scheduling policy was designed and implemented. The third exercise was to reengineer the ST software to LFs. 4. Conduct evaluation of architecture alternatives. An evaluation of each reengineered system was conducted, with the focus on performance. Extensive performance comparisons [Alhussaini04, Lung04a, Lung04b] and modeling [Wu03] were carried out between different alternatives. During the evaluation, we also discovered that the performance results for some scenarios could be very different for the same system simply when it ran on a different operating system kernel [Lee04]. Specifically, in one case, the same system had better results when one architecture was used over the other architecture on one OS kernel, but the results differed on a different OS kernel. This was mainly because the software applications interact intensively with the system, which caused a lot of contentions for resources. Resources are managed differently between two process/thread scheduling modules on two different kernels. This illustrates the challenge in architectural analysis, especially from a performance perspective. A working prototype can provide concrete data and be used to analyze an architecture stepwise and identify sensitive areas among alternative solutions. The approach can complement with performance modeling approaches, because the concrete data can further be used for more sophisticated performance modeling or scalability analysis.
5. Construct reusable components and the framework. The final step is to build the framework from reusable components that are developed based on patterns, if appropriate. Different types of patterns were adopted, as described earlier. The framework was also carefully tested against a variety of scenarios developed for the networked applications. Different alternatives or a combination of alternatives (e.g., one emulated router uses one architecture, the other router uses a different one) were also verified. The next section describes the structure of the framework.
2.2 Structure of the Framework As mentioned above, the scope of the current framework is to support three different architectural alternatives with reusable components built from other design patterns in networked applications whenever possible. In other words, from the architecture perspective, the approach integrates these three alternatives into one framework. Figure 2 demonstrates the overall concept and structure of the framework. The current framework was written in Java, developed in the J2SE environment. Java was chosen for the sake of simplicity and to demonstrate the concept. The GUI is the interface through which the user can select an architectural style and an architectural pattern. Distributed applications could be either Client/Server or Peer-to-Peer style. Each style can be built using any of the three architectural patterns: ST, HS/HA, or LFs, which are implemented in Java packages. Each architectural alternative is made up of generic, reusable components (represented by the letters A, B, C, and D in Figure 2) plus, if necessary, a specific component X for HS/HA. In the above example, for instance, the LFs architectural pattern is created using appropriate components: component A’, which is a variation of component A, due to its functional feature, and components B, C, E, and Y. More detailed description can be found in [Balasubramaniam05]. The current Generator is a simplified version of a traffic source and is primarily used for evaluation and verification purposes. The user can tailor it or add other new features to this component by using its existing design and interfaces. There could be more variations at the architecture level, at least in theory, as pointed out in [Lung03]. Some variations could be added to the framework. The framework is built in a way that is expandable to include those variations as well. However, in practice, not all variations may be practically useful if there are no evident advantages or special requirements.
Figure 2. Structure and Reusable Components of the Generative Framework
2.3 Usage of the Framework Using the framework is straightforward. The user simply has to go through the interface, chooses the desired alternative, and inputs data (machine names or IP addresses, for example) to set up the connections. Figure 3 is a snapshot of the GUI that allows the user to choose an architectural alternative. In this case, the LFs pattern is selected and the user needs to enter the number of Service Handlers, or threads in this case. The Service Handlers deal with application specific aspects which need to be further elaborated by the user. The number of threads is a simple variation point that can be managed easily. Once an architectural style (client/server or peer-to-peer) and an architectural pattern have been chosen, a working network system is generated. The designers can validate application requirements using the framework by adding features to or modifying existing ones in the Service Handlers (component E), shown in Figure 2. Realistic performance data can also be calibrated by designing stubs in the program.
3. RELATED WORK Since the 1980s, the concept of the generative approach has been discussed extensively in the areas of domain analysis and engineering [Prieto-Diaz91] and has been adopted in many application domains. Conceptually, our framework is built on top
Figure 3. GUI for Selecting Architectural Alternative Supported by the Framework of those approaches. The generative approach will become more and more popular [Czarnecki00] and practical in the future as more applications are becoming mature for automation. Our framework has strong tie to the design patterns in networked and concurrent applications and the ACE framework [Schmidt00]. ACE framework provides a number of components that are configurable into applications. Component-based software engineering (CBSE) is also related to our approach. Other component-based approaches include CoSMIC [Gokhale04] and MicroQoSCorba [McKinnon03]. One main difference between ACE, CoSMIC, MicroQoSCobra, CBSE or even a catalog of well documented patterns and our proposed approach is that our approach is architecture-centric. In other
words, the synthesis phase has already been built into the framework. The user does not need to perform synthesis. Our approach is easy to use and can generate a working system rapidly. In addition, it supports evaluation of alternatives at the architecture level. On the other hand, those approaches do not address software architecture explicitly. There may be many ways to glue the components. Without an architecture, composition of components may not be trivial. However, those approaches usually result in larger footprints or more alternatives.
4. CONCLUSIONS Software architecture has been recognized as a crucial factor in successful software development. Practicing architects, unfortunately, have few tools available to them for conducting front-end analysis. Evaluations of architectures are often performed on high-level descriptions. This paper advocated an architecture-centric generative approach to support software architects in requirements gathering, evaluating architecture qualities with concrete measured data, and developing a system stepwise. We also argued that such tools should be easy to use and actually useful, since these are critical elements in technology adoption. The paper also reported our empirical experience in the development of such a generative framework in distributed and concurrent applications. The framework was built using wellunderstood design patterns and through reengineering existing robust systems. The framework is also expandable, to support other new alternatives, if needed. The experience can also be applied to other problem domains.
5. ACKNOWLEDGMENTS We would like to thank Nortel Networks for providing us a network routing software system for research and education. We are also grateful to Q. Zhao, H. Xu, H. Mar, P. Kanagaratnam, A. Alhussaini, B. Balasubramaniam, P. Chandrabose, A. Kasinathan, J.-C. Lee, and X. Zhang, who worked on this project previously. The project is partially funded by NSERC (National Sciences and Engineering Research Council) of Canada.
6. REFERENCES [Alhussaini04] Alhussaini, A., Balasubramaniam, B., Chandrabose, P., and Kasinathan, A., Software Restructuring and Performance Evaluation, Project Report 2004, Dept. of Systems & Computer Eng., Carleton Univ., Ottawa, Canada. [Awduche99] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and McManus, J., Traffic Engineering over MPLS, IETF RFC 2702, 1999, http://www.ietf.org/rfc/rfc2702.txt. [Balasubramaniam05] Balasubramaniam, B., Elankeswaran, P., Gopalasundaram, U., and Selvarajah, K., Program Transformation and Building Reusable Components with Design Patterns, Project Report 2005, Dept. of Systems & Computer Eng., Carleton Univ., Ottawa, Canada. [Bardram04] Bardram, J. E., Christensen, H. B., and Hansen, K. M., “Architectural Prototyping: An Approach for Grounding Architectural Design and Learning”, Proc. of the 4th Working IEEE/IFIP Conf. on Software Architecture, June 2004, pp. 15–24.
[Batory92] Batory, D. and O’Malley, S., “The Design and Implementation of Hierarchical Software Systems with Reusable Components”, ACM TOSEM, pp. 355–398, Oct. 1992. [Bachmann03] Bachmann, F., Bass, L., Klein, M., “Preliminary Design of ArchE: A Software Architecture Design Assistant”, Technical Report CMU/SEI-2003-TR-021, Sept. 2003. [Buschmann96] Buschmann, F, Meunier, R., Rohnert, H., Sommerlad, P., Stal, Pattern-Oriented Software Architecture: A System of Patterns, Wiley, 1996. [Chen05] Chen, D.-J., Tsai, M.-J., Yang, S.-T., “UI Design Pattern Generator for Pervasive Devices”, Proc. of the Int’l Conf. on Software Eng. and Knowledge Eng, July 2005, pp. 360–365. [Czarnecki00] Czarnecki, K., Eisenecker, U.W., Generative Programming Methods, Tools, and Applications, Addison Wesley, 2000. [Floyd84] Floyd, C., “A Systematic Look at Prototyping”, in R. Budde, K. Kuhlenkamp, Mathiassen, L., and H. Zullighoven, editors Approaches to Prototyping, pp. 1–18, Springer Verlag, 1984. [Gamma95] Gamma, E., Helm, R., Johnson, R., Vlissides, J, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995. [Kazman98] Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H., and Carriere, J., “The Architecture Tradeoff Analysis Method”, Proc. of the 4th Int’l Conf. on Engineering of Complex Computer Systems, Aug. 1998, pp. 68–78. [Kostelijk05] Kostelijk, T., “Misleading Architecting Tradeoffs”, Computer, pp. 20–26, May 2005. [Lee04] Lee, J.-C. and Zhang, X., Performance Investigation of a Network System on Different Linux Kernels, Project Report 2004, Dept. of Systems & Computer Eng., Carleton Univ., Ottawa, Canada. [Lung94] C.-H. Lung, J. Cochran, G. Mackulak, and J. Urban, “Computer Simulation Software Reuse by the Generic/Specific Domain Modeling Approach”, Int’l Journal of Software Eng and Knowledge Eng, vol. 4, no. 1, March 1994, pp. 81–102. [Lung00] Lung, C.-H. and Kalaichelvan, K., “A Quantitative Approach to Software Architecture Sensitivity Analysis”, Int'l Journal of Software Eng and Knowledge Eng, vol. 10, no. 1, Feb 2000, pp. 97–114. [Lung02] Lung, C.-H., “Agile Software Architecture Recovery through Existing Solutions and Design Patterns”, Proc. of 6th IASTED Int'l Conf. on Software Eng. and Applications (SEA), Nov. 2002, pp. 539–545. [Lung03] Lung, C.-H., “Variability Analysis for Communications Software”, Proc. of the Int'l Workshop on Software Variability Management (SVM), International Conf. on Software Eng., May 2003, pp. 30–33. [Lung04a] Lung, C.-H., Zhao, Q, Xu, H., Mar, H., Kanagaratnam, P., “Experience of Communications Software Evolution and
Performance Improvement with Patterns”, Proc. of IASTED Software Engineering, Feb. 2004, pp. 321–326. [Lung04b] Lung, C.-H. and Zhao, Q., “Pattern-Oriented Reengineering of a Network System”, Journal of Systemics, Cybernetics and Informatics, volume 2, no. 5, 2004. [Lung05] Lung, C.-H., Zaman, M., Goel, N., “Reflection on Software Architecture Practices – What Works, What Remains to Be Seen, and What Are the Gaps”, Proc. of the 5th Working IEEE/IFIP Conf. on Software Architecture, Nov. 2005, pp. 221–222. [Martensson04] Martensson, F., Grahn, H., and Mattsson, M., “Prototype-based Software Architecture Evaluation – Component Quality Attribute Evaluation”, Proc. of the 4th Conf. on Software Eng. Research and Practice in Sweden, Oct. 2004, pp. 11-17. [Prieto-Diaz91] Prieto-Diaz, R., and Arango, G., "Introduction and overview: domanin analysis concepts and research directions," in Tutorial on Domain Analysis and Software Systems Modelling, IEEE Computer Society Press, 1991, pp. 9-32.
[Schmidt00] Schmidt, D., Stal, M., Rohnert, H., Buschmann, F., Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Wiley, 2000. [Smith90] Smith, C., Performance Engineering of Software Systems, Addison-Wesley, 1990. [Sztipanovits02] Sztipanovits, J. and Karsai, G., “Generative Programming for Embedded Systems”, Generative Programming and Component-Based Engineering (GPCE), Pittsburgh, October 2002. [Willams02] Williams, L.G. and Smith, C.U., “PASA: An Architectural Approach to Fixing Software Performance Problems”, in Proc. of CMG, 2002. [Willams03] Williams, L.G. and Smith, C.U., “Making the Business Case for Software Performance Engineering”, in Proc. of CMG, 2003. [Wu03] Wu, Pengfei, A Performance Model for a Network of Prototype Software Routers, MASc Thesis, Dept. of Systems & Computer Eng., Carleton University, Ottawa, Canada, July 2003.
