Benefits of a component architecture - JSP component model

 بِسۡمِ ٱللهِ ٱلرَّحۡمَـٰنِ ٱلرَّحِيمِ

Let’s look at an example of component-centric design that’s more concrete. When an architect designs a new home he or she relies on components to save time, reduce complexity, and cut costs. Rather than design every wall unit, window frame, and electrical system from scratch he or she uses existing components to simplify the task. Architects don’t design a custom air-conditioning system; they select an existing unit that will fit their requirements from the many models available on the market. There’s a good chance that the architect doesn’t have the skills or resources to design an air-conditioning system anyway. And conversely the designer of the air-conditioning system probably couldn’t build a house. Because of this component-based approach the architect and contractor can concentrate on building what they know best—houses, and the air-conditioning company can build airconditioners. Component architectures allow us to hide a component’s complexity behind an interface that allows it to interact with its environment or other components. It isn’t necessary to know the details of how a component works in order to access its functionality.

We can use this real world example to illustrate another important feature of component design—reusability. The construction company can select an off-theshelf air-conditioner because it supports standard connectors, fastens with standard screws, and runs off a standard electric voltage. Later, if the homeowner decides to replace the unit with a new and improved model, there is no need to rebuild the house—simply swap out the old component for the new. Standardized environments and design specifications have allowed for a flexible system that is easily maintained. Software components are designed to operate in specific environments, and interact in predetermined ways. The fact that components must follow a certain set of rules allows us to design systems that can accept a wide array of components.

While it would be nice if we could design our entire application from pre-existing components, that’s an approach that’s rarely practical for real application design. Usually an application developed with a component approach involves a combination of general purpose and application specific components. The benefits of component reuse sur face not only by sharing components among differing applications, but through reuse of components across several segments of the same or related applications.

A banking application, for example, might have several different customer interfaces, an employee access module, and an administrative screen. Each of these related applications could make use of a common component that contained all of the knowledge necessary to display the specifics of a particular bank account. With luck, and good forethought during component design, this banking component might be useful to anyone developing financial management applications.

Once a component has been designed, the component’s author is relatively free to change its inner-workings without having to track down all of the component’s users. The key to achieving this high level of abstractness is defining an interface that shields any application relying on the component from the details of its implementation.