More significant applications may take advantage of a database server and access persistent data by sending SQL commands to a database server to save and retrieve data. In this case, the database runs as a separate process from the application, or even on a different machine than the machine that runs the rest of the program. As illustrated in Figure 1-2, the components for data access are segregated from the rest of the application logic. The rationale for this approach is to centralize data to allow multiple users to simultaneously work with a common database, and to provide the ability for a central database server to share some of the load associated with running the application. This architecture is usually referred to as client/server and includes any architecture where a client communicates with a server, whether that server provides data access or some other service.
It’s convenient and more meaningful to conceptualize the division of the responsibility into layers, or tiers. Figure 1-3 shows the client/server software architecture in two tiers.
One of the disadvantages of two-tier architecture is that the logic that manipulates the data and applies specific application rules concerning the data is lumped into the application itself. This poses a problem when multiple applications use a shared database. Consider, for example, a database that contains customer information that is used for order fulfillment, invoicing, promotions, and general customer resource management. Each one of those applications would need to be built with all of the logic and rules to manipulate and access customer data. For example, there might be a standard policy within a company that any customer whose account is more than 90 days overdue will be subject to a credit hold. It seems simple enough to build that rule into every application that’s accessing customer data, but when the policy changes to reflect a credit hold at 60 days, updating each application becomes a real mess.
One of the disadvantages of two-tier architecture is that the logic that manipulates the data and applies specific application rules concerning the data is lumped into the application itself. This poses a problem when multiple applications use a shared database. Consider, for example, a database that contains customer information that is used for order fulfillment, invoicing, promotions, and general customer resource management. Each one of those applications would need to be built with all of the logic and rules to manipulate and access customer data. For example, there might be a standard policy within a company that any customer whose account is more than 90 days overdue will be subject to a credit hold. It seems simple enough to build that rule into every application that’s accessing customer data, but when the policy changes to reflect a credit hold at 60 days, updating each application becomes a real mess.
You might be tempted to try to solve this problem by building a reusable library that encapsulates the business rules. When the rules change, you can just replace that library, rebuild the application, and redistribute it to the computers running the application. There are some fundamental problems with that strategy, however. First, that strategy assumes that all of the applications have been created using the same programming language, run on the same platform, or at least have some strategy for gluing the library to the application. Next, the applications may need to be recompiled or reassembled with the new library. Moreover, even if the library is a drop-in replacement without requiring recompiling, it’s still going to be a royal pain to make sure that each installation of the application has the right library installed simultaneously (it wouldn’t do to have conflicting business rules being enforced by different applications at the same time).
In order to get out of that mess, the logical thing to do is to physically separate those business rules out from the computers running the applications onto a separate server so that the software that runs the business rules needs to be updated only once, not for each computer that runs the application.
In order to get out of that mess, the logical thing to do is to physically separate those business rules out from the computers running the applications onto a separate server so that the software that runs the business rules needs to be updated only once, not for each computer that runs the application.
No comments:
Post a Comment