XML —

Data Services Components

The business services components usually handle data processing. To get the data, they make requests to the data services components. The data services components are responsible for storing and retrieving data and maintaining data integrity. They communicate directly with a data source. A data source can be a database, a text file, an XML file, an XML document stored in memory, and so on. When a system performs the Create, Read, Update, and Delete (CRUD) operations, the business services components will validate these operations. If the operations are valid, the business services components will make a request to the data services components to actually perform the operations. If the CRUD operations are invalid, the business services components will raise an error and will not have to communicate with the data services components.

A common confusion associated with the DNA model is between the data services component and the database. A data services component can be either a component that is running on a server (usually not the database server) or a stored procedure. Often a system will have the data services tier that consists of both stored procedures and components. (Some authors refer to the database as a "fourth tier of the logical model.") Either way, the actual physical database is not the data services tier, although it may contain the data services components in the form of stored procedures.

Like business services components, data services components are highly reusable. For example, an e-commerce application, an order entry application, and a reporting program for management could use the same data services component that performs CRUD operations on customer records.

Over the past year, the view on stored procedures has been changing. Earlier it was generally believed that stored procedures were the best location for data services components. Stored procedures could use the security features of the database and be centrally controlled by the database administrators. The major problem with stored procedures, however, is scalability. Replicating databases is difficult and usually inefficient. If you build all of your data services components as stored procedures and the server you are using runs out of memory or other resources trying to run these stored procedures for thousands of users, you cannot easily build a second database server and share the load between the two database servers. Your only option is to upgrade the server. If you reach a point at which the server is already at the maximum capacity the current technology can offer, your server will no longer be able to handle the required loads.

If you build data services components that are placed on a server other than the database server, you can increase the capacity of the system by adding another server. If you use some method to balance the load between the servers, the business services components can call whichever server has the least load. Since the data services components are performing services only for the business services components, it doesn't matter on which server a data services component performs the service.

Of course, if you don't build data services components as stored procedures you will probably not be able to use the database's security mechanisms directly. Instead, you will have to implement security features within your components. This security code should go into the business services components, as they will contain the rules for validating users.

NOTE
Regardless of whether you use stored procedures or components for your data services tier, you should still place validation rules in your database, in the form of triggers, constraints, and so on. Although this means that you are placing the rules in two locations: one in the database and the other in the business services tier, doing so prevents users from performing invalid CRUD operations directly on the database.