8. Reference Architecture

(This page uses style sheets.)

8.1. Generic architectures

One useful way of describing a computer architecture is in terms of the so-called 3-tier model. This model separates out three gross functions that an application performs in general when being used by a human (i.e. it is not a pure server or batch application). These are shown in the following diagram. (http://www.corba.ch/e/3tier.html/ has more details.)

The arrows indicate information being passed between the three parts. These flows should ideally use open and well defined standards. Doing so means that any application only has to worry about performing its business logic leaving the other two functions to standard components. This has the benefit that application code can be simpler and can be more easily run in different environments because its dependence on machine specific access is reduced.

This 3-tier model has been generalised to n-tier, where the components are even further refined, and is typically realised used object or component technology.

Many client-server applications have in the past unfortunately only used a 2-tier model where the application code and the human interface are merged together. This means that migrating such applications is often considerably more difficult than with 3-tier ones. This is because the human interface is likely to require change and the 2-tier application will most likely have human interface code intermixed with business logic throughout.

The communication between the three parts of a 3-tier application normally uses protocols which allow each part, if required, to run on a different machine from the other two. Sometimes the parts can also be split across machines. The choice of location of each of these parts gives rise to various generic architectures.

The extremes from the point of view of the desktop, where at least some portion of the human interface code must be running, are:

1. Ultra thin client

This is where the desktop has only human interface code. Typically it has no local long term memory such as hard or floppy disks. The application code and data access are both run remotely. Examples would be an X terminal, a VT100 green screen and a device with an embedded browser.

2. Ultra fat client

This is where all the code and data is held on the desktop with no network connectivity.

Terms such as thin and fat client mean a desktop which lies in the spectrum between these two extremes.

A variant on these architectures is one in which application code is stored on a server and then downloaded to the desktop to be run when needed. This is the way, for instance, in which Java applets work. Another method involves storing the application code on a server and having the desktop access it as though it were stored locally. This requires the use of a networked file system such as NFS and also means that all the desktops must be of the same processor architecture.

The choice of architecture for any particular application will depend upon:

1. The network bandwidth to the servers and what that bandwidth will have to carry. If the desktop is not ultra fat then the network will have to carry either human interface controls, data or downloaded application code. In some circumstances the size of these loads generated by either a single desktop or a number of them in aggregate may be too great for the capacity of the network.

2. The latency that is acceptable in the use of the application. When a human interacts with the desktop by depressing keys or moving the mouse the time taken for the application to react and draw the effect on the screen is known as latency. For some applications such as simple data entry high latencies may be acceptable but for highly interactive applications such as drawing, latencies must be low. Latency will depend on the capacity of any network segments between the human interface and the application, and on the capacity of the machine running the application code. To achieve the lowest latencies, therefore, the application should be run on the same machine as the human interface, and this machine should be powerful enough to run the application properly.

3. The security policy in place. If data resides on desktop machines distributed throughout the Administration, this means that if any machine is stolen or is accessible in an insecure environment then data can be lost or divulged to third parties or unauthorised staff. This may not be a problem with low grade data which has been properly backed up, but otherwise it could contravene the security policy of the Administration concerning who can access data. Alternatively having data transmitted over a network unencrypted could cause the same problem.

4. The backup policy in place. If data resides on desktop machines distributed throughout the Administration then either some centralised backup mechanism is needed or the responsibility for backup has to be distributed among many people, probably the users themselves. A centralised backup scheme would be complex and would require high network bandwidth and co-operation with the desktop users (who, for instance, must remember not to switch off their machine during periods when backups are scheduled).

5. The design of the application. If the application has human interface code included then it either needs to run on the desktop or on a server with the human interface code split between the server and the desktop. For instance, an IBM 3270 or DEC VT100 terminal has all the display code in the desktop, as does a browser-based terminal. Citrix, Windows Terminal Server and the X Window System all split the display code between the server and the client.

6. The capacity of the desktop machine to run the code. The more the desktop machine has to do, the more powerful (and thus expensive) it has to be.

7. The capacity of the desktop to store the data. Some applications need access to huge data stores which can only be held on specialised servers.

8. The performance of the servers available. If the application is run on a server rather than the desktop then the server has to be sufficiently powerful to run all the instances of the application required when the maximum number of desktops are in use. This could mean that the servers have to be vastly over specified to handle the worst case conditions. In addition, the number of desktops which can be supported by a given number of servers tends to have discrete “jumps” in it. This means that the addition of a few extra desktops could mean the purchase of an extra-large server.

9. The total cost of implementation.

As with any engineering problem there is no solution applicable to all situations and a particular physical desktop may operate in one way for one application and in another for a different application.

8.2. Base Reference Architecture

The Base Reference Architecture (BRA) used in these guidelines is chosen to be relevant in the majority of situations. It can be extended to be thinner or fatter for specific applications as necessary.

In reality the architecture used by an Administration is likely to be a combination of various architectures each chosen for specific applications.

The BRA can be characterised as a “stateless desktop” in that:

1. All applications run on the desktop whenever possible and are stored on the desktop.

2. No persistent data is held on the desktop.

3. All authentication and authorisation is controlled by central servers.

4. System management is centralised.

5. The objective is that desktops are “plug and play” and require no local support.

The applications run locally to ease any latency problems of running them centrally and the BRA assumes that there is sufficient bandwidth for the data to be held centrally. In addition it assumes that all desktops will be essentially identical, allowing anyone to log on to any machine that they have permission to use. There must be a strong systems management regime in place to keep the desktops' software installations in unison.

The BRA has central configuration and management which will simplify system administration, concentrating all important data on central servers for easy backup and management, and making individual client machines disposable, thus reducing the impact of the failure of such a machine.

Keeping the data locally means that there is an identification of machine with user. This causes problems when the user changes location or leaves the organisation. It also makes the location of the desktop user-specific, which makes concepts such as hot-desking difficult. Holding all data centrally removes these difficulties and makes the use of the desktop much more flexible. It also allows the size of the desktop's local storage to be kept to a minimum.

Making the desktop a plug and play device eases installation and therefore reduces the cost of supporting them.

Many Administrations will already be using a variant on such an architecture for all the reasons given and so the BRA is felt to be a reasonable choice.

The BRA is not appropriate for laptops or for desktops which are not permanently connected to the Administration's network. Such devices would either have to be very fat or have some sort of distributed file system which supports disconnected operation. Such OSS distributed file systems do exist, such as CODA, OpenAFS and InterMezzo, but they have not been tested by netproject.