Article Preview
TopIntroduction
Object-oriented and relational paradigms are simply too different to bridge seamlessly, leading to a set of difficulties informally known as impedance mismatch (David, 1990). Impedance mismatch derives from the diverse foundations of both paradigms and it has been an open issue for more than 50 years (Cook & Ibrahim, 2005). To tackle the impedance mismatch, several solutions have been proposed, including Call Level Interfaces (CLI), Embedded SQL, object-to-relational mapping techniques (O/RM), language extensions and persistent frameworks. These solutions are geared to deal with and hide all the complexity of the translation between the two paradigms. Among the available solutions, CLI are considered the correct option whenever a fine tune control is needed to interact with databases (Cook & Ibrahim, 2005). In spite of this important advantage, CLI also convey some drawbacks. Four of the most relevant drawbacks are: 1) programmers need to completely master the schemas of the underlying databases; 2) Create, Read, Update and Update (CRUD) expressions are frequently re-written over and over again whenever similar business needs have to be addressed; 3) whenever a new CRUD expression is needed there is no other option than write the necessary source-code to manage its execution and 4) CLI do not provide any architecture to decouple development process of business tiers from the development process of application tiers. These drawbacks are increasingly relevant when schemas of databases get more and more complex, when the number of CRUD expressions increases and when the complexity of CRUD expressions increases. In reality, CLI are general low level API that do not provide any architectural policy to be followed during the development process of business tiers to address any of the mentioned drawbacks. CLI were mainly devised to address the impedance mismatch issue. To tackle these CLI drawbacks, a research has been carried out in the context of Component-Based Software Engineering (Heineman & Councill, 2001; Szyperky, Gruntz, & Murer, 2002). Component-based development aims at composing software units from other pre-built software units (Heineman & Councill, 2001). At the end, a final software system is not built as a unique block but as a composite of software units known as components (Kung-Kiu & Zheng, 2007). A key aspect for the success of any component is its capability of being adapted to be reused (Bracciali, Brogi, & Canal, 2005) which is improved if another key aspect is also considered: the reuse of computation (Elizondo & Lau, 2010). Thus, this research is focused on creating a software architecture for building adaptable business tier components, herein referred to as the Reusable Business Tier Architecture (RBTA). The adaptation process is carried out in two phases: the static phase and the dynamic phase. During the static phase, reusable business tier components (RBTC) are automatically built from a business schema to comprise a wide typed service able to address a business area, such as accountability, warehouse or sales. During the dynamic phase, CRUD expressions are deployed to RBTC, at runtime, into a pool to address specific users’ needs. RBTC are capable of managing any CRUD expression the schema of which is a sub-set of the implemented wide typed service.
Throughout this paper, all examples are based on Java, Java Database Connectivity (JDBC) (Parsian, 2005), T-SQL (SQL Server) and Northwind Microsoft database (Microsoft). The presented code may not execute properly since we only show the relevant parts for the points under discussion.
This paper is structured as follows: section 2 presents the motivation; section 3 presents an overview of the related work; section4 introduces Call Level Interfaces; section 5 presents the RBTA; section 6 discusses some aspects of RBTA and, finally, section 7 concludes and presents future work.