A Method for Component-Based and
Service-Oriented Software Systems Engineering
A Method for Component-Based and
Service-Oriented Software Systems Engineering
PROEFSCHRIFT
ter verkrijging van de graad van doctor, aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus Prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties,
in het openbaar te verdedigen op dinsdag 22 februari 2005 om 15:30 uur
door
Zoran STOJANOVIĆ
diploma engineer en magister computer science van de Universiteit van Niš, Servië en Montenegro
Dit proefschrift is goedgekeurd door de promotor:
Prof. dr. H.G. Sol
Toegevoegd promotor: Dr. A.N.W. Dahanayake
Samenstelling promotiecommissie:
Rector Magnificus, voorzitter
Prof. dr. H.G. Sol, Technische Universiteit Delft, promotor
Dr. A.N.W. Dahanayake, Technische Universiteit Delft, toegevoegd promotor Prof. dr. ir. A. Verbraeck, University of Maryland, USA
Prof. dr. R. Welke, Georgia State University, USA Prof. dr. R.W. Wagenaar, Technische Universiteit Delft Prof. dr. ir. P.J.M. van Oosterom, Technische Universiteit Delft
To my parents To Nada
Zoran Stojanović
Oostblok 144 Delft University of Technology
2612 PG Delft Faculty of Technology, Policy and Management
The Netherlands Jaffalaan 5
Phone: +31 (0) 6 2850 2188 2628 BX Delft, The Netherlands Email: zorans@tbm.tudelft.nl Phone: +31 (0)15 278 8380
Fax: +31 (0)15 278 3429
English editor: Miranda Aldham-Breary
Printing: Febodruk BV- www.febodruk.nl, Enschede/Utrecht Cover picture: © AV Bros, www.avbros.com
Zoran Stojanović
A Method for Component-Based and Service-Oriented Software Systems Engineering Doctoral Dissertation, Delft University of Technology, The Netherlands
ISBN: 90-9019100-3
Keywords: Component-Based Development, Model-Driven Architecture, Service-Oriented Software Engineering
Copyright © 2005 by Zoran Stojanović
All rights reserved. No parts of this publication may be reproduced, stored in a retrieval system, or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the written permission of the author.
Preface ... xi
1 Components and Services ... 1
1.1 Background and Motivation ... 1
1.1.1 Managing Complexity and Changes... 1
1.1.2 Methodology Needs... 5
1.2 Research Objective and Questions ... 7
1.3 Research Approach... 12
1.3.1 Research philosophy... 12
1.3.2 Research strategy... 13
1.3.3 Research instruments... 15
1.4 Thesis Outline ... 16
2 The State-of-the-Art of Component-Based Software Systems Development ... 19
2.1 The Roots of CBD... 19
2.2 Component Basics ... 21
2.2.1 Component Definitions ... 21
2.2.2 Components and Objects... 23
2.2.3 Component Interface ... 25
2.2.4 Components and Architecture ... 26
2.3 Technology Standards for CBD ... 29
2.3.1 Microsoft Component Model ... 29
2.3.2 Enterprise Java Beans Component Model (EJB)... 30
2.3.3 CORBA Component Model (CCM)... 31
2.3.4 Summary of Implementation Models ... 32
2.4 Component-Based Development Methods and Approaches... 33
2.4.1 Rational Unified Process ... 33
2.4.2 Select Perspective... 34
2.4.3 Catalysis ... 35
2.4.4 KobrA... 36
2.4.5 UML Components... 37
2.4.6 Business Component Factory ... 38
2.4.7 Summary of the Methods ... 39
2.5 Components and Web Services... 40
2.6 Model-Driven Development and Agile Development ... 43
2.6.1 Model-Driven Architecture ... 43
2.6.2 Agile Development... 44
2.6.3 Model-driven vs. Agile Development ... 45
2.7.2 UML 2.0 ... 47
2.8 State-of-the-Art Survey Findings... 49
2.8.1 Analysis of the CBD Methods... 50
2.8.1.1 The Way of Thinking... 51
2.8.1.2 The Way of Modeling... 54
2.8.1.3 The Way of Working ... 56
2.8.1.4 The Way of Controlling ... 59
2.9 CBD Method Requirements ... 60
2.9.1 Basic Method Requirements... 60
2.9.2 Requirements for Component-Orientation ... 61
2.9.3 Evaluation of CBD methods... 62
2.9.4 Evaluation Findings... 64
2.9.5 Conclusion... 66
3 Component-Based Development in Practice ... 67
3.1 Airport Business ... 67
3.1.1 Airport Strategic Exploration ... 67
3.1.2 A Support for Airport Strategic Planning... 69
3.2 The Airport Business Suite... 70
3.2.1 The System Structure ... 70
3.2.2 Prototype Implementation ... 71
3.3 Design and Implementation of the ABS ... 72
3.3.1 The Basic Component Architecture of the ABS... 72
3.3.2 Decomposition of the Main Model Components... 73
3.3.3 Implementation of the ABS Components... 75
3.3.4 The Role of the Researcher ... 76
3.4 The Role of CBD in the ABS Project... 77
3.4.1 System Flexibility and Adaptability ... 77
3.4.2 Project Team Organization... 78
3.4.3 Iterative and Incremental Development... 79
3.5 Lessons Learned Practicing CBD ... 80
3.5.1 The ABS Component-Based Approach... 80
3.5.2 Evaluation of the ABS component-based development approach... 82
3.5.3 Evaluation Findings and Conclusions ... 83
4 Component Concepts and Definitions ... 87
4.1 Basic Component Concepts ... 87
4.1.1 Components and Composition... 88
4.1.2 Component Essentials ... 89
4.1.3 Different Views on Components ... 92
4.2.2 Behavior Viewpoint Specification... 95
4.2.3 Information Viewpoint Specification ... 97
4.2.4 Realization Viewpoint Specification ... 97
4.2.5 Component Specification vs. Interface... 99
4.3 Components in the Development Lifecycle ... 99
4.3.1 Coupling and Cohesion ... 99
4.3.2 Component Facets ... 100
4.3.3 Component Granularity and Types... 102
4.3.4 Component Reusability and Replaceability... 104
4.4 Representing Web Services Using Component Concepts ... 105
4.5 Discussion and Conclusion ... 107
5 Component Modeling Techniques and Notations... 111
5.1 Modeling Components Using UML ... 112
5.1.1 Modeling Basic Component Concepts ... 112
5.1.2 Component Context in UML... 115
5.1.3 Component Behavior in UML... 116
5.1.4 Component Information in UML ... 119
5.1.5 Component Implementation in UML ... 121
5.1.6 Component Stereotypes... 122
5.1.7 Component Package ... 123
5.1.8 Modeling Component Collaboration ... 124
5.1.9 Alternative Component Modeling ... 126
5.2 Textual Representation of Components ... 127
5.2.1 Component Modeling using IDL... 127
5.2.2 A Component Definition Language to extend IDL ... 129
5.2.3 Related Work... 131
5.2.4 Concluding Remarks ... 133
5.3 Machine-Readable Representation of Components ... 134
5.4 Summary... 140
6 Component-Oriented Architecture Design and Implementation... 143
6.1 Method Requirements... 143
6.2 Related Work... 145
6.3 An Overview of the Method ... 149
6.4 Business Domain Model... 154
6.5. Business Component Model ... 157
6.5.1 Business Requirements Analysis... 157
6.5.2 Identifying Business Components ... 159
6.5.2.1 Existing Approaches for Identifying Components ... 159
6.5.3 Specifying Business Components ... 165
6.6 Application Component Model ... 166
6.7 Component Refactoring... 170
6.8 Implementation Component Model... 173
6.9 Model Packages and Tool Support ... 177
6.10 Summary... 178
7 Test and Evaluation of the Method... 183
7.1 Usability of the Method... 183
7.1.1 An Introduction to the Sample System... 184
7.1.2 Business Component Model... 187
7.1.3 Application Component Model ... 195
7.1.4 Implementation Component Model... 197
7.2 Users’ Evaluation of the Method ... 197
7.2.1 Case Study... 198
7.2.2 Survey Settings... 199
7.2.3 Survey Questionnaires... 200
7.2.4 Survey Summary ... 205
7.3 Added Value of the Method... 205
7.3.1 Methods comparison ... 205
7.3.2 Impact of the Method ... 208
7.4 Summary... 212
8 Epilogue... 213
8.1 Research Findings ... 213
8.1.1 Research Context... 213
8.1.2 Main Contributions... 216
8.1.2.1 Research Question One ... 216
8.1.2.2 Research Question Two ... 219
8.1.2.3 Research Question Three... 220
8.1.3 Reflection on the Research Approach ... 222
8.2 Further Research ... 223
References ... 227
Appendix A UML 2.0 Modeling Notation ... 239
Appendix B Survey Questionnaire... 241
Appendix C List of Abbreviations ... 247
Summary ... 249
Samenvatting... 253
The sea is dangerous and its storms terrible, but these obstacles have never been sufficient reason to remain ashore…unlike the mediocre, intrepid spirits seek victory over those things that seem impossible…it is with an iron will that they embark on the most daring of all endeavors…to meet the shadowy future, without fear and conquer the unknown.
Ferdinand Magellan, explorer (circa 1520)
Information technology (IT) and systems have become the backbone of modern enterprises and they provide a wealth of new opportunities for conducting business. The ability of an enterprise to manage the complexity of its information systems and to adapt rapidly to business changes has been widely recognized as a crucial factor for business success. Therefore, an effective approach for building system solutions that support business goals and strategic decisions, and that can be easily adapted to meet business changes represents an essential business knowledge asset. There is a growing consensus in the business/IT community that the way to create these adaptive, and potentially complex, IT systems is through components and services – discrete units of business functionality that collaborate over contract-based interfaces using standard protocols and platforms.
During the last few years, component-based development (CBD) and Web services (WS) have been widely used for building flexible enterprise-scale systems and providing effective inter- and intra-enterprise application integration. While the technology and implementation standards for CBD and WS have already been established in practice, further efforts are necessary to design methods and techniques for engineering these complex computing systems, from business requirements to software implementation. To gain the full benefit of these new development paradigms, improvements in technology must be followed by improvements in the development process. Therefore, a more formal and well-defined system development strategy that includes a set of consistent concepts, a proper modeling notation, guidelines, techniques and tools is required as an essential part of IT development within an enterprise.
A method for software systems engineering following component-based and service-oriented concepts, principles and practices is designed and presented in this thesis. A set of consistent and technology-independent component concepts is defined in the method, together with the types, facets and granularity levels of components in the context of the development process lifecycle. The component concepts are modeled throughout the development process, depending on the reason for the modeling and specification, using techniques and notations based on Unified Modeling Language (UML) 2.0, Interface Definition Language (IDL) and eXtensible Markup Language (XML), enriched with extensions where necessary. The method further provides pragmatic guidelines, techniques and milestones that use the defined concepts and notations to facilitate a stepwise development process in a component-based and service-oriented manner. The method prescribes which activities should be carried out within each
believe that our method is general, flexible and scalable enough to be used in component-based architectural design and development for a wide range of IT systems, from small-scale desktop applications to complex, Internet-based, enterprise-scale IT systems.
Many people have helped me to conduct the research presented in this thesis and to achieve a number of scientific and professional objectives. First, I would like to thank Henk Sol for supervising and supporting this research. He provided me with unconditional freedom to perform this research in a most approachable way for me and made many valuable comments and suggestions that helped to keep me on track. Second, many thanks to Ajantha Dahanayake for fruitful lengthy discussions, valuable input, and profound support, while conducting the research and during the writing process of a number of joint publications.
I had the pleasure to work with many nice, stimulating colleagues at Delft University of Technology. Many thanks to Jeroen Lorist, Amr Ali Eldin, Tamrat Tewoldeberhan, Semir Daskapan, Boris Shishkov and Corné Versteegt for being wonderful friends and for the constructive discussions we had about research and about “outside” life. Many thanks to all the members of the Systems Engineering group for being pleasant colleagues and for supporting me in various ways during the research. Thanks are also due to Miranda Aldham-Breary who helped me to improve my English. I would like to thank the people involved in the BETADE research project for sharing ideas and giving valuable input and support, and for the enjoyable time spent together attempting to answer the question: “What are building blocks?” I want to thank the people involved in my case studies for helping me to achieve my research goals, namely the members of the ABS project and the employees of Geodan BV. Perhaps the most difficult thing in doing a PhD is that most of the time the researcher works alone. However, when I was not working I was glad I had the support of many good friends, with whom I have shared the common memories, common strategies to deal with the difficulties of living in a foreign country and common dreams about living a better life far away from our homelands. Thank you my friends for many enjoyable moments spent together and for making me feel at home.
Last, but certainly not least, I would like to express my deepest gratitude to my parents, Hranislav and Dragica for all their love, support, care, sacrifice, dedication and efforts during my whole life to get me to where I am now. Unfortunately, my father passed away recently and did not get to see this thesis completed, but I know that he would have been very proud of me. I dedicate this book to the memory of my father. Further, I owe many thanks to my brothers, Ivan and Dragan, who have constantly been with me although thousands miles away. Finally, my deepest thanks go to my beloved wife Nada, for all her love, care, understanding, patience and support during this important and difficult period of our lives.
Zoran Stojanović Delft, January 2005
Modern enterprises are caught in the flux of rapid and often unpredictable changes in business and Information Technology (IT). New business demands caused by the need of an enterprise to be competitive in its market require the immediate support of advanced IT solutions. At the same time, new IT opportunities and achievements are constantly emerging and must be rapidly adopted to support new and more effective ways of conducting business. Therefore, it is crucial to provide a way to achieve effective business-IT alignment in terms of producing high quality and flexible IT solutions within a short time-to-market that satisfy complex business functionality needs and change as business changes (Butler Group, 2003).
1.1 Background and Motivation
1.1.1 Managing Complexity and Changes
Enterprise IT systems are, by their very nature, large and complex. Many of them have evolved over years as a way to combine legacy assets, third-party software packages, outsourced applications and newly built functionality, with all these parts possibly running on different computing resources. Due to their complex and often monolithic structure, these systems can be very difficult to test and understand, which can result in low-reliability and a long development lifecycle. Moreover, if one part of the system needs to be upgraded, this often affects the system as a whole causing changes to propagate throughout the system in an unpredictable manner (Szyperski, 1998; Sprott and Wilkes, 1999). There is the risk that businesses may become dependent on IT system infrastructures that are complex to manage and that cannot evolve at the pace required to support changing business goals (Veryard, 2001).
Therefore, the ability to manage the complexity of IT systems used to support business and to adapt rapidly to changes in business and IT has been widely recognized as a crucial factor in the modern business and IT world (Brown and Wallnau, 1998; Gartner Group, 1998). During the last years, there has been a growing consensus that, to manage complexity and changes effectively in today’s agile business world, complex IT systems need to be built as a set of discrete building blocks of functionality that can be integrated to form a meaningful, dedicated whole to provide specific support for particular business functions (Heineman and Councill, 2001; Crnkovic and Larsson, 2002). This strategy of separation of concerns, of
divide-and-2
conquer and plug-and-play used in building IT systems is not new. It has been the goal of the information systems engineering community since the beginning of software development, largely motivated by similar strategies that have been successfully applied in other complex systems engineering disciplines. It is believed that modularization results in a shortened time to market, lower production costs, more evolvable systems and systems of a higher quality (Szyperski, 1998). It was recognized at the 1968 NATO Conference that producing software systems, due to the increasing system complexity, should be treated as an engineering discipline (McIlroy, 1968). Parnas (1972) introduced various concepts and requirements for decomposing system into modules. Since then, a number of development paradigms related to building software systems from parts have been proposed, using the concepts of functions, subroutines, modules, units, packages, subsystems, objects, and components. Parallel to applying the modularization strategy in system development, attempts have been made to define these building blocks of a system at a higher-level of abstraction, i.e. larger grained and semantically closer to the problem owner. As one of the founders of Unified Modeling Language (UML) Booch remarked in his presentation The Limits of Software, “the entire history of software engineering is that of the rise in levels of abstraction” (Booch, 2002). The new levels of abstraction allow us to deal with greater levels of software complexity and help us to bridge the gap between the users and developers of the system, i.e. between the outside view of the system and how it is actually implemented.
The object-orientation (OO) paradigm, based on ideas first introduced in the late 1960s by creating the Simula language (Dahl, Myhrhaug and Nygaard, 1968), has become well established as a cornerstone of IT development defining new programming languages (Smalltalk, C++, Java, etc.) and development methods (Booch, 1986; Rumbaugh, Blaha, Premerlani, Eddy, and Lorenson, 1991; Jacobson, Christerson, Jonsson, and Overgaard, 1992; Cook and Daniels, 1994). One of the main characteristics of the OO paradigm is that, for the first time, the business user and the software developer have a means to achieve a common abstraction in terms of an object that associates functionality with data, represents a real-world entity and constitutes the main building block of a software system (Booch, 1986). However, IT practice has shown that it is difficult to manage the complexity of large projects using purely OO techniques (Udell, 1994; Szyperski, 1998; Whitehead, 2002). Applying the OO approach can lead to too many objects/classes with fine granularity and numerous associations among them. Objects are tightly coupled and wired together which results in complex systems with monolithic structures, which are difficult to change, evolve and adapt (Nierstrasz, 1995; D’Souza and Wills, 1999).
Recently, Component-Based Development (CBD) has been introduced as a solution for building complex and adaptive enterprise IT systems in the Internet era (Welke, 1994; Brown and Wallnau, 1998; Szyperski, 1998; Crnkovic and Larsson, 2002). Using the CBD paradigm, system development becomes the selection, reconfiguration, adaptation, assembling and deployment of encapsulated, replaceable, interoperable system elements with clear functionality and hidden implementation, rather than building the whole system from scratch
3 (Brown, 2000; Clements, 2000). One of the primary aims of CBD is to deal with the increasing complexity and size of business applications (Allen and Frost, 1998; Allen, 2000). Moreover, using CBD helps us to manage changes better as it can be used effectively to localize changes inside single components and prevent the uncontrolled propagation of changes throughout the system (Cheesman and Daniels, 2000; Veryard, 2001).
Other potential benefits of following the CBD paradigm in system development, often cited in the literature from the field, are outlined below (Heineman and Councill, 2001; Crnkovic and Larsson, 2002). Using components to develop IT systems reduces development costs as it supports reuse of existing, developed and pre-tested components. In addition, reuse of existing components increases productivity, since system development teams do not have to start building new applications from scratch. A component can be replaced with an improved version or another component as long as the provided functionality is the same. Building with components also reduces maintenance costs. Since components are encapsulated, it is possible to make changes to their implementation without affecting all the systems that rely on them. A component approach also allows system developers to reuse existing knowledge in the form of its legacy software assets, which are often still written in COBOL, thus supporting the continued use of software that represents considerable past investments for a business. Encapsulating such legacy applications and turning them into components allows them to be integrated with new components to accommodate a broader range of business process variability and evolution. Using CBD helps system developers to build higher quality systems since the components that are used have already been pre-tested and certified in prior projects. CBD offers the possibility for parallel work during development projects as different components can be built by different project groups working simultaneously. Finally, CBD provides better system scalability in a way that a system made of components can easily grow in size by adding new components or replacing existing ones with components offering a wider set of responsibilities.
In summary, using components allows us to address the core issues and challenges in modern system development in several important ways: using components delivers complex applications that are designed to be adaptable to business and technology changes; their use increases productivity and speed of delivery, without loss of quality; and, components enables the integration of legacy assets with modern approaches, which protects previous investments (Sprott and Wilkes, 1999; Allen, 2000). The Gartner Group predicted in 1998 that, by the year of 2004, ICT organizations that have matured in CBD methods and that have a large inventory of business components will have the potential to be five to ten times more productive and responsive to changes than those that do not. The main concepts and benefits of the CBD approach are shown in the Figure 1.1. The elements of the figure with the arrows pointed at the “CBD oval” represent the main concepts and characteristics that drive CBD. The elements with the arrows pointed away from the oval represent the main benefits of introducing CBD in an enterprise.
4
Figure 1.1 Concepts and benefits of CBD (adopted from Sprott and Wilkes, 1999) It is not just important to design and develop the individual components that provide the services we need. It is just as important to provide a suitable mechanism to integrate them into a meaningful whole to realize higher-level business functionality. Any strategy for separation of concerns into particular components must also provide mechanisms for seamless, consistent and meaningful integration of these components, to quote Jackson (1990) “having divided to conquer, we must reunite to rule”.
During the last few years, we have witnessed the further evolution of the component way of thinking in the form of Web services (Newcomer, 2002; Kaye, 2003; Apperly et al., 2003). These have been introduced as a promising way to integrate information systems effectively inside and across the enterprises. Web services can be generally defined as loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols (W3C, 2004). From a technical perspective Web services are essentially extended and enhanced component interface constructs. The basic elements of the new service-oriented paradigm are the standards for interoperability - XML, SOAP, WSDL and UDDI, which provide platform-independent communication for software resources across the Internet. On top of this basic interoperability protocol stack, new languages and specifications for defining the composition of services to form real-world business processes have emerged, such as Business Process Execution Language for Web Services (BPEL4WS) (BPEL, 2003) and Web Service Choreography Interface (WSCI) (WSCI, 2002). Using this advanced technology, the Internet, once solely a repository of various kinds of information, is now evolving into a provider of a variety of business services and applications.
This idea of a software application as a service was recognized in the past (e.g. Brown, 2000), but it can now be fully realized using the Web services technology for systems interoperability
5 (Newcomer, 2002). Web services are organized in a Service-Oriented Architecture (SOA) that represents an approach to distributed computing that considers software resources as services available on the network (Kaye, 2003). Similar initiatives have been proposed in the past, such as CORBA (Zahavi, 2000; Siegel, 2000) or Microsoft’s DCOM (Sessions, 1998). What is new about SOA is that it relies upon universally accepted standards like XML and SOAP to provide broad interoperability among different vendors’ solutions. Using SOA, the level of abstraction is further raised, so that the main building blocks are now real world business activities encapsulating the services that offer business value to the user (Kaye, 2003). It is important to make a clear distinction between service-oriented thinking and service-oriented technology. SOA represents the service way of thinking where a business domain is organized into modular services providing business-level functionality that are provided, consumed, brokered and orchestrated into more complex services. The CBD and Web services technology and standards are just the way to implement SOA, i.e. the way to bring the service thinking into practice.
1.1.2 Methodology Needs
A common point for both CBD and Web services, as it has been the case with each development paradigm proposed so far, is that they are technology-led, i.e. they were first introduced through new technology standards, infrastructures and tools, and only then were new methods, techniques and processes proposed to target this technology in the final phase (Heineman and Councill, 2001; Crnkovic and Larsson, 2002). Although technology is essential in building complex IT solutions from components and services, it cannot be sufficient on its own to support the full extent of business and IT requirements. One cannot simply implement and deploy components and services using an advanced component middleware infrastructure without any prior plan to follow from business requirements to implementation (Brown, 2000; Whitehead, 2002). As using component middleware technology does not ensure that one will achieve the promised benefits of CBD, conversely, the CBD paradigm can be successfully employed without using this technology (Szyperski, 1998). A similar issue now arises in the case of Web services. As there is more to CBD than packaging software into Java Beans or .NET components, there is more to service-orientation than simply rendering interfaces of e.g. programming objects as Web services (Apperly et al., 2003; Kaye, 2003). Furthermore, the set of technologies and standards available for CBD and Web services is complex and constantly evolving. This can cause problems whenever new versions of interoperability protocols or technology infrastructure appear. Moreover, all of these technologies are low level, based on XML or J2EE and .NET platforms. Developing systems directly using these technologies is tedious, complex and error prone (Szyperski, 1998; Cheesman and Daniels, 2000). At the same time, by using only pure technology, the system development activities are largely separated from the business user’s point of view. This can result in the risk that a developed system does not really reflect business needs, and this may be recognized quite late in the project lifecycle (Allen 2000; Williams, 2000). As the
6
Butler Group suggests in their report Application Development Strategies, technology and tools are rarely to blame for the high incidence of IT project failures (Butler Group, 2003). Improvements in technology must be followed with improvements in the process of development. The Butler Group believes that a formal, documented, application development strategy, including selection of appropriate processes, methodologies and tools, is an essential part of the overall process of IT governance.
The real challenge lies not just in new technology per se, but also in how best to make use of the available technology using systems engineering methods and techniques (Frankel, 2003). A software development method can be defined as a regular and systematic way of conducting the analysis and design portion of a software development process (Wallnau, Hissam and Seacord, 2001), or as a standard that describes the characteristics of the orderly process or procedure used in the engineering of a product or performing a service (IEEE standard, http://www.ieee.org). Therefore, as pointed out by Herzum and Sims (2000), Atkinson et al. (2002), Crnkovic and Larsson (2002) and Apperly et al. (2003), one of the biggest challenges facing component-based and service-oriented development is the lack of a methodology for building complex Web-enabled systems using the notion of components and services. Due to the complexity of their computing models, the need for a development method in the context of CBD and Web services is even more important than for traditional software development (Heineman and Councill, 2001; Kaye, 2003). Applying well-defined development methods and techniques ensures that a development project does not end up with a random collection of unusable, although technologically feasible, components and services (D’Souza and Wills, 1999; Herzum and Sims, 2000; Allen, 2000;). While it is relatively straightforward to break down an application into components such as buttons and dialogue boxes to build a graphical user interface, building a distributed, multi-tier application where core components must interoperate over the Internet requires effort, investment and a design of a totally different order (Heineman and Councill, 2001; Atkinson et al., 2002). Applying a well-defined method within a disciplined development process can help us to gain the full benefits of the CBD and service-orientation paradigms given above (Apperly et al., 2003). For example, a method allows us to reuse models, specifications and designs and not just to reuse software code. As Sommerville (2000) states, the potential gains from reusing abstract products of the development process, such as specifications and designs, may be greater than those to be obtained from reusing code components, since they are more abstract than low-level software code and hence more widely applicable. Furthermore, a CBD method can help us to develop systems to a higher-level of abstraction which will make the development process more productive, flexible and understandable for business people who define the system requirements, use the solutions and who decide future strategies, while the developers handle the tedious details of low-level technologies (Herzum and Sims, 2000; Atkinson et al., 2002). The set of component constructs, made in the way a business analyst sees an application being developed, can be gradually mapped to the low-level software constructs in a way dictated by the method and practiced through the development process (Frankel, 2003). This
7 transformation of high-level business models to logical system specification and then to a technology infrastructure of choice, potentially automated by an advanced tool, is the main idea behind the current trend in system development proposed by the Object Management Group (OMG) in the form of Model-Driven Architecture (MDA) (OMG-MDA, 2004).
1.2 Research Objective and Questions
While application functionality is routinely packaged into components and services today, the essential component-based and service-oriented development methods that enable application adaptability, widespread reuse and commercialization still have little acceptance (Heineman and Councill, 2001; Whitehead, 2002). The IT community has just recently started to recognize the importance of new CBD methods, processes, and techniques such as Catalysis (D’Souza and Wills, 1999), Select Perspective (Allen and Frost, 1998) and Rational Unified Process (Booch, Rumbaugh and Jacobson, 1999). The way these methods handle component concepts is significantly influenced by their object-oriented origins (Crnkovic and Larsson, 2002; Dahanayake, Sol and Stojanović, 2003). The methods inherit difficulties in recognizing the fundamental nature of components and consider the componentization aspects as ways of code packaging (Eeles and Sims, 1998; Szyperski, 1998).
Typical component definitions that consider a component purely as an implementation artifact are given by the UML 1.3 standard (OMG-UML 1.3, 1999), where components are defined through physical component diagrams, and the Gartner Group (1998).
♦ A component is a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces (UML 1.3 standard).
♦ A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group).
A consistent view on the component concept beyond the pure technology perspective has been largely missing (D’Souza and Wills, 1999; Atkinson et al., 2002). The numerous definitions of a component that have been proposed so far show clearly that everybody sees components differently. A clear distinction between components and concepts such as objects/classes, packages, subsystems and modules, has yet to be made (Heineman and Councill, 2001). Treating components as software packaging units at the end of the development lifecycle while still following traditional object-oriented analysis and design has created a gap between detailed software design performed using OO concepts and implementation using software components. This has given rise to a need to define a strategy for packaging a hierarchy of OO classes/objects into cohesive implementation units, i.e. components. Various approaches for solving this have been proposed, based on different ways of measuring the cohesiveness between objects that should be deployed into the same implementation component (Ambler, 2001; Larman, 2001; Jain, Chalimeda, Ivaturi and Reddy, 2001). Furthermore, by using
8
components as implementation artifacts only, software engineers focus their reuse efforts on the implementation level, where technology changes rapidly and standards are only just emerging. As a consequence of this way of thinking, the significance of the component mindset as a paradigm shift in system development, and the potential of the component concept to provide a common ground between business and technology concerns, have not yet been truly recognized (Allen, 2000). Moreover, a way to express the design of software components in an implementation-neutral fashion, a level above the latest language fashion, is missing and strongly required (Kaye, 2003).
A newer generation of CBD methods and approaches proposed recently have started to define components as units of business functionality under the name of business components. However, object-orientation has still a strong influence on defining these business components, making them rather similar to old-fashion business objects (Eeles and Sims, 1998). These methods typically define a business component as a representation and implementation of a business concept that is relatively autonomous in the problem space (Herzum and Sims, 2000). Components are often identified based on underlying business entities, such as Order, Customer or Account (Cheesman and Daniels, 2000). Such components are too fine-grained and entity-oriented to be used effectively in the design and development of complex, Web-based and service-oriented applications (Apperly et al., 2003). Due to the recent increase of interest in, and the importance of, the new paradigm of Web services in inter-enterprise collaboration and integration as a further evolution of component thinking, there is a strong need for a method that provides mechanisms and techniques for modeling and designing Web services and service-oriented architecture (Apperly et al., 2003; Stojanović, Dahanayake and Sol, 2004a). Related to this, the method should support the design decisions about what part of the application can be exposed as a marketable, value-added Web service, or what part of the system architecture can be realized by invoking a Web service from the service provider (Kaye, 2003). Current CBD methods do not provide necessary support for modeling and designing SOA (Apperly et al., 2003). These methods define components based on underlying business entities and, therefore, do not posses a sufficient expressive power to define the concept and behavior of the services that operate across these entities. Exposing the interface of a business entity object as a Web service using the interoperability protocols can easily cause a communication overhead due to fine-granularity of the exposed service and its potentially high coupling with the rest of the system. Furthermore, exposing interfaces of business objects as Web services does not necessarily mean that one designs a SOA, where the main elements are larger-grained loosely coupled business added value services that are at a higher level of abstraction and granularity than OO objects (Kaye, 2003). Therefore, a paradigm shift from components as objects to components as service managers should be defined, making the method capable of modeling the system architecture that represents a contract-based collaboration of components and services (Stojanović, Dahanayake and Sol, 2004a). Components defined in a behavior-driven and service-oriented manner are able to provide a straightforward mapping of business processes
9 into the service-oriented system architecture, where the collaboration of services provided by components represents the core of the system (Allen, 2000; Apperly et al., 2003).
New developments in the field of software engineering, such as Model-Driven Architecture (MDA), UML 2.0 (OMG-UML2, 2004) and the UML for profile for Enterprise Distributed Object Computing (EDOC) (OMG-UML4EDOC, 2004) have recently emerged. MDA shows the power, and importance, of modeling and specifies the possibility of transformations (even automated) between the models at different levels of abstraction. MDA defines the possibility to create high-level business models and then perform successive model transformation and final code generations that gives the software code, or a great part of it. The UML for EDOC and the new major revision of UML, version 2.0, define new ways of component thinking and component modeling. Unlike UML 1.x, they define components as larger design units that will typically be implemented using software modules. However, the concept of service is still not defined as a first-class citizen within these modeling frameworks. It is worth noting that, although UML 2.0 and UML for EDOC bring a lot of definitions and modeling techniques specifying components and related concepts, they do not define stepwise guidelines, methods and techniques for using components within the development process, i.e. they define the way of thinking and the way of modeling, but not the way of working, and in that sense they are method-independent.
The full benefit of the component and service way of thinking can be achieved only if the component and service concepts are integrated into each of the phases of a development process in a formal and systematic way (Herzum and Sims, 2000; Atkinson et al., 2002; Butler Group, 2003). Components providing services that support business processes and goals need to be identified and defined early in the development process, then successively modeled and specified in the analysis and design phase, and finally implemented using available component implementation technology (Frankel, 2003). Such truly component- and service-oriented process would maximize the benefits of component and service thinking throughout the process in terms of more adaptable and maintainable system architecture and usefulness of advanced component and Web service technology to implement that architecture. Therefore, the main challenge lies in creating component-based and service-oriented MDA models at different levels of abstraction that help us to map business requirements into software implementation. A method built upon this basis, as its main vocabulary, should provide precise and consistent definitions of various aspects of components in a development process. These aspects are: essential component concepts, concepts related to component specification, different forms and facets of components throughout the lifecycle, from conceptualization to implementation, different granularity and abstraction levels of components within the development process, and properties of components such as cohesion, coupling, reusability and replaceability.
In relation to this, a method should provide an effective means for modeling and specifying given artifacts within the process, at the conceptual and specification level using a graphical
10
modeling technique, at the level that is a step above programming languages using e.g. a textual pseudo-code, and at the machine-readable level that is the basis for communication among computer systems. Finally, a method should define a set of guidelines, techniques and steps to integrate the concepts and modeling techniques into a meaningful whole and place them in the context of a development process that will be used to guide the project from business requirements to software implementation and deployment.
Taking the discussion presented above into consideration, the main objective of our research is formulated as follows:
To design a method for component-based and service-oriented software systems engineering that supports components and services during the whole system development lifecycle, from business requirements to implementation.
While designing the method, we take into account the methodology framework defined by Sol (1990), which pays explicit attention to all the important aspects of a development methodology. Sol’s framework defines a set of essential factors that characterizes an information systems development method and classifies them into a way of thinking, way of modeling, way of working, and a way of controlling, Figure 1.2. The way of thinking of the method provides an abstract description of the underlying concepts together with their interrelationships and properties. The way of modeling of the method structures the models, which can be used in the information system development, i.e. it provides a set of techniques and an abstract language in which to express the models. The way of working of the method organizes the way in which an information system is developed. It defines the possible tasks, including sub-tasks and ordering of tasks, to be performed as part of the development process. It furthermore provides guidelines on how these tasks should be performed. The way of controlling of the method deals specifies management aspects of the development process in terms of the management of resources, actor roles, intermediate and final results, etc.
Figure 1.2 Methodology framework for information systems development
The research questions that we addressed to achieve our research objective were inspired by the methodology framework given above. Each research question corresponds to one of the
11 main elements of the development method; the first research question deals with the way of thinking of the method, the second deals with the way of modeling of the method, and the third deals with the way of working of the method and partly with the way of controlling of the method. The research questions are defined as follows.
1. How can a technology-independent and coherent set of component concepts be defined to address various aspects of components throughout the development process? 2. What modeling techniques and notations can be used to express the component concepts
in a clear and understandable way to all stakeholders involved in the development process?
3. How can the procedures, techniques, steps and rules of a method be defined to guide the development process, from business requirements to software implementation, using the defined component concepts and modeling techniques and notations?
The research should result in a method that provides a well-defined and technology-independent component-based and service-oriented design of IT systems that support and realize business processes and goals. The systems are designed and realized as a collaboration of components that offer services at different levels of granularity and abstraction. The method should enable the precise specification of system architecture, as a set of contract-based components and their collaboration, to be mapped into a platform-specific implementation using the technology of choice (Frankel, 2003). The method takes into account that not all components of a system can be or will be implemented in-house. They can be outsourced, bought as Commercial-Off-The-Shelf (COTS) components, made by encapsulating legacy assets, or invoked as Web services over the Internet. Applying the method should result in well-specified components that reflect business needs and that are, at the same time, based on technology reality, which is an essential factor in providing cost effective management of business and technology changes (Allen, 2000; Apperly et al., 2003). Today, a component-based representation of a business domain is becoming a great metaphor for business people who are considering how they want to develop their business models in terms of collaborating chunks of business functionality as a way to provide necessary business agility (Veryard, 2001; IBM, 2004). The method we propose should ensure that this separation of concerns, starting at the business level, is mapped appropriately into loosely coupled well-specified and, further, well-implemented components and services, to provide effective business-IT alignment.
Potential users of the research results are all the actors in the development process, including business analysts, system architects and software developers. Using the set of defined component concepts, modeling notation and guidelines for transforming business requirements into software artifacts, they can jointly overhaul IT systems used to support a business. In this way, they can simplify the IT architecture, making it more flexible,
cost-12
effective and responsive to business changes, and bridge the gap between IT and business, which is the problem that often causes the poor business value returns on investments in advanced IT. Much of the support provided by the component-based method to the functional architect can be equally useful to the business analyst, especially as a way to partition and help master modeling complexities. In this sense, the component-based method could better connect the world of business analysts with the world of system architects, thereby providing effective business/IT alignment. At the same time, software developers retain control over how system models are turned into complete applications using advanced component-based technology infrastructure, which is transparent for business analysts, but well controlled by system architects.
1.3 Research Approach
The research approach of a scientific inquiry may be defined as following a certain research strategy in which a set of research instruments are employed to collect and analyze data on the phenomenon studied, guided by a certain research philosophy. In the following sections we discuss the research philosophy, strategy, and instruments that we applied to address our research questions and pursue the research objective described in the previous section. The research approach was chosen based on characteristics of the research objective, research questions and existing body of knowledge.
1.3.1 Research philosophy
A research philosophy underlines the way in which the data on the phenomenon studied is collected and analyzed. In general terms, a research philosophy is seen to determine the way a study is guided epistemologically. It determines what kind of knowledge can be obtained and what the limits are of that knowledge. The following research philosophies or “schools of thought” can be distinguished for research on information systems (Galliers, 1992).
Positivists generally assume that reality is objectively given and can be described using measurable properties, which are independent of the observer (researcher) and his or her instruments. Positivist studies generally attempt to test theory in an attempt to increase the predictive understanding of phenomena. In line with this, Orlikowski and Baroudi (1991) classify information systems research as positivist if there is evidence of formal propositions, quantifiable measures of variables, hypothesis testing, and the drawing of inferences about a phenomenon from the sample to a stated population. Most of the studies carried out according to this philosophy are aimed at theory testing and make use of deductive reasoning and quantitative research instruments.
More recently, an increased awareness of the complexity of the information systems issues has prompted the research community to accept interpretivism as a valid approach to research. Interpretivists, sometimes called anti-positivists, claim that reality can only be understood by
13 subjectively interpreting observations of reality. While pointing out that multiple interpretations of reality are possible, they emphasize human interpretation and understanding as constituents of scientific knowledge. Interpretative methods of research in information systems are “aimed at producing and understanding of the context of the information system, and the process whereby the information system influences and is influenced by the context” (Walsham, 1993). Most of the studies carried out according to this philosophy are aimed at building theory and make use of inductive reasoning and qualitative research instruments. Both schools have been used as the basis of studies in information systems research, however, according to Orlikowski and Baroudi (1991), 96.8% of research in the leading American information system journals follows the positivist tradition. The preference for a certain philosophy guides the choice of research instruments. Positivist research instruments often include laboratory experiments, field experiments and forecasting. Interpretivist researchers make more use of action research, descriptive/interpretive research and grounded theory. Several research instruments and techniques can be applied within either a positivist or an interpretivist context. These instruments include field studies, surveys and case studies (Clarke, 2000). Different instruments have their strengths and weaknesses (Galliers, 1992). One should look for a combination of instruments to counterbalance their respective weaknesses and strengths. Several authors (Yin, 1994; Hirscheim, 1992) refer to this observation as the pluralistic view on science. A pluralistic view on science was adopted as the research philosophy in this research, as the strengths and perspectives of both positivist and interpretivist philosophies and related research instruments have been used in various aspects of the research.
1.3.2 Research strategy
A research strategy is required to ensure that the necessary steps are carried out to execute an inquiry into the phenomenon studied. Such strategy is used to outline the sequence of data acquisition and analysis. The choice of a research strategy is based on the nature of the research problem, and on the status of theory development in the research field. The research strategy we followed in conducting this research is the inductive-hypothetic research strategy (Sol, 1982). This strategy is based on the expansion of scientific knowledge by adapting it endlessly and inductively in a multidisciplinary manner based on new observations (Galliers, 1992). The main characteristics of the inductive-hypothetic research strategy we used here are the following (Sol, 1982).
♦ It emphasizes the activities of conceptualization and problem specification, underlying specification and testing of premises in an inductive way.
♦ It enables the generation of various solutions, starting, if possible, with an analysis of the existing situation.
♦ It permits feedback and learning and enables evaluation of ideas.
14
These characteristics make the inductive-hypothetic research strategy very applicable for emerging research fields such as a component-based design and development methodology, which has been has been of interest only for last several years. Furthermore, the literature covering CBD and information systems development methodologies is rather overwhelming, but not always relevant for this research. It is difficult, if not impossible to solve the problem of improving component-based and service-oriented methodology theory and practice in a purely deductive way. An inductive research strategy seems to be most appropriate. This is reinforced by the fact that the fields of CBD, MDA and Web services have recently emerged and are still evolving, so that a well-grounded and solid theory is not yet available. Given the lack of available well-established theory in the research field, the only way to formulate a theory is to identify the requirements for a component-based development method using available literature, further refine and justify them in practice and use this combined knowledge to form a theory. This can be facilitated by an inductive approach.
The central notion of the inductive-hypothetical strategy is a shift during the research from a description of problems to the prescription of an alternate approach to solve these problems. The inductive-hypothetical strategy consists of five steps in which four types of models are constructed, as illustrated in Figure 1.3.
Figure 1.3 The inductive-hypothetic research strategy
A number of initial theories are defined and used to investigate a set of empirical situations in the first step. Attention should be paid to characteristics, heuristics, and the problems encountered. This step ends with the construction of descriptive empirical models providing a detailed insight into, and a better understanding of, the problem area. A descriptive conceptual model is then constructed by abstracting from the empirical models in the second step. This model is used to represent the essential and generic elements of the problem area under investigation and gives indications for possible solutions. A theory is constructed to solve some of the previously observed problems in the third step. Based on the conceptual description, one or more solutions for the problems encountered are designed in the form of a prescriptive conceptual model. This model is still an abstraction of the specific area of
15 interests, but explicitly defines how to address the perceived problems. The prescriptive conceptual model is implemented in a number of practical situations in the fourth step. The result of this step is a set of alternatives that provide solutions for the originally identified problems and is presented in prescriptive empirical models. The results of the prescriptive empirical situation are evaluated in the fifth step. Additional improvements or changes to the prescriptive conceptual model may be identified. The inductively expanded theory can be used as initial theory in empirical situations to start a new cycle.
1.3.3 Research instruments
Various research instruments can be applied within the three main phases of the inductive research study. We started with a review of existing literature also called a meta-analysis to get the initial starting points for our research. A comprehensive review and analysis of past research/developments can lead to new ideas and insights and can ensure that subsequent research is built on past achievements. Significant advances in our knowledge, and our ability to develop theory, can be made through such an in-depth review of the problem domain (Galliers, 1992).
The subjective/argumentative conceptual research was performed parallel to the literature survey. This type of research involves creative information systems research based more on opinion and speculation than observation (Vogel and Wetherbe, 1984). It comprises argumentative/dialectic and philosophical analysis. This creative research process can make a valuable contribution to the building of theories, which can subsequently be tested by more formal means. Its main strengths lie in the creation of new ideas and insights, while its weaknesses result from its less-structured and subjective nature (Galliers, 1992).
Drawing on the literature research and argumentative conceptual research, we decided to gain a deeper understanding of the problem domain and better identify shortcomings of the previously proposed solutions using other research instruments, namely case studies. Case study research can be characterized as qualitative and observatory, using predefined research questions (Yin, 1994). In the case study research process, the researcher goes through the phases of design, collection, analysis and report. The choice of a case study is often based on opportunism, rather than on rational grounds (Yin, 1994). An important issue for the design of our research concerns the number of case studies to be used. Single case studies are often seen as inferior to multiple case studies with respect to generality; however, when selected with care, a limited number of case studies, or even a single case study, may be very successful in terms of theory formulation and theory testing (Yin, 1994).
We used literature research to compare our findings, to sharpen emergent ideas from case studies, and to gain a better understanding and explanation of the results of the case studies. Theory development was based on an inductive case study, literature research and argumentative research. The inductive case study that was performed had the characteristics of action research. While case study research pays explicit attention to ‘why?’ and ‘how?’
16
questions, action research or applied case study research is focused on ‘how to?’ questions (Checkland, 1981; Meel, 1994; Galliers, 1992). Instead of taking the observer point of view, the researcher actively participated in the case study project and got involved in theory application, prototype implementation and testing. After the theory development, and in addition to the test case study, a literature comparison was done to find more support for our findings. Parallel to that, surveys were carried out among experts in the field on a quantitative and qualitative basis. This was used to gather written and verbal data from the potential users to evaluate the level of their satisfaction with the component-based and service-oriented design and development method proposed in this research.
1.4 Thesis Outline
The outline of the thesis is given in this section in a descriptive and graphical form shown in Figure 1.4. In this first chapter we describe the background, scope, relevance and motivation of the research performed. The research objective and questions, and research strategy and instruments to achieve the objective and address the questions are presented.
The state-of-the-art of component-based and service-oriented systems engineering is presented in chapter two. Existing concepts, development standards, technology infrastructure, and development methods are presented and critically evaluated. Weaknesses and shortcomings of the current achievements in the field are identified and conclusions are derived about how to improve the current theory and practice of systems engineering based on components and services. The chapter results in the set of requirements that is the basis of the creation of our component-based and service-oriented method.
An inductive case study about the design and development of an airport business suite, in which the researcher participated actively, is introduced in the third chapter. This case study helps to strengthen the formulation of the research objective and questions, to provide a deeper insight into the problem domain from the practical point of view, and to justify the set of method requirements introduced in the previous chapter.
The way of thinking of the method, in the form of the set of cohesive, consistent, and technology-independent component concepts, is defined in chapter four. Different viewpoints in component specification, different component facets throughout the development lifecycle and different granularity levels, from coarse-grained enterprise components to fine-grained program components are addressed in this chapter.
The way of modeling of the method in the form of various modeling techniques and notations that can be used to express the component concepts is presented in chapter five. Several modeling paradigms are presented that vary in purpose, scope and the type of expressions, textual or graphical. The modeling constructs that are delineated are able to represent the component concepts given in chapter four in a clear, coherent and easily understandable way.
17 Figure 1.4 The outline of the thesis
The way of working of the method is given in chapter six. The set of guidelines, activities, rules and techniques for mapping business requirements into software implementation, using the proposed concepts and notation, is presented. An incremental and iterative process for creating the four component architectural models that together form the complete specification of the system that can be easily implemented using the technology platform of choice is applied in the method.
The created method is tested and evaluated in chapter seven. The method is tested for usability by applying it in a case study of building a location-based geographic-information system for supporting users in the field. Based on this application, the method was evaluated by the participants in the case study at the organization where the case study was performed, using a survey technique. The main added values of the method are given, and compared with the current state of the theory and practice in the field.
The main conclusions, a reflection on our research, and recommendations for further research are discussed in chapter eight.
Systems Development
An overview of the various aspects of Component-Based Development (CBD) is presented in this chapter. The chapter starts with a basic perspective on CBD, followed by definitions of a component and related concepts. An outline of the significant achievements in the fields of component-based implementation models and component-based development methods is presented. New developments and paradigms, such as Web services, service-oriented architecture and model-driven development related to this research are presented. At the end of the chapter, an attempt is made to define the concepts and steps that are needed to improve current CBD theory and practice.
2.1 The Roots of CBD
Building complex systems from simpler components is not an invention of the software industry. Around two centuries ago, Eli Whitney proposed manufacturing rifles with interchangeable parts specified clearly according to templates, instead of crafting each rifle individually. Widely regarded as the beginning of mass production, this strategy of interchangeable components led to a dramatic increase in production capacity while delivering the additional benefits of consistent operation and easy maintenance in various manufacturing and, later, industry sectors and it has become a standard approach in e.g. the construction of various electronic devices and in advanced systems engineering.
In the field of information systems engineering, CBD is also considered to be an evolutionary rather than a revolutionary approach. It has existed in one form or another for a number of years. The idea of constructing modular software system has long been recognized as advantageous within the software community. This dates back to the early days of structure programming using subroutines and libraries serving as "components" (Parnas, 1972). During the original NATO conference, in 1968, components were seen as a solution for a software crisis or a lack of software that highlighted the widening gap between the achievements of software engineering, when compared to its ambitions. Brooks in his well-known work
Mythical Man-Month (1975) describes the difficulties involved in developing complex
software systems and presents two possible methods to avoid the complexities of these systems, namely “buy before build” and “reuse before buy”. These strategies are among the cornerstones of today’s CBD paradigm.
During the 1990’s object-oriented (OO) techniques were considered to be a powerful means for solving the software crisis due to achieved high maintainability and reusability (Cook and Daniels, 1994). Some authors state that CBD is a natural extension and an evolution of the OO paradigm, containing, as it does, many similar concepts and characteristics (Orfali et al., 1996; Brown and Wallnau, 1998). Others insist on the failure of object technology for solving software reusability problems and on the necessity for introducing a new component development paradigm (Udell, 1994). The works of Booch (1987) and Meyer (1994) are generally regarded as seminal in the advancement of ideas regarding the fundamental nature of components, particularly with regard to low-level structural properties of the components. Work done by Nierstrasz (1995) in relation to software composition for open distributed systems can be considered to be an important contribution to later CBD concepts and ideas. Further work has extended these early ideas along various dimensions, including the introduction of formal specifications into component frameworks, the development of new paradigms for data movement, and the development of improved design guidelines for what constitutes a good component that is both efficient and independently verifiable. Over the last few years component-related research has also been found under various subjects such as module interconnection languages (MILs) (Prieto-Diaz and Neighbors, 1986), module interface specification and analysis (Perry, 1989), mega-programming (Wiederhold et al., 1992), domain-specific software architectures (Fischer, 1994), software generators (Batory and Geracy, 1996), object-oriented frameworks and patterns (Gamma et al., 1995; Fayad et al., 1999), architecture description languages (ADLs) (Garlan and Perry, 1995) and real-time object-oriented modeling (ROOM) (Selic, Gullekson and Ward, 1994).
Components were first introduced at the level of implementation for fast building a graphical user interface using VBX (Visual Basic eXtensions) controls or Java controls. Following that, first Microsoft ActiveX/DCOM/COM, CORBA objects and services, and Java Beans, followed by Microsoft COM+/.NET (Microsoft .NET, 2004), CORBA Components (Siegel, 2000) and Enterprise Java Beans (EJB) (Sun, 2004) were proposed as standard component-based implementation solutions. Based on them, component-component-based frameworks and architectures were developed to speed-up application development, such as the IBM SanFrancisco framework based on EJB (Carey, Carlson, and Graser, 2000) and the TINA architecture for building telecommunication systems based on CORBA (TINA-C, 1996). A common theme to all these initiatives is a shift of emphasis from developing small, centralized monolithic systems to developing complex systems consisting of functional units deployed over nodes of the Web. The two key concepts that have emerged are: (i) components as large-grain building blocks of a system and (ii) architectures and frameworks as blueprints of the system describing its main building blocks and the way of composing them into a coherent whole.
