Readers Respond: Client-Server Computing Strategy: Has your campus committed to it *************************************** Copyright CAUSE. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear,and notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To disseminate otherwise, or to republish, requires written permission.For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu *************************************** READERS RESPOND Question: Has your campus committed to a client-server computing strategy and, if so, what steps have you taken or identified to implement it? At Penn, we have just gone live with a client-server application used to assign campus ID cards. The application has a small user population. The purpose of the effort was to move an existing application to a more robust operating system and platform and to take advantage of a graphical user interface. The client platform is currently Microsoft Windows running on a 486 microcomputer. The application is based on an Ingres database using Ingres's Windows 4GL, with an RS/6000 as the server. The Ingres database is updated from both the client application and fed from the mainframe transaction systems. Other systems are expected to draw data from the Ingres database. Carl Abramson Associate Vice Provost for Information Systems and Computing University of Pennsylvania abramson@a1.relay.upenn.edu Cornell University's vision for the use of information technology is to make all information accessible from a desktop (wherever that desktop happens to be). This architecture requires implementation of all of the services (and more) that are provided by the mainframe environments of today, only network based. The complexity of this infrastructure cannot be overlooked. We have made several decisions to move us ahead. (1) We needed to use our legacy data. We couldn't throw out all of the applications that have been designed to collect and process this information. (2) We knew that SQL access to this data would not produce the desired result. Users would have difficulty understanding the structure and definitions of the data. (3) We decided to build an industrial-strength infrastructure to develop our client-server applications. (4) We chose object-oriented technology for our client programming environment. (5) We didn't want to retrain all of the staff in graphical user interfaces and client-server design. In a joint project (called Mandarin) with Apple, MIT, and Penn State, we have attempted to build the infrastructure and toolset to develop client-server applications. Our first success was a product called "Just the Facts," which allows students to look up their grades, bursar bills, course information, and change their address. This service is available from kiosks or any Macintosh that has a network connection (like some of the dorm rooms). We have also developed a product called Bear Access (Cornell's mascot is the Big Red Bear) that allows the campus community to point and click their way to many additional campus services like POP mail, CUINFO (our CWIS), the library catalog, and Gopher. Client routines to allow faculty to view student data for advising will be available in the spring. We have implemented Kerberos, from MIT, as our network authentication system. We have written a version server that makes sure the client software is synchronized with the server software. We have servers to do authorization and aliasing (converting network IDs into system keys). There is a script server that controls the functionality of the client routines. All of our network communication is based upon TCP/IP. In partnership with Penn State, we have written a sockets-level protocol routine to allow direct communication with Natural (our fourth-generation language from Software AG) running in VM and MVS. The generic server calls "action routines" written in Natural to retrieve data from our production data in ADABAS (also from Software AG). This allows the client software to specify "what it wants" and the action routines send "what it meant." To prove the modularity of the design, we have successfully ported Just the Facts to Penn State. The client has been demonstrated at many different sites. It accesses test databases at Cornell over the Internet in real time. David W. Koehler Director of CIT/Information Resources Cornell University David_Koehler@cornell.edu Our central academic computing systems began to migrate to a client- server architecture during the mid 1980s. Rapid adoption of the technology was driven by the explosive growth in the number of academic workstations and the academic community's needs for a more flexible environment. Some of the first services implemented were DNS (domain name service), NFS (Network File Service), NIS (Network Information Service), NTP (Network Time Protocol), electronic mail transfer (Eudora, SMTP servers, etc.), file transfer (FTP), networked file system backups, distributed and remote presentation (X-Windows). This approach paved the way for changes in our administrative computing environment as well, having shown that the client-server model offered increased flexibility, increased productivity, higher performance, and, over time, reduced costs. In spite of, and perhaps because of, drastic budget and resource cutbacks, our division has embarked on a plan to upgrade and improve access to three major campus-wide administrative systems: the student information system, the financial system, and the payroll/personnel system. The student information system is proceeding towards this goal, with some functions already implemented in client-server fashion, while upgrades to the other systems are in their formative stages. Our strategy for the migration to a client-server architecture includes the following: * We must have ubiquitous campus networking, as data will flow between clients and servers in all areas on campus. * We must empower departments to support both sides of the client- server model, and to facilitate a migration towards a tiered client- server architecture. This tiered approach would include clients at the desktop, as well as departmental, campus area, and centralized systems running client and/or server applications. The centralized systems would support applications with campus-wide scope, while the campus area and departmental systems would support more diverse usage of these applications and data. * We must make the vendors aware of our client-server application needs through the standardization of our RFP and RFQ process. * We must embrace the leading edge of computing technology and computing environments. This advanced technology will serve as a guidepost for the evolution of the client-server model, as the way that people think about and use computers and information changes. Paula King Kent Kuo Sam McCall Information Technology University of California, Davis pmking@ucdavis.edu At Bradley University, we have committed to client-server computing as our future campus architecture for both academic and administrative computing. Bradley has been a fully networked campus since 1986. Beginning in 1989, all new academic computing projects were implemented in a client-server model. Examples include: * The Residence Halls of the Future project. Each room in six major residence halls is equipped with a color 386SX or 486SX PC, printer, and Ethernet connection. Software, print services, and access to campus networks and the Internet are supported by a cluster of 486 servers. * Library Information Network. The University Library, recently doubled in size, is equipped with a multi-functional client-server LAN, providing library users with access to productivity software, network information resources (including the Internet), networked CD- ROM databases, network delivery of fax documents, and an image database of rare photographs. * Departmental labs. All new departmental computer laboratories are built on a client-server model. Our client-server efforts in administrative computing began in 1991 with an initiative to convert all major administrative applications from the current mainframe environment to client-server LANS. This conversion will be completed in 1995. The initial client- server application--advancement--will go online June 1, 1993. Finance will be converted during fiscal year 1994. The following year, all student records applications will be converted. With the exception of finance, all new client-server development will be programmed by in- house staff, working with an outside consultant. New administrative client-server applications are being developed using a rapid-prototyping methodology. A cross-functional joint applications development team consisting of user office personnel, staff programmers, and the consultant meet weekly to review progress and plan further development. The use of an outside consultant skilled in applications design, plus the selection of powerful application development software, have made it possible to complete each step of development within the five working days between team meetings. We expect the new client-server applications to greatly enhance administrative operations and improve access to information. We also expect the cost of client-server administrative computing to be significantly less than that of our current mainframe environment. Joel L. Hartman Associate Provost for Information Technologies and Resources Bradley University (Illinois) joel@bradley.edu The Catholic University of America (CUA) is just now putting the finishing touches on a reengineered student information/financial record/facilities management system that we consider to meet the client-server model, at least as we define the term. What we have done is to create a common relational database (using Digital's RDB) on a VAX 4500 server/central computer that contains current and historical data for admissions, orientation, registration, financial aid, resident life, student accounts, financial records, and facilities management. CUA has adopted the philosophy that the MIS staff is responsible for developing and maintaining the tools necessary for putting data into the database. Third-party products provide the tools to extract data from the database for analysis and manipulation. Because multi- user, multi-level security can not be provided for on a PC platform, the database can only be accessed for updating from an account on the central computer. CUA has developed a security package that makes a single account/password per user possible regardless of the work to be done. If the user wishes to access the administrative data, s/he is granted dynamic access to the relevant portions of the database based on the application chosen. If a user wishes to report against, or extract data from, the database, an ad hoc reporting tool (SQL-Assist from Software Interfaces) is available, that allows data to be downloaded across the LAN to a PC where it can be manipulated by any number of specialized PC-based packages. Leonard J. Mignerey Director, MIS The Catholic University of America (DC) mignerey@cua.edu For electronic mail, we outsourced the basic hardware and software for the e-mail service; we develop and support our own client software for Macs and PCs. For information services, we developed and deploy Gopher; we are exploring putting up many different kinds of information, including the University Libraries now making Current Contents available through Gopher. In administrative systems, we have a pilot project under way which front-ends our Hitachi mainframe with an RS/6000 server. Client software uses SQL to query the server. Don Riley Acting Associate Provost for Academic Affairs Computer & Information Services University of Minnesota drriley@mailbox.mail.umn.edu The University of Utah is considering a client-server architecture to distribute student departmental data from the mainframe database to databases on departmental servers. The department servers would then be accessed from department clients for data analysis and reports. The Recital database is under evaluation for the department servers. The mainframe database is Software AG's ADABAS. The administrative data processing department has proposed to the central administration that the present 3090 mainframe be downsized to a transaction processing rated Unix RISC platform for cost savings purposes. The software on the 3090 would be migrated to the Unix platform, not rewritten. A decision is pending. Earl Kartchner Director, Information Systems University of Utah ekartchner@adp.utah.edu