The use of the term '3-Tier architecture' can sometimes be confusing as it may mean different things to different people. In my long years of experience I have come across two different meanings - one hardware oriented (physical), the other software oriented (logical). Perhaps the next time you get into a discussion with someone on this topic it may help to check that you are both talking about the same view.
When viewed from the hardware perspective the 3-Tier architecture consists of 3 device layers, as shown in Figure 1:
Figure 1 - 3 Tier Architecture (hardware view)
In this configuration all Forms (.FRM files) are executed on the Client, while all Services (.SVC) and Reports (.RPT) are executed on the Application Server. It should be noted here that Services and Reports can be executed on an Application Server because they do not have any dialog with the user. It is also advisable that they be compiled as 'self-contained' components in order to avoid any problems with global objects. To quote from the Uniface documentation:
A component running remotely executes in the environment of its Application Server. This means that it accesses the DOL or UOBJ.TEXT located in the installation directory for that Application Server. This does not necessarily contain the same global objects available to the client application. When a service or report that is not self-contained runs in the Application Server environment, the difference in global objects can lead to problems that are difficult to detect.
In order for this configuration to work the Application Server requires special software (also known as Application Server or ASV). This communicates with the Client through a Message Daemon. Synchronous communication provides a separate instance of the ASV for each Client, while Asynchronous communication allows a single ASV to communicate with multiple Clients.
The advantage of this configuration is that the service and report components execute at the speed of the Server device, not the Client. The network traffic between the Client and the Application Server may also be a lot less than the network traffic between the Application Server and the Database Server.
I have also come across a configuration which has a File Server instead of an Application Server, as shown in Figure 2, but this is not a true 3-Tier configuration.
Figure 2 - with File Server instead of Application Server
The advantage of this configuration is that when components need to be updated the updates need only be applied to the File Server instead of all the Client devices.
The disadvantage is that when a component needs to be accessed by a Client device it needs to be copied from the File Server into the Client's memory before it can be executed.
Software is comprised of code that can be broken down into 3 distinct areas:
This is described in an earlier article entitled UNIFACE and the N-Tier Architecture.
Where all this code is contained within a single component you have what is known as a 1-Tier system.
When utilising UNIFACE with a database driver all the data access logic is contained within the database driver, therefore this is known as a 2-Tier system. It is possible to change one database driver for another without having to make any changes to any application code.
If the Presentation Logic and Business Logic are split off into separate components you end up with a 3-Tier system, as shown in Figure 3.
Figure 3 - 3 Tier Architecture (software view)
One of the advantages of this 3-Tier system is that all business logic is centralised in one layer. A component in the Business Layer can be accessed by any number of components in the Presentation Layer, therefore any changes to business logic can be made in one place and be automatically inherited by all other components without having to duplicate the change in those other components.
Note that the Presentation Layer components do not access the database - all data is provided by the Business Layer in the form of XML streams. Any changes made in the Presentation Layer need to be passed back to the Business Layer before they can be applied to the database.
xmlsave- transfer data from the component's structure into an XML stream.
xmlload- transfer data from an XML stream into the component's structure.
retrieve/reconnect- reconnect any occurrences created by
xmlloadwith the database to determine whether these occurrences are updates or additions.
More details on this are contained in an earlier article entitled 3 Tiers, 2 Models, and XML Streams which also comes with some sample code. Note that this software also demonstrates the use of two different application models - one for the Presentation Layer and one for the Business Layer. This provides a much greater degree of flexibility than the single model approach.
The use of XML streams in this way utilises what are known as 'disconnected record sets' as the occurrences within the Presentation Layer components are not connected to the database. Although this is not essential in a Client/Server application it does not prevent their use. However, disconnected record sets are important with Web applications as the Web is entirely stateless. This method means that the Business layer components can be used by a Presentation Layer which can be either Client/Server or Web (or even both at the same time).
The simple answer is No. It is possible to have all types of component (forms, services and reports) stored and executed on the Client device. Indeed, this is how I built and tested my sample software.
However, as this architecture has all its business logic contained within service components it is an ideal candidate for being deployed on 3 layers of hardware.
24th April, 2002