This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Component Space
The term "component-based development" does not refer to the development of just one type of system, or to the use of just one type of component. Most conceptions of component-based development share a few fundamental concepts. Foremost of these is that components are software implementations that have interfaces and that are units of independent substitution. But beyond this, there are numerous variations, both large and small. We have found three dimensions of variation to be particularly apt for describing the big picture.
The first dimension concerns the source of software components. As we earlier noted, published component-based software methods share a premise: that the principle task of the design effort is to produce component specifications. This premise is clearly invalid in situations where most or all of the components already exist. The distinction we make, then, is between development efforts that specify their own custom components and efforts that are constrained to use only preexisting components. Today, the most important source of preexisting components is the software component marketplace. It is the marketplace that will lead to economies of scale and that will truly differentiate component-based development from other software engineering paradigms.
The second dimension concerns the environments into which components are deployed and in which they execute. Again, there are two major distinctions. Some components are deployed directly onto a native operating system. This class of component need only comply with the interfaces and conventions imposed by that operating system. Other components are deployed into a higher-level environment that is variably referred to as a component framework [3][85], business component virtual machine[36], or component standard[17]. Whatever it is called, the distinction between framework-based and operating system-based components is an important one, since a component framework constrains component developers and simplifies component integration.
The third dimension concerns the use of components to implement application versus infrastructure. Obviously this distinction is subjective: the best definition of infrastructure that we know of is "whatever it is that I need to do my job."2 Consequently, one engineer's infrastructure may well be another engineer's application. Nevertheless, the idea of infrastructure does have substantive meaning for one very large class of system—the enterprise information system. Enterprise systems tend to be, among other things, large, heterogeneous, distributed, multi-user, persistent, transactional, and secure. By infrastructure we mean the software that implements this functionality. In contrast, enterprise applications use the infrastructure to implement and deliver business services to users.
Some people refer to infrastructure dismissively as "plumbing" as a way of suggesting that this functionality should be assumed to exist within a component framework, that the problems of infrastructure are by and large solved, and that the real software engineering problems reside elsewhere. We agree that one of the benefits of component frameworks is that they bundle infrastructure services [80]. In principle, we agree with Herzum and Sims (and many others) that component technology will evolve in the direction of more complete and robust frameworks. However, we do not expect one standard framework to emerge, but rather a variety of component frameworks, each tailored to its own requirements. Such frameworks will themselves need to be integrated, and new releases of frameworks must be installed and integrated. There is no escaping infrastructure, and building and sustaining an enterprise infrastructure is an excruciatingly complex undertaking. Software engineering methods are needed here, too.
Figure 1-1 depicts these as three orthogonal dimensions in a Cartesian coordinate system. We of course understand that the world of components is far more complex than can be accommodated by these three dimensions. But the resulting picture of "component method space" adequately situates the subject matter of this book with respect to different classes of component-based system and their related development methods.
){kind=link}
As mentioned earlier, Cheesman and Daniels' UML Components targets the design of applications built using frameworks (upper right rear). Although their method includes a step to search for existing components, doing so after defining component interfaces practically guarantees that no components will be found. Herzum and Sims' are even more aggressive in postulating component frameworks than Cheesman and Daniels. They assume frameworks exist at each conceptual layer (user, workstation, enterprise, and resource) in their canonical system design. Both of these methods focus on application rather than infrastruc
Figure 1-1 The Structure of Component Method Space
The region of framework-based commercial components used for applications (upper left rear) represents an important emerging market. It includes, for example, markets in commercial off-the-shelf Enterprise JavaBeans™. Such components are already available in the commercial marketplace as stand-alone components, and as product-lines of components. While the component framework used in such applications will distill away much of the integration complexity that is tackled by this book, the market forces that drive the component market will ensure that a considerable residue of mismatch among components will remain. As a result, we expect that engineering methods that address this class of application will need to combine elements described in this book and what is described by Cheesman and Daniels. In any event, work is needed in this area, and soon.
We have dash-outlined the two uncharted regions of space corresponding to framework-based components for infrastructure. There are research projects (sometimes referred to as "programmable middleware") that are underway in this area of space. While these efforts might produce industrial-grade results, currently these regions are essentially unexplored. Note one area of space that should be avoided at all hazards: enterprise infrastructures built from custom software. There may be some justification for this for military applications or other highly specialized domains, but otherwise there is little justification for avoiding commercial technologies.
The remaining regions of component-method space—applications and infrastructure constructed predominantly from commercial-of-the-shelf (COTS) components—are the subject of this book.