XML

Buying, Reusing, or Building Components

Components can be bought from third-party vendors. If a third-party component can be found that performs the services you need, it is usually the most economical solution. On the other hand, third-party components typically perform a large number of services that you do not need and may not exactly fit the needs of your project. You must also verify that the maker of the product will update the component to accommodate new operating system and development program releases.

Reusing existing components is also an excellent option. Often the best way to make your component reusable is to carefully plan your system before you build it. With planning, you can often identify components of the system that can be used in many places. Sometimes an identical component can be used in numerous places; at other times only a part of the component can be used in multiple places.

In addition to reusing components, you can also reuse a component template. During the designing phase, you may find that some components can be built from a particular pattern. If you are building an order entry application, for example, you may find that all of your business services components perform the same CRUD functionality. Thus, all of your business services components have Create, Read, Update, and Delete methods. You can use this pattern of shared methods to create a template that can then be used to build all of your business services components with CRUD functionality.

Building a component is the most costly option in terms of time and resources, but with proper planning and design it will guarantee that the correct component is built. Using patterns and creating reusable components can offset the cost of designing and building components from the ground up.

The best option depends on the available resources. Finances, available personnel for development, and time allowed for development are the three most common resources that will influence your decisions. Each system should be carefully analyzed to find the best solution for that system.

Locating Logical Components

The traditional view held that user services components belong on the client computer, business services components belong on the middle-tier computer, and data services components belong in stored procedures on the database computer. This placement is usually appropriate for smaller systems with a limited number of users or large Internet-style systems, but it is not always the best configuration for all systems. There are several factors you need to take into consideration when designing your deployment plan.

Performance considerations

Business services components can perform many different functions and the middle-tier computer is not always the optimal location for these components. For example, the business services components that validate input from the user services components will provide the best performance if they are located on the client computer. When the user inputs information into the user services components, the business services components can provide immediate validation because the user and business services components are both on the same computer. On the other hand, if the business services components that validate user services components are located on the server, requests to validate input must be sent to the server. Sending the validation to the server can slow down the process, especially when network traffic is heavy, and can affect the overall performance of both the application and the user.

However, some types of business services components might have better performance even though they are placed on a server. For example, you could have a business services component called by an ASP document that builds HTML pages. The Web server is communicating with the business services component, not with the client, as in the previous example. As long as the Web server has enough resources, which is usually the case, the business services components could be placed on the Web server. The data services components and the server-side business services components could also reside on the same server. The decision would be based on the expected load and the capabilities of the server.