Build Your System with Components

Build Your System with Components

One aspect of functional decomposition ^[4] is that it separates data from functions. One of the drawbacks to this separation is that it becomes expensive to maintain or modify a system. For example, a change to how data is stored may impact any number of functions, and it is generally hard to know which functions throughout a given system may be affected (see Figure 2.6). This is the major reason the Y2K issue was so difficult to address.

^[4] In functional decomposition, complex functions are recursively broken down into smaller and simpler functions, until you have functions that can be implemented easily. You also separate the data from the functions, which gives you a many-to-many dependency mapping between functions and data.

Figure 2.6. A Functional Decomposition Architecture. Functional decomposition has the disadvantage that changes, for example, to how data is stored, may impact many functions, leading to systems that are both highly difficult and expensive to maintain.

On the other hand, component-based development encapsulates data and the functionality operating upon that data into a component. When you need to change what data is stored, or how the data can be manipulated, those changes can be isolated to one component. This makes the system much more resilient to change (see Figure 2.7). Components can be implemented using object-oriented techniques or other techniques such as structured programming, and can be used for developing a wide array of systems including legacy systems re-engineering, new application development, or package deployment.

Figure 2.7. A Component-Based Architecture. Component-based development leads to systems that are more resilient to changes in requirements, technology, and data.

To communicate with a component, and hence take advantage of all its capabilities and code, you need to know only the component's interface. You don't need to worry about its internal workings. Even better, a component can be completely rewritten without impacting the system or system code, as long as its interface does not change. This is an important feature of component-based development called encapsulation, which makes components easy to reuse.

A component can also be assembled by other components, thereby allowing it to provide many advanced capabilities. The combination of encapsulation and the availability of large components radically increases the productivity associated with reuse when developing applications.

Component technology is also the basis for the Web services initiatives recently launched by all the major platform vendors on both J2EE and .NET platforms, and it is why Web services may well be "the next big thing" in software development. In short, Web services are "Internet-enabled" components. Think of them as components on steroids. Like all components, they have a well-defined interface, and you can take advantage of all their capabilities simply by knowing that interface. As long as the interface does not change, you are unaffected by changes to a Web service. The major difference is that whereas a normal component typically limits you to communicating with components developed on the same platform (and sometimes only with components compiled on the same system), a Web services architecture allows you to communicate independently of the platform by exposing component interfaces over the Internet. ^[5]

^[5] For more information on Web services for the .NET platform, see Thai 2001.

Summary

Component-based development relies on the principle of encapsulation and enables you to build applications that are more resilient to change. Components also enable a higher degree of reuse, allowing you to build higher-quality applications faster. This can radically decrease system maintenance costs. Component-based technology is the basis for Web services offered on J2EE and .NET platforms.