Two tier client/server architectures have been built and fielded since the middle to late 1980s. The design is well known and used throughout industry. Two tier architecture development was enhanced by fourth generation languages.
Scalability. The two tier design will scale-up to service 100
users on a network. It appears that beyond this number of users, the
performance capacity is exceeded. This is because the client and server
exchange "keep alive" messages continuously, even when no work is being done,
thereby saturating the network
[Schussel 96].
Implementing business logic in stored procedures can limit scalability because as more application logic is moved to the database management server, the need for processing power grows. Each client uses the server to execute some part of its application code, and this will ultimately reduce the number of users that can be accommodated.
Interoperability. The two tier architecture limits interoperability by using stored procedures to implement complex processing logic (such as managing distributed database integrity) because stored procedures are normally implemented using a commercial database management system's proprietary language. This means that to change or interoperate with more than one type of database management system, applications may need to be rewritten. Moreover, database management system's proprietary languages are generally not as capable as standard programming languages in that they do not provide a robust programming environment with testing and debugging, version control, and library management capabilities.
System administration and configuration. Two tier architectures can be difficult to administer and maintain because when applications reside on the client, every upgrade must be delivered, installed, and tested on each client. The typical lack of uniformity in the client configurations and lack of control over subsequent configuration changes increase administrative workload.
Batch jobs. The two tiered architecture is not effective
running batch programs. The client is typically tied up until the batch job
finishes, even if the job executes on the server; thus, the batch job and
client users are negatively affected
[Edelstein 94].
Developing a two tier client/server architecture following an object-oriented
methodology would be dependent on the CORBA standards for design
implementation. See Common Object Request Broker Architecture.
Possible alternatives for two tier client server architectures are
When preparing a two tier architecture for possible migration to an
alternative three tier architecture, the following five steps will make the
transition less costly and of lower risk
[Dickman 95]:
- Eliminate application diversity by ensuring a common, cross-hardware library and development tools.
- Develop smaller, more comparable service elements, and allow access through clearly-defined interfaces.
- Use an Interface Definition Language (IDL) to model service interfaces and build applications using header files generated when compiled.
- Place service elements into separate directories or files in the source code.
- Increase flexibility in distributed functionality by inserting service elements into Dynamic Linked Libraries (DLLs) so that they do not need to be complied into programs.
