Logical Three-Tier Model

[Previous] [Next]

When you build components in a Windows distributed system, you will define the components based on the services they perform. For example, the Web page running in the Web browser will perform services for the user, such as allowing the user to enter information, select information, or navigate to another Web page. Components placed on the Web server will receive requests from the Web browser to perform services such as accessing a particular Web page, searching the catalog for all occurrences of a particular word, and so on. The services that a system can perform are divided into three categories: user services, business services, and data services. Thus, you can form three tiers: the user services tier, the business services tier, and the data services tier. Each of these tiers consists of one or more components.

User Services Components

The user services components are responsible for passing information to and from the user. Specifically, they gather information from the user and then send the user information to the business services components for processing. After the information is processed, the user services components receive the processed results from the business services components and present them to the user. Typically, the user is a person and the user services components consist of user interface components such as Web pages in a browser, an .EXE application containing forms, and the like. A user could also be another system—in which case, there's no visible interface. An example of this scenario would be an application that verifies credit card information.

To design user services components, you must interview the potential users of the system. Based on these interviews, you can create a detailed description of the steps required to complete each of the tasks that the system will be asked to perform. These descriptions can then be turned into Unified Modeling Language (UML) use cases. UML is a set of models used to design object-oriented systems, although it can be used to design virtually any system. A use case is a text description of how a user will perform a task; each use case has a specific format such as a flowchart, a flow diagram, or a step-by-step outline in a table format. These use cases will help you organize the steps required to complete your tasks, will help you define the components your system will need to perform these tasks, and can be used as the basis of the design for your entire distributed system.

For the most part, user services components are designed to meet a specific need and are not reusable. For example, the user components specifically created for entering employee information are not likely reusable in an application that's used for obtaining order information from customers.

Besides communicating with the user, most applications must process data. For these applications, you will also need to define a set of business rules that govern how data is handled. Examples of business rules could be the requirement that every customer have a name, a customer ID, and a billing address. Business rules are similar to use cases, except that they are text descriptions of the requirements to be met to ensure a business is run correctly. In a two-tier architecture model, some or all of the business rules regarding data processing are placed in the user services components. In a three-tier architecture model, the business rules are moved from the user services components to the business services components.

Business Services Components

The business services components receive input from the user services components, interact with the data services components to retrieve or update data, and send the processed result to the user services components. The business services components ensure that the business rules are followed. For example, a user services component may ask a business services component to save a new customer record. The business services component will then verify that this new record fulfills all of the rules for a new customer record. In another example, the user services components might request that the business services components retrieve a particular Web page containing data from a database. The business services components will get the data and format it according to a set of rules and then build an HTML or XML page for the user services components.

If the business rules change, only the business services components that contain those rules will need to be changed. If the business rules are placed within the user services components, the user services components will have to be updated every time a rule changes. If such a user services component were an .EXE application installed on thousands of computers, a change in the business rules would mean reinstalling the component on all the client computers.

Separating the business rules from the user services components is only one benefit of using business services components. Business services components usually contain logic that is highly reusable. For example, if you create a business services component to retrieve product information for a Windows-based application, you don't need to rewrite this component if you want to create a Web-based application that requires the same business logic.

Using business services components also simplifies the building of your user services components. As previously mentioned, the business rules in the three-tier model are moved from the user services components to the business services components. Thus, the user services components are simplified. In addition, if you build business services components as objects that expose methods and properties, your user services components can be simplified further since the code in your user services components will consist of setting properties and calling methods of the business services objects.

For example, let's say your application requires validation of new orders. You can implement the validation logic in the user services components, but you can also separate this logic from the user services components and implement it in an Update method in the business services components. Thus, the validation of a new order will be done when you call the Update method.

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.

Connecting the Three Tiers

So far you've learned that by using Windows DNA, you can split your application's services into three parts: user services components, business services components, and data services components. Now you will learn how you can tie the three parts together. In Windows DNA, this is done by exposing system and application services through the Component Object Model (COM).

The foundation of Windows is COM, which has become COM+ in Microsoft Windows 2000. (COM as used here refers to both COM and COM+.) COM provides a way for applications to communicate with COM objects. COM also enables one object to communicate with another object through method calling and property setting. How a COM object actually performs its services is not important. Objects hide or encapsulate the details of how they work. Because an object hides how it performs its services, you can change the way an object performs its services without breaking the application that uses the object.

If the services components in each tier are COM components, the communication between tiers will be COM method calls. To be specific, your user services components will call the methods of the business services components to request services from the business services tier, and your business services components will call the methods of the data services components to ask for services from the data services tier.



Developing XML Solutions
Developing XML Solutions (DV-MPS General)
ISBN: 0735607966
EAN: 2147483647
Year: 2000
Pages: 115
Authors: Jake Sturm

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net