This paper was presented at CUMREC '99, The College and University Information Services Conference. It is the intellectual property of the author(s). Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and that the title and authors of the paper appear on the copies. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the authors.

Transforming Host and Client/Server Applications to the Internet
"Internet Development of the Future Here Today"

Jason Popillion, Systems Analyst II

Wayne Ostendorf, Director, ADP Center

Iowa State University

The Iowa State University (ISU) Administrative Data Processing (ADP) Center provides computer services and support to most departments at Iowa State. Two of these departments are the ISU Alumni Association and the ISU Foundation. For these departments the ADP Center has successfully implemented a Graphical User Interface (GUI) Internet Alumni system, which supplements an existing powerful client server application. This application retrieves data from an external database and dynamically displays the inquired information back to the requesting client. Some developmental highlights of this application include: extremely production and service oriented, runs on a wide range of browser types (Netscape 2.0 through the latest version of Netscape and Internet Explorer 3.0 through the latest version of Internet Explorer), accommodates various client screen resolution settings, allows access to information regardless of client operating system, provides integrated application security as well as internet security, provides integrated client base analysis, and executes 95% of all code on the web server. The clients who use the application are generally impressed with the user-friendly interface, as well as the response time in retrieving data from the external database over the internet. It is our feeling that the success of this application proves the ability to develop robust database driven applications over the internet making client needs of the future available today.

Transforming Host and Client/Server Applications to the Internet
"Internet Development of the Future Here Today"

History

In the mid 1980s the Administrative Data Processing (ADP) Center created a series of on-line interactive applications for the ISU Foundation and Alumni Association. These systems consisted of the Master system to keep track of all Iowa State Alumni, the Pledge and Gift system to track contributions made to ISU, the Membership system to track members of the Alumni Association, the Scholarship system to track awarded and disbursed scholarships, the Prospects system to track major donor prospects, and the General Ledger system to process the accounting of all contributions. These systems were rich in functionality, worked very well and some of them are still in place today.

In the early 1990s technology brought to the forefront the ability to create Graphical User Interface (GUI) applications with connections to external databases through Open Database Connectivity (ODBC) and Transmission Control Protocol / Internet Protocol (TCP/IP). This technology appealed to the ISU Foundation and thus the SUMMIT project was launched. In the fall of 1994 we began investigating tools and methods to use in converting our host Alumni Systems to a GUI application running on an IBM RS6000. In the summer of 1995 development of the new GUI application, titled SUMMIT, was started. Shortly after development started we realized that because all the Alumni systems were so closely related to each other, and because we have other University users who would not have the required computer resources or operating system, we would need to maintain a display-only version of the on-line interactive host system. The solution created for this dilemma involved replicating the current day's processed data from the RS6000 platform to the Host on a nightly basis. We set up a replication process and in June of 1996 we implemented the SUMMIT version of the Master system which was followed by a March 1997 implementation of the SUMMIT version of the Pledge and Gift system. The SUMMIT versions were renamed Constituents and Contributions respectively.

With the replication process in place and the first two systems implemented we were finally able to focus our development on converting batch jobs from the Host to the RS6000 for the Constituents and Contributions systems. Through this process we realized that the replication process we implemented had become more of a hindrance than a solution. It worked but it logged changes created by both the relational database and the replication process itself, requiring so much disk space that it limited the amount of data we could manipulate in an overnight batch program. We knew that with a growing demand of processing batch jobs overnight and the amount of data that these jobs would manipulate, we had to find a way to eliminate the replication process and still deliver display-only access of the data to university clients. In the fall of 1997 we began investigating the ability to provide display-only access of the data on the RS6000 to clients through the use of a web browser. After three months of research and testing we designed an application framework which would be able to deliver dynamic HTML to a requesting client browser via an internet application using Active Server Pages, a Windows NT operating system, Internet Information Server as a web service, and Microsoft's Visual Interdev as a development platform. We started development in January of 1998 and eight months later successfully implemented the SUMMITWEB Constituents, Contributions, and Security systems.

Design

The success of this application was the result of a solid application framework design. Before we started the research or design of the application a set of guidelines were established which we felt would be necessary in displaying secured data to university clients over the Internet. The guidelines were:

These five guidelines were strictly adhered to not only in coding the application but also in testing it. In fact, if a page didn't meet these goals, we completely reengineered the page so it would. This sometimes meant fine tuning the application framework to support these changes and to keep the flow of the code the same across all pages of the application. By making the coding structure the same across all pages, development time was increased dramatically. On the average we could produce 2-3 new, tested pages a day. At this rate we developed all 132 pages of the SUMMITWEB Constituents system with two people in 1 1/2 months. Learning from the development of the SUMMITWEB Constituents system we were able to add enhancements to the framework and complete all 148 pages of the SUMMITWEB Contributions system in the same amount of time. With prior development of the SUMMITWEB Security system only taking 1 month we were able to devote 2 1/2 months to testing the application and training clients on using it. Figure 1 outlines the basic framework design.

Figure 1: Application Framework

Integrated Application Security

The SUMMITWEB application's appeal is enhanced through the integrated application security provided with the application. This security applies four levels of security to the application. The four levels include:

Profile or group level security allows a system administrator to create groups or profiles with specific settings. These settings could allow access to only one SUMMITWEB system or to multiple SUMMITWEB systems. They could also control access to certain buttons or functions within a system. User level security allows a system administrator the ability to add new users, add a user to a profile or group, activate or inactivate a user's account, and monitor the last time a user signed into the system. This level of security restricts individuals without a valid user account from using the system. Window and field level security consists of enabling or disabling a data field on a certain window. By using this feature a disabled field will not be dynamically displayed to the client. In other words that piece of information would not appear on the screen and the user would not be aware they were missing any information. Record or data level security is used to restrict contribution information that is displayed to the client by college code, college code and department code within a given college, or by fund accounts. This security feature allows a system administrator to restrict individuals in each college to view only contributions to their college or across colleges, if restrictions by fund accounts are used.

In addition to integrated application security the SUMMITWEB application utilizes Secured Sockets Layer (SSL) encryption. With SSL all data transmitted from a web server is encrypted and decrypted at the client browser. SSL also allows a client browser to encrypt data sent from that browser which is then decrypted at the web server. This process ensures that all data transmitted between the server and the browser is in a secured format. Figure 2 shows the user security window. Note the stored encrypted password that was set by the user in a text form then passed through an in-house designed encryption algorithm and then stored.

Figure 2: User Security Screen

Application Independence

Through our research of other web applications we noticed a trend of web design and programming which limited the client to use either Netscape or Internet Explorer as their browser. In addition, these applications also limited the functionality of the application not only by the type of browser but also by the version of browser used. A good example of this is any application using client side Java Script, Java, Java Applets, or Active X controls. Because Internet Explorer supports Java slightly different than Netscape, some commands may work in one browser but not the other. In addition, although new releases of browsers are being developed to accommodate some of these differences there are still users who are using older versions of browsers which do not support Java or Active X. We knew that our client base would use the full spectrum of browser types so we wanted an application which would be able to offer a high degree of browser independence. In order to accomplish this guideline we needed to understand how browsers would process the HyperText Markup Language (HTML) differently. This meant first establishing a browser range we felt might encompass a majority of the users on campus. The next step was to extensively test every web page on every web browser in our pre-defined range of browsers. This process helped us identify inaccurate code and helped standardize code that would work in all the required browsers. By allowing the SUMMITWEB application to not be dependent upon a certain browser, the ADP Center was able to eliminate the need of supporting a particular browser across multiple client stations. This also allowed the client the flexibility to use a browser they were already comfortable with.

Just as different browser types could restrict an application's abilities, so could different screen resolutions. A client with a 17" monitor and a screen resolution setting of 1024 X 768 will be able to see more information on their screen than a client with a 15" monitor and a screen resolution setting of 800 X 600. After testing on different size monitors and screen resolution settings ADP felt that it was important to deliver as much information to the client as possible without having their screen resolution considerably restrict the amount of data displayed to the user. To solve this problem we reviewed many other Internet sites and evaluated their solutions. Almost all of them had two techniques in common. They used horizontal and vertical scroll bars and resizable frames. The ADP Center implemented these techniques and found that they would help considerably. However, because of the amount of data our application delivers, we found we needed more to solve this problem. We very carefully created logic that would allow a user to magnify the main viewing area of the application to the full width of the browser. Carefully, because navigating in and out of frames in a web application can be very tricky. This is so because when using frames there will always be one frame that is active. When going between a page that is not in a frame and a display which has four pages, each one in a frame of its own, the active frame must be deactivated before calling the new page. If this is not done the new page will overwrite the page in the active frame thus confusing the user and disrupting the application flow. Also, to extend the viewing area potential we eliminated all navigational buttons provided by the browser and coded all navigational controls in the application. Figures 3 and 4 on the following page show the gift browse screen in unmagnified and magnified states. Notice the marked design techniques and the missing browser toolbar.

Along with independent browser types and screen resolutions the SUMMITWEB application can also be accessed through browsers running on a variety of operating systems. When the SUMMIT PC application was created, our clients were very excited about using a graphical system on their PC. There was only one drawback: a PC with a significant amount of resources was needed to run the application. Being a university we have clients who use a wide variety of computers ranging from a 286 PC to Macintoshs. These clients need access to the system in order to view their accounts, but we could not provide access without providing another method of viewing the data. In addition we could not write a separate application for every operating system platform our clients use. Since the Internet is accessible from a majority of operating system platforms an Internet application fit well in solving this problem.

In creating an Internet application to run on multiple operating system platforms it must not be assumed that it will work simply because most operating systems access the Internet. As stated earlier different browsers process Java and HTML differently. This is also true for browsers across different operating systems. Because Java is compiled by the browser at runtime a browser running on a Macintosh may fail if the Java code was designed for a windows environment. If an internet application is to be accessed by a client base using multiple operating systems, specialized coding (i.e. displaying Windows based toolbars) should not be used and the application should be tested across the operating systems expected to use the application.

Figure 3: Gift Browse Screen (Unmagnified)

Figure 4: Gift Browse Screen (Magnified)

Integrated Client Base Analysis

Building data-centric Internet applications is quickly becoming a reality for many higher education institutions. Because this type of development is still in its early stage, our only guide on how to develop in this environment was determined through extensive research. Once the application was developed and tested we had the idea of incorporating code into our application which could give us additional information about our client base that the web server itself could not provide. Through more research we found coding techniques which would give us exactly what we were looking for. By using a combination of Java Script and Visual Basic Script we were able to accumulate information on each client who uses the application. This information consisted of :

The code logs the information each time a user successfully signs into the application. By logging this information we can apply a statistical analysis and determine what type of environment, data-centric Internet applications at our university should be expected to run in. Figures 5 through 7 on the next page are taken from our statistical analysis of the logged data.

These graphs are a testament to the success of the SUMMITWEB application. The "other" category in figure 5 is capturing new beta browsers using the SUMMITWEB application. Likewise, the "unknown" category in figure 7 is displaying failed attempts at pulling client screen resolutions. These failed attempts are a result of uncontrolled client interference while the application is trying to collect this piece of data. The results of these graphs show that the core of our clients, accessing the SUMMITWEB application, are using Netscape 4.0, running on a Windows 95 operating system with a screen resolution setting of either 1024 X 768 or 800 X 600. By compiling this information we can create better guidelines which will help us define the limits of functionality we can implement in future applications, thus delivering a more robust internet system to our clients.

Independence from Client Resources

All GUI applications in one way or another are dependent on a certain amount of resources on the client machine in order to operate properly. This was a concern since this was a major issue with the SUMMIT PC application. We found the solution to this problem in Active Server Pages (ASP) and Internet Information Server (IIS). Active Server Pages allow developers the ability to embed either Visual Basic Script or Java Script in a web page surrounded by HTML. The developer can also force the script to be executed at the web server instead of at the client station. This also means that by using ASP, a developer could dynamically change the appearance of a page. This is done by dynamically changing the HTML sent to the requesting client from the web server. In addition, both Visual Basic Script and Java Script allows a developer the ability to connect to an external ODBC compliant database and retrieve data which could then be dynamically added into HTML and sent to the requesting client. Just think, all of this functionality executing on a web server independent of the requesting client's resources. Realizing the flexibility of this technology we elected to create the SUMMITWEB application using these methods.

After development was underway we discovered that in order to add the same look and feel of the SUMMIT PC application we would have to use some client-side Java Script. We set guidelines on where and how much script would be used and proceeded to place Java Script in our application. This worked perfectly. We found that we only needed to add script to perform functions like displaying a pressed button or redisplaying a page once the selection criteria was changed. Java Script was only added in areas of the application where the execution of the script was not critical to the functionality and performance of the application. The script that we used is, at most, four lines of code and was placed in only a few pages of the application. It is the only script that executes on the client station thus allowing us to accomplish a client resource independent application.

 

Figure 5: Browser Types

Figure 6: Operating Systems

Figure 7: Screen Resolutions

User Acceptance

A user who migrates from a character based CICS system to a GUI Internet system has to make a very big adjustment. This was anticipated, so we elected to train 90 users on the functionality and similarity of the SUMMITWEB application. These training sessions benefited us as much as the users. Through these sessions we were able to gauge how successful the application might be. The application showed a tremendous amount of promise as the users were thoroughly impressed with its graphical presentation, the robust user-friendly controls, the amount of data delivered, and the speed of delivering the data in an internet environment.

Once the SUMMITWEB application was put into production, we eagerly awaited user reactions. To our surprise user reactions were far better than imagined. Only positive responses have been reported from both users of the system as well as non-users who have heard about or maybe seen the system. Since its inception, we have averaged between 20 and 30 users logged in daily, and no one has reported any problems with the SUMMITWEB application.

Conclusion

The work we have done on the SUMMITWEB application has taught us to look at the Internet in a new light. We have learned that client needs are a much bigger concern in a data-centric Internet application environment than in a typical transaction based environment. This is due to the vast number of tools vendors are providing users to interact with the Internet. We would like to think that the solutions we put in place today will continue to be solutions for the long term. With the continuing changes in technology we know this is not a feasible conclusion. In order to continue creating successful data-centric Internet applications we need to continuously evaluate new technology and determine its appropriateness in our environment.

It is important to note that just as a transaction based or GUI PC system can be designed many different ways, this is also very true with Internet applications. The area of Internet development is so abundant in tools and add-on components that it can become difficult to create long-term, feature rich Internet systems. Deciding on the appropriate tools and features to implement is very critical to the success of an Internet application. A possible guideline for making these decisions may be found by adhering to the following statement -- Database driven internet systems of today must be narrow enough that they focus on the target groups that will use them, but not so narrow that the systems restrict the growth of the target groups or the platforms they run on.

Overall this project has been very successful at ISU and positions us for the future in supporting systems on the World Wide Web. The structural design of our approach will also fit other "core" applications at ISU.