In an N-tier architecture, data access will usually occur through some form of middle tier (Figure 11-8). This allows applications not to know the location of their data sources. By introducing this principle into an architecture, one can restructure databases by changing schemas on the fly on backup sources using promotion/demotion schemes without the application knowing this occurred. For disaster recovery and high-availability situations, the underlying data source can be offline and restarted in another location, also without affecting the application. Furthermore, one can use this strategy for replatforming data sources, such as moving from Oracle on Solaris to Microsoft SQL Server on Windows 2000. Figure 11-8. Separation of tiers.For example, a client should never send SQL requests directly to a database. It is preferable that a client send requests to services that handle processing. The service will receive the request from a client and send a message to the middle tier. The middle tier in turn will send an SQL call to the database. This approach means the client does not need to know data-specific language constructs, whether SQL, XML, or proprietary. The client is simply responsible for sending a request for work.
|