Integrated Information Environment--A Technology Architecture for the Next Century

The University of Arizona is reengineering its major administrative systems. We envision a new environment where data is collected at the source and people have access to information when and where they need it.

Our vision requires integrating data from many different sources, expanding its accessibility, and building a secure technical foundation that is usable, reliable, extensible, portable, adaptable, and manageable. We selected an architecture that allows us to capitalize on our legacy systems and expertise in the transition to an integrated information systems environment based on world wide web technologies.

This paper describes our architectural selection process and presents issues requiring additional thought and resolution.

INTRODUCTION

Information Technology at the University of Arizona, Strategic Directions for the Year 2000 (1994), describes a 21st century electronic environment reaching everyone, any place and any time. It identifies information technology as an indispensable and strategic part of the University's Year 2000 directions.

A key component of this vision is establishing a University Networked Information Technology Environment (UNITE). UNITE includes recommendations, guidelines and standards for the technology environment needed by the institution to implement recommendations outlined in the Information Technology report.

This paper describes the technical design of an information and analysis systems that supports planning and decision making. The result is a distributed client/server architecture consistent with UNITE standards and the University vision.

DISTRIBUTED COMPUTING

Despite our historical reliance on large computers, the majority of the University's investment in technology is now in widely distributed desktop systems. This evolution toward a distributed computing paradigm allows individual units to improve their operation without delays that may occur when using external expertise. However, when technology is implemented in a piecemeal fashion, units can find themselves unable to accomplish work that crosses organizational boundaries.

A distributed computing environment is an integrated collection of computing systems frequently referred to as servers. As such, our administrative computing environment will have presentation servers (to display and accept data), application servers (to store program logic and business rules), data servers (which store and retrieve data), print servers (that produce output), etc.

Some servers lend themselves to being implemented and supported centrally. For example, one centrally maintained security server can authenticate user access to any of the component servers in the enterprise. It is not necessary to have multiple security checks with multiple procedures and passwords for each server.

Departmental implementation and support are more appropriate for other servers, such as a database used only by a single department. The departmental database, however, may need to obtain some of its data from a central database, so the ability to interact with other servers must be maintained.

THE CLIENT/SERVER MODEL

Background

Until the late 1980s, the typical University computer was a mainframe system connected to dumb terminals. They were called dumb terminals because they didn't do any processing or store any data. Users could do only what the mainframe programs allowed them to do. The arrival of the desktop computer upset this traditional paradigm. Individual users were able to run their own programs and create their own data files and documents. Sharing that data, however, was difficult. So in the late 1980s, the local-area network (LAN) emerged to provide connectivity between desktop systems.

Users got excited about sharing files and sending each other electronic mail, but sharing files over a LAN wasn't much different from the old mainframe model. We needed to rethink how to use this new technology. The result was client/server computing.

Most client/server successes involve small scale pilot applications generally of a non-critical nature. As we evolve from these pilot projects to mission-critical applications, there is a corresponding increase in performance expectations and uptime requirements. The architectural strategy, therefore, becomes a critical consideration. The choice of architecture affects development time and the future flexibility and maintenance of applications. If the design is flawed, implementation could result in horrendous response times. How these issues are being addressed at The University of Arizona is the subject of this paper.

Definition

Beyond the generalizations of client/server reflected in the Background above, there is much confusion about the definition of client/server computing. John Gallaugher and Suresh Ramanathan (1996), from Syracuse University, offer an excellent definition of client/server.

Client and server are software and not hardware entities. In its most fundamental form, client/server involves a software entity (client) making a specific request which is fulfilled by another software entity (server). Figure 1 illustrates the client/server exchange. The client process sends a request to the server. The server interprets the message and then attempts to fulfill the request. In order to fulfill the request, the server may have to refer to a knowledge source (database), process data (perform calculations), control a peripheral, or make an additional request of another server. In many architectures, a client can make requests of multiple servers and a server can service multiple clients.

Figure 1 - Client/Server Transactions

It is important to understand that the relationship between client and server is a command/control relationship. In any given exchange, the client initiates the request and the server responds accordingly. A server cannot initiate dialog with clients. Since the client and server are software entities they can be located on any appropriate hardware. A client process, for instance, could be resident on a network server hardware, and request data from a server process running on another server hardware or even on a PC. In another scenario, the client and server processes can be located on the same physical hardware box. In fact, in the prototyping stage, a developer may choose to have both the presentation client and the database server on the same PC hardware. The server can later be migrated (distributed) to a larger system for further pre-production testing after the bulk of the application logic and data structure development is complete.

The fundamental aim of client/server processing from the user perspective is to provide a single image of the total information systems enterprise. From the technical perspective, however, there are tremendous challenges created by the interaction of multiple clients, multiple servers, security concerns, file integrity considerations, backup and recovery, network protocol complications, and combinations of heterogeneous hardware and software components.

Architectural Components

In Client/Server architectures most end-user applications consist of three holistically related components: Presentation, Logic, and Data.

Presentation components for display, keyboard/device handling and data validation;
Logic components implementing applications specific business logic, policies and procedures;
Data access components for retrieving and updating stored information

Client-server architectures are classified by how systems are partitioned into logical components, and how the components are distributed among network computers. A system generally has one presentation component, but possibly several modular application components (programs), and several data components (e.g., files, databases). Client-server architecture presents several alternatives in distributing these components to computers best suited to each task. A framework, or consistent approach for the distribution of the components, constitutes a client-server architecture.

The architecture determines the amount of flexibility and control we have with the implementation of our applications, as well as how they are built and used. Although a virtually infinite number of possibilities exist for distributing and linking architectural components, most contemporary architectures are defined in terms of a limited subset of alternatives. The subset that seems to have gained most acceptance in implementing distributed transaction-orientated database systems are described in terms of architectural Tiers.

Two Tier Architecture

In Two Tier architecture, the Presentation, Logic, and Data are divided into two distinct units - the Client which executes on a users workstation, and a Database Server which executes on another node in the network. Two tier architecture works best in a homogeneous environment where all the database servers and the interactions with these servers are of the same type. In two tier implementations the presentation is handled exclusively by the client and data is stored on and accessed on the server. But the application or business Logic can reside on the client (fat client), or on the database server (thin client) in the form of stored procedures.

In either case, two-tier architectures are not appropriate for our central administrative applications. In our campus information environment the legacy applications are implemented on an IBM mainframe. In order to effectively transition our legacy applications to the new architecture, access to legacy information must be available for the new client/server applications. In a network environment, this access must include transactional integrity to preclude the possibility of data synchronization problems. As such a two tier architecture is problematic.

We estimate that in our environment, two-tier solutions will not scale well beyond approximately 100 clients. Since the campus could conceivably have 10,000 employee clients and 35,000 student clients, a two-tier architecture would not scale to meet the needs of the campus. We do recognize however, that some of our ancillary departmental processes are candidates for the simplicity of two-tier architecture. As such, we evaluate the pros and cons of fat clients and thin clients as enterprise candidates.

Two Tier - Fat Clients

In the fat client architecture, the presentation and logic component (application code) executes on each client platform. Data is retrieved and updated over the network to connected database servers. The primary benefit of placing the application on the client is ease of development. A large selection of easy-to-use tools that take advantage of standard APIs (ODBC and SQL) and protocols are available. In addition, most development tools support a wide selection of client platforms (Macintosh and Windows) with common source code. Application development is swift and easy.

As a unifying client-server architecture, the fat client is limited in both run-time execution and systems administration. Processing individual SQL statements overloads the network because messages and large amounts of data must be transmitted over the network. The network rapidly becomes a bottleneck as the number of clients increases. Administratively, the fat client becomes a management nightmare. Application logic is replicated on each client, application changes need to be distributed to each client, and tools supporting an automated update capability have not been identified.

Two Tier - Thin Clients

In the thin client architecture, the client process is involved with presentation. The database server manages the database, and the application component is defined, managed, and executed in the form of database stored procedures. Languages to develop stored procedures are immature and currently proprietary to the databases that implement them. Because stored procedures are not standardized across different database vendor implementations, using this model can lock you into a single database vendor.

Efficient resource utilization is another key issue. In transaction processing applications, database throughput becomes a performance bottleneck. When the number of clients increases, database resources are drained as the database allocates memory for each client process. With stored procedures, the database assumes additional application processing tasks that erodes its primary function of fast and efficient data access.

Three Tier Architecture

Three Tier architecture places the presentation, logic, and data components on their own (logical) servers and under the control of tools optimized for each distinct function. The application servers provide program calls to other application components in the same or other servers. These application components, in turn, provide access to non-proprietary database services.

The placement of business logic on the application server provides scalability and isolation of the business logic in order to handle any rapidly changing business needs. Another advantage of this approach is the ability it provides to off-load processor intensive tasks from the client workstation, thus allowing us to utilize thin clients (with lesser amounts of memory and processor power). This advantage in scalability must be weighed against the greater cost and complexity of creating a three thier solution.

One of our critical requirements was to accommodate applications that use data stored in heterogeneous databases. The integration of application and database server integrity is facilitated by an application management environment, know as a Transaction Processing (TP) Monitor. After researching the pros and cons of two and three tier issues, a three-tier client/server architecture was chosen to best suit the needs of our mission-critical applications. As stated above, however, this architecture doesn't preclude the concurrent use of the two-tier model.

INFRASTRUCTURE COMPONENTS

Figure 2 - Schematic View of the Infrastructure

World Wide Web Technologies

Web-based technologies offer some tangible solutions both short-term and long-term. Industry standard web browsers utilizing Java and JavaScript can support robust application development to include methods for incorporating multi-media capabilities such as sound, pictures, or movies into applications.

Another area that can benefit from web-based technologies is data reporting. Report distribution via web-based technologies will decrease costs associated with paper or fiche archiving. In addition, warehouse data can be made available for direct download into client spreadsheet applications without the need for client knowledge of complex SQL syntax. It is possible to deliver decision support data to large numbers of clients without a substantial increase in training on data extraction methods.

The biggest advantage the web technologies offer is lower support costs. Since the application presentation logic is downloaded on request to the browser, the resources and infrastructure needed to support software version control, software distribution, and software configuration are greatly reduced. Institutions can begin to offer web-based applications with current technology and evolve them to take advantage of newer browser and web server technologies as they become available without substantial changes to the client environment.

Use of the SSL security standard for web browsers, makes end-to-end encryption of sensitive data such as credit card transactions achievable. SSL also help organizations achieve the goal of a single identification for user authentication when used in combination with gateway servers.

ODBC - Open DataBase Connectivity

For access from the client, there are two emerging standards, the Web and Microsoft's ODBC (Open DataBase Connectivity). In the ODBC model, a middleware layer from Open Horizon was chosen which allows ODBC to be tunneled over DCE. This approach enables a network, single-login to DCE and encrypts sensitive data as it is transmitted over the network. This middleware, Connection/Client, also enables the utilization of a single ODBC interface to access both the business logic on the application server(s) (three-tier), and the data on the database server(s) (two-tier).

DCE - Distributed Computing Environment

For the distributed computing infrastructure, the Open Software Foundation's Distributed Computing Environment was chosen. One of the overriding reasons DCE was chosen is to provide users a single user account. We have some employees today with eight user IDs and passwords. With DCE, we would give clients a network ID and a network password. DCE also provides, like the web SSL standard, the ability to encrypt data transmitted across the network and to make resources location transparent. DCE is composed of the following major components: Remote Procedure Call, Directory Service, Time Service, Security Service, and Threads Service.

Transaction Processing

Transaction Processing (TP) monitors are software systems that provide a family of products for building, operating, and maintaining online transaction processing (OLTP) applications. In distributed environments, client-server TP monitors evolved to manage systems performance and data integrity in on-line applications. TP monitors, for example, support network-scalability and dynamic load balancing of requests. It is possible to integrate heterogeneous application server platforms and to balance fluctuating loads across these servers.

A critical issue is the need for an integrated way to retrieve our data and to maintain its integrity. TP monitors provide us the guarantee that all databases get updated or that they all get rolled back in the case of failures. This includes network transactional integrity between legacy applications on our mainframe and distributed, relational, database systems as long as the database vendor supports the X/Open XA interface standard for resource managers.

TP monitors also provide a distributed transaction system layered on the services of DCE. Failed servers are automatically detected and rerouting requests to other available servers occur while recovering and restarting the failed services. The application logic can be coded in either COBOL, C, or C++. By utilizing COBOL, our existing COBOL application programmer experience can be utilized without an initial training investment in C.

SUMMARY

The n-tier solution

The architectural components we've chosen are described as being both three-tier and two-tier client/server capable. In reality, this architecture supports the notion of a n-tier model. In the n-tier model, a departmental client could initiate some departmental business logic on the departmental application server(s) which, as part of a network transaction, could update the departmental database(s) and then initiate institutional business logic on the institutional application server(s). These institutional application server(s) could then update the institutional database(s). All of this takes place under the umbrella of a network transaction.

Any one of the chain of application server(s) could initiate a rollback which would cascade to all of the application server(s) involved. This capability allows a delegated approach to how business rules are implemented. As the business processes are identified and appropriate business logic is implemented on the application server(s), these services could then be institutionally advertised. This allows end-users to develop their own presentation interfaces to the business logic, but force them to abide by the business logic residing on the application server(s).

Issues to be Resolved

Network management

The ability to plan for the growth and troubleshoot network problems is an important part of any network application if the organization desires to be proactive rather than reactive.

Web server scalability

The Common Gateway Interface (CGI) is the most common method of providing dynamic document content in the web today. This method does not scale adequately when trying to deal with thousands of requests. Alternative methods are emerging that need to be researched for addressing this problem.

Web server integration with Encina

All of the web servers available today do not provide an interface to the Encina transaction monitor. An interface will have to be developed that is scaleable and robust.

Web development environments

A number of tools are beginning to appear to make the development of web-based applications much easier. Research will have to be done to determine which product best fulfills our requirements.

Java stability and security

The Java user interface environments built into the existing web browsers has not yet reached a point for use as a robust application development environment. In addition, the downloading of malicious Java applets is still an issue that will hopefully be addressed as standards are developed that support digitally-signed Java applets.

Other Integrated Architecture Sites
Indiana Stanford Pennsylvania Wisconsin-Madison UCDavis North Carolina at Chapel Hill North Carolina State Illinois at Urbana-Champaign California at San Diego UCLA	Memorial (Canada) Oberlin College CAUSE "Why Adopt DCE?" State of Connecticut Michigan1 Michigan2 Ohio State Wisconsin Penn State Oklahoma State

REFERENCES

Gallaugher, John and Ramanathan, Suresh. (1996). The Critical Choice of Client Server Architecture: A comparison of Two and Three Tier Systems. http://web.syr.edu/~jmgallau/cccsa.html, Syracuse University.

Gallaugher, John and Ramanathan, Suresh. (1996). Comparing Coding, Testing, and Migration Costs for Two and Three Tier Client/Server Architectures, http://web.syr.edu/~jmgallau/ais_paper.html, Syracuse University.

SIS2000 Project Team. (1995). Student Information Systems 2000 Homepage, http://www.arizona.edu/SIS2000/SIS2000.html, The University of Arizona.

Tristram, Claire. (1996). Middleware Makes C/S Apps Really Work, http://www.datamation.com/PlugIn/issues/1996/aug/08soft2.html , Datamation, August 8, 1996.

UA Information Planning Team. (1994). Information Technology At The University Of Arizona. Strategic Directions For The Year 2000, http://daps.arizona.edu/daps/pubrec/reports/splan/infoplan.html, The University of Arizona, 1994.

UNITE Project Team. (1994). U.N.I.T.E. - University Networked Information Technology Environment, http://w3.arizona.edu/~unite/unite/unite.html , The University of Arizona.

Prepared by:

John Detloff [email protected]

Dick Ecelbarger [email protected]

Keith Wilburn [email protected]

CAUSE 1996