Tier Strategy
Many options are available to a project team that wants the best and most flexible design strategy. At a minimum, any application built today that is intended to be around longer than a year or two without experiencing a major reworking must implement a minimum of three logical tiers. This minimum is specified because the traditional three-tier model needs further categorizing, for the following reasons:
The Business Services layer actually consists of two types of services: Business Context and Business Rule. The first type deals with the user interface as it pertains to filtering and cleansing information as it enters the system; for example, a value entered in one field limits the allowable values entered in another field. The other service deals with the more traditional business rules; for example, a Remulak Productions' customer that places over $10,000 in orders in a given year receives 10 percent off of the next purchase.
The Data Services layer actually consists of three types of services: Data Translation, Data Access, and Database. The first deals with translating a logical request for information services (e.g., select, update, and/or delete) into a language that is compatible for the data repository, such as SQL. The second service deals with the execution of the request by an API, such as a JDBC driver. The third service is the actual database technology (Oracle, Microsoft SQL Server, or the like).
Figure 8-4 depicts the logical layers that could be used in any application—the six-logical-tier model—along with a description of the services provided at each layer.
Figure 8-4. Six-logical-tier model
The Presentation Services and Database Services layers require the least amount of attention (although we have to build screens and design tables, of course). The remaining four layers must be very sound and well built to hold up for the other layers. If we do the job right, we should easily be able later to replace the Presentation Services and Database Services layers with different presentation services (such as the Internet) and different database technology (such as Oracle, to replace Microsoft SQL Server).
Communication among the Six Layers
We need to determine the most appropriate mechanism to enable communication among the six layers. To do so, we should first ask the following questions:
What interprocess communication (IPC) technology should be used among the layers?
What mechanism should be utilized to communicate among the layers when the IPC is used?
These two questions are addressed in the next two subsections.
Interprocess Communication Architecture
The IPC mechanism can be handled by any of many different technology options, including native socket support within Java, Common Object Request Broker Architecture (CORBA) technology and its Internet Inter-ORB (object request broker) Protocol (IIOP), and Remote Method Invocation (RMI) and its Java Remote Method Protocol (JRMP). In some cases for a Web front end, the communications IPC is actually HyperText Transfer Protocol (HTTP).
Layer Communication Architecture
The second question deals with methods for communicating, from the application's perspective, among the layers. This communication method will use the IPC services (RMI/JRMP, HTTP, CORBA/IIOP). Several choices are available:
Pass individual attributes and objects, as needed, between each layer.
Pass String arrays and attributes between each layer.
Pass serialized versions of objects between each layer.
Pass XML (eXtensible Markup Language) streams between each layer.