In-Depth

The RIT Stuff: Students Drive Universities to the Future of Data Access

• By Larry Akers
• 12/01/2000

Historically, leading-edge companies have been in the spotlight for using the latest technology in their operations, and the education sector has followed. However, the advent of a large number of technology-wise students demanding easier ways to access course information, registration, grades and financial account status, has pressured educational institutions to investigate ways to serve their students better. The World Wide Web is the ideal vehicle for these organizations to provide efficient access to their student administrative functions from anywhere in the world.

Like most businesses, educational institutions have spent decades developing mainframe 3270-based systems that do an excellent job, but they don’t work on a Web browser. These legacy applications have years of development invested in them, and significant dollars have been used to customize these applications to meet the organization’s specific needs. The presentation logic of these applications is deeply integrated with the business logic, and targeted exclusively for 3270 terminals.

This was the problem facing Rochester Institute of Technology (RIT), in Rochester, N.Y. RIT is internationally recognized as a leader in imaging, technology, fine and applied arts and education of the deaf, and enrolls over 13,000 full- and part-time students. RIT has always been a leader in providing students with technological advances. (RIT was one of the first universities in the United States to introduce telephone registration.) Their 3270-based Student Information System (SIS) is called upon to provide students not only with course information and class availability, but also with realtime access to a student’s grades, home, emergency and billing address information, housing information, student account status, quarterly charges, financial aid and general bulletin board information. A student can also project quarterly and cumulative grade point averages through a GPA modeling screen.

RIT, like many other universities, strives to be cost effective. The challenge is improving student administrative functions, while at the same time minimizing costs. Online services eliminate many previously labor-intensive tasks, and reduce staffing requirements. RIT aimed higher by deciding to use the Internet to empower students to identify and solve problems directly, and perform many administrative tasks for themselves. This allows the RIT staff to focus on solving "real" problems, rather than being burdened by repetitive and routine functions.

RIT already had administrative applications implemented on its mainframe computer. A major objective was to continue using current 3270 applications, and give students more direct access to class availability, current grade information and financial records without changing or rewriting applications.

RIT had considered moving some of its student-related applications and data to smaller server computers, but rejected that idea because of increased cost, staff, education and maintenance. With its Web site in place, RIT moved onto their next step for providing students Web browser access to most administrative applications – they went through a "buy or build" analysis.

Faced with this challenge, the choice of how to proceed came under one of the following categories:

Start fresh. One approach would be to continue operating legacy applications normally on 3270 terminals or emulators while IS specialists set about writing all new application software to accomplish the same business needs with a different front end, such as a Web browser.

This approach had formidable drawbacks for RIT:

• It would be extremely expensive.

• It would duplicate existing "tried and true" software by opening the door to technical problems and dual software maintenance.

• The development time required would be prohibitive.

Reengineer. This approach would change existing legacy software so that it operates with different presentation logic. While the mission-critical business logic would not change, the programs would be rewritten to operate, either on a Web browser or other front-end device. Again, there would be significant problems with this solution.

• The expense and time requirement would still be high.

• The risk of disturbing essential business logic would be real.

Reface. This technique would involve no changes to legacy applications software. Additional software, either provided by vendors or developed in-house, would be interweaved between the new front-end device and the existing software. This new software acts as a presentation translator by intercepting outbound 3270 displays, and converting them "on-the-fly" into the format required by the new front end. There would be significant advantages to this approach, such as:

• It would be far less expensive.

• There would be no invasion of existing software, resulting in minimal risk.

• It would provide instant Web enablement of all 3270 applications with no significant development effort.

But, a major disadvantage remains. Legacy applications would still operate like 3270 applications. Refacing does not take advantage of the improved presentation capabilities of a Web browser or other front end. Some products allow users to radically change the appearance of individual 3270 screens, but the operation of the applications is still "one-for-one." That is, one browser request equals one legacy screen display just as a 3270 terminal would function.

Remodel. Like refacing, additional software would be used to interact with legacy applications and would require no changes to existing software. Unlike refacing, however, remodeling would take advantage of the expanded presentation capabilities of new front ends. It would provide a method of integrating legacy transactions, extracting data from multiple screens and presenting it in far more sophisticated ways. Remodeling can transform legacy applications into true Web applications, and take full advantage of today’s technology. The pros and cons of this approach can be stated as follows:

•Like refacing, remodeling would require far less expense than starting fresh or reengineering, and there would be no changes required to mission-critical software.

•It would have the additional advantage of fully utilizing the presentation capabilities of new front ends.

•This technique would require development of some kind of middleware application software.

The option of building their own Web enablement system was ultimately rejected. "This is pretty complicated technology," says Pete Kulpa, RIT’s Information Systems Manager. "We’ve got some great IS technicians, but frankly, we didn’t want the technical support load. This is a critical application that has to work right all the time."

It was decided that RIT would find a software product that would provide both refacing and remodeling options. SIS was a remodeling project, since the end result was to be a state-of-the-art Web application, not just a 3270 emulator. Refacing was still desirable for less critical systems.

Providing new presentation logic was not going to be a problem. There were a number of good HTML generation tools on the market, and RIT’s programmers found HTML easy to learn. They also wanted the capability to use Java, wherever it might be applicable, and leave the door open to new front-end technology that might develop in the future. The problem was the back end – how best to integrate the SIS 3270 applications with a different front end.

Three-tier solutions were considered first. In a three-tier environment, browsers communicate with an interim platform, such as an NT or UNIX-based server. The server tier then communicates with the mainframe, sending and receiving data one transaction at a time, just as an operator would function on a 3270 terminal. But three-tier products have performance and scalability issues. Every 3270 transaction must pass across the network, which is typically the slowest executing part of an enterprise. As the number of Web-enabled users increases, the power of an external server platform can be quickly consumed requiring additional servers to achieve scalability. The hardware cost of three-tiered solutions was seen as an ever-increasing expense.

RIT evaluated a number of possible vendor alternatives, and selected CrossPlex, a Web-enabling product from SofTouch Systems. CrossPlex is a two-tier solution operating on the S/390 platform, and that made sense since RIT already had a staff of systems support technicians familiar with the S/390. RIT avoided the staffing and education required to support a new hardware platform, and the IBM mainframe was a proven performer for handling large volumes of data.

With CrossPlex, all 3270 data transmissions operate in memory on the mainframe. Nothing is placed on the network until a final Web page is ready to display. CrossPlex uses the Front End Programmer Interface (FEPI) or CICS Bridge to programmatically operate 3270 applications. Legacy systems are not limited to CICS, and CrossPlex accesses any VTAM application (IMS, CICS, IDMS-DC, VTAM session managers, TSO, etc.).

"The combination of IBM’s S/390, CICS and CrossPlex gives us the speed and capacity needed to handle the Web volumes," says Pete Kulpa. Guy Stappenbeck, who provides RIT with system technical support, adds, "CrossPlex has been easy to install and maintain. We have been very happy with the performance."

CrossPlex allows RIT to put a "new face" on existing 3270-based applications by presenting the data in a more user-friendly manner, and by presenting end users with familiar graphical user interface (GUI) displays.

Developers code simple scripts, or use a Java application called Visual Application Developer provided by CrossPlex to generate scripts. These scripts provide the business intelligence to operate legacy transactions in the correct sequence, while handling error situations and accessing and reformatting 3270 presentation data. The legacy data is merged into an HTML template, or passed to a Java applet for browser display.

Another important feature for RIT was the capability of CrossPlex to provide instant Web enablement of all 3270 applications with no development effort. Users connect from a browser to the mainframe, and operate 3270 transactions exactly in the same way as they would at a terminal. 3270 displays are converted "on-the-fly" to HTML, and presented on the browser in a similar format to the original 3270 screen. Or, they can be enhanced one screen at a time with an HTML template. While RIT wanted a more sophisticated Web application for SIS, this "one-for-one" 3270 emulation feature was viewed as a good alternative for hundreds of other applications, thereby, allowing RIT personnel immediate access to any mainframe transaction through the Internet.

The SIS application was developed using "many-for-one" technology. This means a single browser request might trigger the execution of several 3270 transactions to gather all required data. The presentation of this data on the browser was not limited in any way to the original 3270 screen design.

The security of personal student data was addressed in several ways. SIS is made available exclusively to RIT students through most Web browsers. A university account number must be provided, along with an ID and a personal identification number (PIN) to gain access to information. Secured Sockets Layer (SSL), firewalls and existing mainframe security ensure there is no unauthorized entry.

RIT installed CrossPlex last May as the spring semester drew to a close. Technicians from SofTouch Systems traveled to Rochester to provide on-site training and support. Microsoft FrontPage was used to create and maintain the HTML templates, while the RIT staff quickly learned how to develop and test CrossPlex scripts.

SofTouch provided ongoing support via e-mail and telephone as the RIT staff worked through the summer. In September, as the fall semester was about to commence, the system went into production on a limited basis. RIT restricted the number of users initially in order to shake out any remaining bugs and reduce exposure.

"It worked great!" enthuses Pete Kulpa. "Our students loved it, and we loved it. I began receiving calls almost immediately from other universities who heard about it."

"There was virtually no reduction in response time," explains Guy Stappenbeck, "even though several layers of software were introduced over the original 3270 applications. The mainframe didn’t bog down at all."

Daniel Vilenski, RIT Registrar, is pleased with RIT’s accomplishments to date. "Our students are well served by this application," says Vilenski, and he adds, "We are extremely satisfied with the success of this critical project."

Larry Akers is Vice President of Research and Development for SofTouch Systems (Oklahoma City).