Three Tier Architectures - Improving Client/Server Performance
	By Steven Rabin Chief Technologist, American Software, Inc.

The saying, "Watch out or you just might get what you wish for" must have first been uttered by a client/server development manager. After convincing management that C/S is appropriate for the next generation of applications, the reality of developing and implementing these applications set in. In fact, when these applications are successful, the good news is also the bad news. Supporting increasing numbers of users and functions across computing platforms with additional transaction traffic, messages and concurrent access is not a simple scenario.

How do you take an application, departmental in nature and two-tier in architecture, and scale it up to the realities of this new environment? Tools that provided an excellent framework for the initial development effort may quickly lose their appeal once additional requirements are known. This includes support for heterogeneous environments (and not just the GUI), distributed data sources (and not just the RDBMS) and transaction monitoring facilities.

Because of this, the terms legacy system and legacy code are now being used to describe C/S applications. What was once solely the domain of tired mainframe systems has been inherited by the first generation of C/S as well. Lack of scalability, portability and a host of performance-related problems haunt the dreams of developers and users alike. "Porting mainframe systems to a client/server environment opens up a Pandora's box of issues," says Jeff Davis, a business systems consultant at Cadbury Beverages. "This includes changes in desktop operating systems, back-end services and performance problems due to concurrent access and transaction volumes."

Few doubt the basic role C/S computing is going to play in the development of business-critical applications. The issue is developing an architectural model tied to a new generation of distributed system services that are capable of fulfilling the promise of this environment. Development tools must also support this vision in a sophisticated and efficient manner. The days of using a visual tool only capable of supporting the client GUI-database server model are rapidly coming to an end.

As companies move to heterogeneous environments, applications must be able to be deployed across multiple operating environments. Although not an unreasonable request it is difficult to build and, perhaps even more important, maintain these systems. The inherent intricacies and complexities of supporting an application across multiple environments requires a new architectural model along with a new generation of tools designed explicitly for distributed environments.

The architectural demands of the software development environment are often dependent upon the size of the application being built and the services it requires. Small applications, less than 50 users and a single server, generally have simple demands while larger applications, more than 100 users and multiple servers, have much different and expanded requirements. The stresses placed on the system by a small application can usually be dealt with within the constraints of the applications design and associated tools/facilities. "Re-engineering the Supply Chain Planning systems at Cadbury involves integrating locations and people across the country," explains Jeff. "Locations and functions will be phased in over time, which means that it is critical to take into account the different platforms and operating environments that will be encountered. The days of dictating what gets run where and when and on what environment are long past. The application must meet the business model and provide services to accomplish the goals of the software."

These two-tier, first-generation applications can actually grow quite large if all that is required is the sharing of data. However, as applications grow in complexity, numbers of clients/servers and transactions-per-second requirements placed on the environment become something very different and not quite as easy to handle. Three-tier architectures, supporting object manipulation, solve many of the problems associated with developing high performance, robust, enterprise wide, client/server applications. This includes portability, shared services, distributed management, reliability, open integration and performance. One of the first tasks is to understand the fundamental requirements of the application in order to match the services that best support them.

For example are the services of the RDBMS enough or should an OLTP be considered? Because they are designed to process information quickly and safely (data integrity/fault tolerance), OLTP monitors are a good choice for high-volume applications that demand reliability. While this isn't the MO of all applications it certainly fits the description of a manufacturing or customer order processing system. The added performance benefits OLTPs bring to the table make them a good choice for a variety of applications.

Relational database managers tend to slow down as the number of concurrent users increase. This is often caused by the RDBMS relying on the operating system to handle these multiple, concurrent users. The OLTP is designed to share back-end functions among may users including the processing of database requests (see figure 1). In this case the TP monitor acts as a resource mediating middle tier between the client and the database.

Figure 1

In addition to the use of the RDBMS and/or OLTP, three-tier architectures provide the means for supporting two very important performance-oriented facilities. The first is load balancing or partitioning and the second is environment independence through shared services. Partitioning allows an application to be both portable and scalable by not locking specific application elements to pre-defined environments; thereby reducing network traffic. Shared services allows a single copy of a service (eg. credit check) to be accessed by multiple users and/or applications; increasing performance, control and maintainability. Shareable application services and partitioning require a messaging framework for communicating requests and results across the distributed landscape.

Many of the most serious limitations of tactical C/S development become apparent only when an organization attempts to tackle enterprise issues within the existing development framework and toolset(s). The ability to add middle layers to the computing hierarchy can substantially increase C/S performance. For example, a growing user base can introduce performance bottlenecks that were not foreseen in the original design or implementation. The need to expand application functionality also calls for additional computing devices and services to be considered. Some of these services may be remote and not system oriented; a real-time financial data feed.

Performance must also be considered from the business modeling point of view. Being able to develop and then distribute shared business services simplifies the development of complex applications by breaking them into manageable components. This speeds the development of new applications through component reuse while facilitating application maintenance by allowing small, individual components to be changed while leaving others intact. From the execution point of view it is possible to implement a single copy of a service that can support multiple applications (eg. all applications requiring the latest inventory status information) that is independent of the desktop and RDBMS.

The three-tier approach allows applications to be designed with the middle tier supporting a variety of middleware services. This includes data access to heterogeneous databases, gateways to remote mainframe systems, resource managers via TP monitors and a host of communication and object brokering services. A new breed of products and services, supported by both existing and emerging protocols (eg. ODBC, DRDA, OLE, OLE2, DCE, COM, SOM, DSOM, CORBA) are being developed to provide solutions across this middle tier. These products make it easier to develop and deploy applications across disparate environments and in many cases specifically tackle the performance issues associated with that..

"The ability to build application servers instead of running all of the code on the client provides a flexible model that better represents the way our business is run," describes Jim Laurie, a senior manager of IS Services at Western Digital. "Partitioning allows for applications of greater complexity to be built without concern for how they are to be distributed across the network." Rigid definitions of the roles of clients and servers often don't allow for flexible solutions. Many two-tier client/server tools have a preconceived notion of what is allowed on the client versus the server. This is counterproductive and often different from what the business solution requires.

Before running down to your local store and buying a development tool supporting three-tier architectures let's look at some design issues. In order to satisfy the requirements of portability and environment independence an application must be defined without thought given to where components will be deployed. In other words, developers must build a logical representation of the application independent of the physical environment. Today's Novell server may be tomorrow's NT server. The front-end running under Windows may also need to support users in another location dedicated to the MAC or Warp or Win 95 or....

A survey of the increasingly difficult demands placed on applications built with client/server technology is revealing. First, the applications must be easy to develop, easy to distribute to the people who need them and easy to maintain/enhance while in use. The applications must be able to support not only departmental, but enterprise-wide, mission-critical solutions across an increasingly complex and heterogeneous development and deployment environment. Since new applications must live with existing legacy systems, they must be able to access legacy data. Finally, the developed application must fit the business model; the business model should not require modification to fit the application or toolset.

Many of the problems associated with application scalability and application independence are linked with portability. Networks are not fixed entities and must adjust to changing requirements as well as technological and desktop changes. This has led to a proliferation of protocols and operating systems as companies balance the matching of platforms to specific functions, with an eye toward protecting investment through legacy system integration. C/S applications must be developed to execute on different platforms with the code accordingly compiled. The manual division and deployment of this code is a huge problem from both the development, deployment and ongoing maintenance points of view.

"A three-tier tool that utilizes distributed object technologies greatly facilitates this," says Jeff Davis. "Developers need to be able to build classes of objects (both business and computing objects), store them in a repository and then determine how those objects should be deployed across the enterprise." The method/messaging structure of object technology is the basis of this decoupled development where functionality development and system deployment (partitioning) are isolated. The best tools allow the application to be written as a series of objects on a single platform or assembled from modules produced by developers on separate platforms. Independently, descriptions of target platforms are defined and stored in a repository. Application deployment occurs by assigning these objects (eg. business events, GUI desktops, interfaces to services) to their logically appropriate platform, see figure 2.

Figure 2

The advanced application development environment developed by FORTE Software is one of several next-generation tools that provide a sophisticated environment for the development and deployment of three-tier applications. The application development schema of this product supports features common to many C/S tools and a variety of features that make this product stand out. The common features include a GUI designer, 4GL language editor, repository browser and debugger. Interfacing to third-party tools/services is accomplished through open APIs.

What makes this tool really interesting is the way the logical application objects are stored in a repository along with the platforms to be supported. This layer of portability abstraction allows the key components of the application to be defined outside of the physical implementation. This includes the display, database, network, TP services, middleware and other application service components. Configuring and re-configuring a system is then a matter of utilizing a graphical drop and drag module to place application components in the environment best suited to support them. Generation of high-performance C++ code, multi-threading, concurrency and access to shareable services are automatically taken care of.

Mark Joyce, Fiber System's Engineer Supervisor with Corning says, "Forte's support of OLE, DCE, CORBA and other open standards provides the flexibility to build components or purchase the best components available on the market. The three-tier architecture is the direction of the future; distributed computing over heterogeneous nodes via object brokers and/or DCE for component-based systems." The issue of openness is important because today's computing environment is a mixture of different technologies and standards. Tools that successfully hide the complexities of layered environments allow developers to build applications that can run across a variety of hardware and software without changing the application. This "plug and play" architecture needs to include different hardware designs, operating systems, networks, GUIs, database managers, TP monitors and other services. Equally important are full-functioned APIs, conformance to recognized standards and native support to ensure the best performance possible.

The architectural and performance limitations found in the first generation of client/server applications is giving way to new ideas and approaches. The utilization of middle tiers, possibly representing multiple servers and services, and the separation of the logical design of an application from its physical environment are perhaps the most striking features of this new generation of C/S thinking and tools. As more and more mission-critical applications are shifted to client/server environments, network and development managers will necessarily look to these new approaches to help solve the problems associated with deploying applications across heterogeneous environments and associated performance related distributed solutions. As it turns out, getting what you wish for might not be so bad after all and the promise of client/server may finally be realized.

Steve Rabin is featured at DCI's Software World & Client/Server World.