(10:00 am, Friday)
Edward V. Michalak III, BS, BA, MS
Thomas Jefferson University
David A. Gitlin, BA, MA, MS
Thomas Jefferson University
JEFFLINE - The Information System of Thomas Jefferson University - Migration to a Client/Server Version Using NCSA Mosaic and Lynx.
ABSTRACT
JEFFLINE, the information system offered by Academic Information Services & Research (AISR) at Thomas Jefferson University, attempts to resolve this issue by offering a graphical user interface (GUI) that integrates and organizes a wide variety of information services. These services are accessible by students, faculty, researchers, clinicians and doctors from their desktop microcomputers. Attendees will be able to gain experience from
colleagues on how to plan, test, and implement a migration from
current terminal-based information systems to client/server,
hypermedia information systems.
PAPER
Introduction
Today universities are confronted with a diverse array of hardware and software platforms through which information can be accessed, either locally or externally. Accessing this information can be difficult and time consuming, because it involves trying to learn and use different hardware systems, operating systems, software applications, and interfaces. JEFFLINE, the information system offered by Academic Information Services and Research (AISR) at Thomas Jefferson University, attempts to resolve this issue by offering a graphical user interface (GUI) that integrates and organizes a wide variety of information services. These services are accessible by students, faculty, researchers, clinicians, and physicians from their desktop microcomputers.
Recently AISR completed development of the first GUI version of JEFFLINE, and released it for beta testing to the TJU community. Taking advantage of the latest client/server Internet tools, the server portion was constructed on an IBM RS/6000 minicomputer, using NCSA's HTTPD 1.0 server software. Links to hundreds of information services, either locally, or across the world, were created using the Hypertext Markup Language (HTML). Patrons within Scott Memorial Library use a Macintosh microcomputer, using NCSA's Mosaic software (later, Mosaic Netscape), to access the server. Outside of Scott Library, and across the world via the Internet, patrons of JEFFLINE can use any client, such as Mosaic for Windows, Cello, or Lynx (VT100 client), from the microcomputer of their choice.
JEFFLINE consists of links to an integrated library system, databases such as MEDLINE, clinical services such as Micromedex CCIS, a campus wide information system, electronic mail, bulletin boards, image archives, sound archives, QuickTime movies, and information across the Internet via gopher, WAIS, Archie, or the World Wide Web. Prior to development of the GUI version, JEFFLINE was available via a VAX 6410 minicomputer using VT100 terminal sessions. These terminals have neither graphics nor multimedia capabilities. Now, with the use of Mosaic, HTTPD and multimedia workstations, patrons of JEFFLINE have access to hypermedia resources located throughout the world.
This paper will describe, in detail, the planning, testing, and transformation of JEFFLINE from a terminal based information system to a client/server, hypermedia information system. It will also discuss plans for the future.
JEFFLINE - The Beginning
Just prior to January, 1992, JEFFLINE was basically a closed information system, with access to an integrated library system (including miniMEDLINE), and the clinical service Micromedex CCIS. Access was confined to DEC terminals located throughout Scott Library, and 5 dial up lines. The system was offered on a DEC PDP 11 minicomputer running the MUMPS operating system, hard wired with several asynchronous multiplexers allowing access via terminal servers in a reverse LAT configuration. The system was inherited, and plans to migrate to more state of the art systems had already been in place.
In January 1992, the Systems Department successfully started the transformation of JEFFLINE to a more state of the art system with the introduction of the DEC VAX 6410 minicomputer. Within a few months JEFFLINE had grown from a very small, closed system, to a large, diverse information system, offering, in addition to the initial resources, access to MEDLINE, catalogs of other libraries, and ASCII text files. Access was broadened by connecting the VAX directly to the ethernet, and loading TGV's Multinet TCP/IP software. Terminal sessions with the VAX had the capability of accessing the Internet via telnet sessions with remote hosts. Menus were structured on the VAX using DCL, offering great flexibility and ease in design and administration. Decisions on the design of menus were largely made by the Scott Library Senior Staff, guided by the Director of the Library. JEFFLINE's patron base at this time was not relatively large, so the system was relatively over designed for the capacity at that time. In retrospect, it offered the Library Staff time to define JEFFLINE's role as an academic information resource, and to plan for further improvements.
Exploring the Internet
Although JEFFLINE's access had been improved by connecting to the ethernet and offering access to the Internet, for the most part, JEFFLINE was still a VT100 terminal based system. JEFFLINE lacked the ability to provide graphics or multimedia of any kind. Instead, patrons were confined to terminal sessions with the VAX or other sites via the Internet, or displaying only text documents. Although JEFFLINE had come a long distance in a very short time, the Systems Department of Scott Library realized that the future expansion of JEFFLINE must incorporate a more graphical approach.
In 1992 the Library staff's personal computing power was improved with access to the ethernet via Cayman's Gatorbox router/gateway. It offered the staff the first opportunity to explore the potential of IP clients such as TurboGopher and NCSA Telnet, directly accessing information resources via the Internet from their desktop Macintosh microcomputers. Also at this time, the design and planning for JEFFLINE was improved and broadened by the creation of specific working groups which focused on such areas as the interface, Library content, Campus Wide Information content, and Education/Marketing. The working groups were comprised of not only Librarians and Systems personnel, but also Instructional Technologists, Educators, and Audio Visual specialists. These professionals served to broaden the perspective of JEFFLINE development, as well as broaden our potential market for JEFFLINE. JEFFLINE was seen as a tool to serve a larger patron base, to serve as a campus wide information system for the entire university.
By 1993 JEFFLINE had expanded to the point where it now offered access to a campus wide information system, electronic mail for students and faculty, and various other services, either locally or external. Due to exploration of the Internet, using microcomputer based clients, the Systems Department was able to successfully implement a gopher server. The gopher server was one of the first at the University, and was accessible via JEFFLINE.
The gopher server was JEFFLINE's first venture into the graphical world. It was largely the product of the JEFFLINE Interface Working Group, and it was designed with a special focus on the University's mission of Education, Research and Patient Care. With TurboGopher loaded on a client Macintosh, patrons were able to access the gopher server and retrieve sounds or images, either locally owned, or via the Internet. Through JEFFLINE, the gopher server could also be accessed via a terminal based gopher client on the VAX, so that any JEFFLINE patron could access the gopher server in some form.
The gopher server was a very big success with the JEFFLINE patron base, but it quickly became apparent to the Systems Department that, although JEFFLINE had grown and was now able to offer some graphical services, the organization of JEFFLINE was not seamless. Due to technical limitations, it was not possible to completely integrate the gopher server into the existing JEFFLINE offerings, resulting in some overlap and slight disorganization. It became apparent to the JEFFLINE working groups, especially the Interface group, that the design of JEFFLINE needed to be reconsidered, based on our advancements in technology, and based on our need to offer a tightly integrated, graphical interface to our patron base, based on emerging client/server technology.
By late 1993 the Systems Department had begun to explore the World Wide Web, and the development of information systems based on hypertext markup language. It was quickly realized that the simplicity and highly integrated interface offered by the World Wide Web would solve a lot of the design and access problems in the existing version of JEFFLINE. Despite the introduction of a gopher server, JEFFLINE was still a terminal based system.
The World Wide Web and Client/Server
In the previous section we have discussed the limitations that we faced using both the DCL based menu systems, and then the gopher based menu system. During this time we began to experiment with the World Wide Web for the display of text and the construction of hyper links to other systems. The decision to use the World Wide Web (WWW), via NCSA's HTTPD server and clients such as Mosaic, Netscape and Lynx, as the primary technology by which we would reconstruct the menu interface to JEFFLINE, was prompted by several factors. Some of these factors were our dissatisfaction with the limitations imposed by the technologies discussed in the previous section, and some were due to organizational changes that occurred within our department. We shall examine the technical issues first.
The VAX/VMS platform on which the library's primary software products ran, as well as AISR's email system, had proven to be a reliable platform. VMS is a well developed, robust, and full featured operating system. The DCL scripting language which constitutes a part of VMS is powerful. However, as a result of the increasing demand for computer resources, as well as the organizational and technical changes mentioned above, we began to find that the VAX/VMS platform was limited in several ways. The VAX architecture is nearing the end of its life cycle. The per mip cost of a VAX, as well as the per megabyte cost of storage is significantly higher then other hardware platforms, such as RISC based systems. This means that scaling the VAX to meet the increasing demand for computer services is quite costly compared to RISC based platforms. This is of increasing concern as the load on the VAX increases, and response time decreases. Many of the software products we found of interest, such as gopher and the World Wide Web, either did not have VAX based implementations, or in the case of our gopher, were not robust enough to handle the load placed on them. UNIX has become the operating system of choice in research environments, and that is where most of the development work for technologies such as HTTP are going on. Client/Server systems are evolving into the focal computer technology of the nineties.
One of the reasons is that C/S systems can be scaled far easier, and are less costly, then standalone minicomputers such as the VAX. The Systems Department felt that client/server (C/S) technologies could prove to be a valuable asset for AISR, and a powerful platform on which to implement the next generation of services. VAX/VMS is not as well suited to act as a server as UNIX platforms running on RISC based processors. UNIX handles process creation and destruction far better than VMS, a necessary attribute for a server, and RISC systems are cheaper, faster and far less costly to scale up. In addition, we had already committed ourselves to buying a UNIX platform to run the next generation of medical databases. Hence the migration towards the use of the Web was part of a larger decision to begin to migrate away from our legacy VAX/VMS platform, and towards a client/server system using RISC based servers running UNIX.
At the same time the Systems Department was not satisfied with the platform on which our most important databases, such as Medline, were offered. Originally, they were installed on a Novell platform. To make these databases available from remote sites, and compatible with a VT100 interface, access to the Novell server was done through Vservers supplied by Virtual Microsystems, Inc. This type of access, for such heavily used and important databases, proved to be unsatisfactory. It was not only quite slow, but unreliable. The Vservers often needed to be either serviced, or rebooted. This method also meant that all transactions on these databases had to be routed through our increasingly overtaxed VAX 6410. (Vservers are designed to allow users to access Novell file servers from VAX based VT100 terminals. They are designed to be compatible only with VAXes.) As a result, the library decided to purchase a new platform to run these databases. The platform consisted of an IBM RS6000, running IBM's version of UNIX, AIX. This system has twelve gigabytes of disk space and over 125 megabytes of memory. Access to the system is done either through telnet or rlogin.
The Office of Academic Computing (OAC) also has a smaller RS6000 which it uses to run database services and CBL software. At approximately the same time, AISR also purchased a number of microcomputers. As a result, the division now had software running on three different platforms and on three different minicomputers, two RS6000s and a VAX 6410. Since the original menu scheme had been developed for the library system alone, and had been designed to run only on a VMS platform, we began to search for a new way of integrating these diverse information technology resources.
Given the wide diversity of services offered by JEFFLINE, and the amount of capital invested in existing systems, the migration to a C/S system will have to be done in incremental steps. The Systems Department feels that implementing a C/S menu system, using the World Wide Web, is an excellent way to begin the migration process. For one thing, it makes use of hardware resources already owned by the division. WWW software, both server and client, are either free or attainable at a nominal cost. The HTTPD Web server was designed primarily to run on UNIX platforms, and AISR had already purchased such a platform to support its medical databases. In addition, the WWW offers several unique technical innovations. It combines the ability to display text, hypertext, graphics, gopher services, images, QuickTime (C) movies and sound in a single unified package.
The power of the Web also stems from the number of sophisticated, and elegant looking clients now in existence. NCSA's Mosaic and Netscape from Netscape Communications Inc. are both attainable free of charge for educational institutions. They run on a variety of platforms, MAC, PC and Xterminal. AISR depends primarily on the MAC versions although it does have a few PC's running Netscape. The initial client chosen by the Systems Department was NCSA's Mosaic. However, we found that Netscape was more robust, incorporated a much larger set of features, and provided an aesthetically pleasing interface. Netscape can load images, with an internally launched viewer.
It can also be configured to launch applications, such as sound players, movie players, etc. We found that one of the more interesting features of the Web is its support for electronic forms.
Not all clients adequately support this feature, but Netscape does. The library has designed several different forms and plans to incorporate more into its menus. Netscape's multi threaded architecture allows it to retrieve graphics from a page while the user follows a link to another page.
The HTML language is becoming widely used and documentation for it is becoming more extensive and diverse. Most importantly the WWW is based on a stateless C/S model and thus offers several advantages for building menu based software. Because the client depends on a central server only to receive its startup page, and an initial description of available links, it is able to access resources located on other platforms directly, without constantly going through a central system. That is, once the client is told what links are available, either in the form of telnet, gopher, or other services, the client can make a service request directly to the appropriate server without having to go through a central machine. This has the dual advantage of relieving the stress put on our already overtaxed VAX, and allowing us to integrate a wide diversity of services located on different platforms. In effect, the Web combines the ability to provide the end user with the appearance of a single unified menu system, with the ability to spread resources out over many different platforms. In the case of our links to the Internet, the resources do not even need to belong to TJU. The end user need not have any idea of where the software they are using is physically located, or on what platform. Resources still located on our VAX system, such as email and our OPAC, can be accessed by creating telnet links that point to the VAX.
There are other benefits as well. The system has become increasingly easy to scale in a way that was not possible when we depended on a single, centralized menu system, based on DCL command files. We can now add relatively inexpensive hardware resources to our existing servers and clients or, as our budget permits, increase the number of servers and clients in the system. Any hardware platform that supports the TCP/IP protocol stack can be added to the system. The division plans to buy a second RS6000 in the summer. Integrating this server into our present system should be straightforward.
In addition, a higher level of fault tolerance and reliability is now possible. Since, resources are located on a diverse array of machines, the failure of any single platform means that only the services offered on that platform are unavailable, all other services can still be accessed. The entire system can still fail if the central server, which all of the clients point to for their home pages, fails. However, this situation can be avoided by simply duplicating the menu structure on the central server on secondary servers. (The amount of disk space the HTML documents take up is nominal.) If the main server were to go down we need only re point the clients to the backup server. We plan to implement this type of redundancy once we purchase a second RS6000 in the summer.
In addition to all of the technical advantages the Web supplied, we began to realize that it offered a number of social and organizational advantages as well. In 1993 the library was incorporated into a newly formed division, known as Academic Information Systems and Research (AISR), which included several other departments. These departments consisted of the Scott Library, the Office of Academic Computing (OAC), and Medical Media Services (MMS).
The new division was given the mandate of servicing all of the academic and research information needs of the TJU community. The division was concerned with information resources of all types, not just those traditionally associated with a medical library.
The formation of this new division opened up exciting opportunities for experimentation, as well as significantly extending the role of the Systems Department. The Systems Department was now expected to oversee, manage and integrate a much larger array of information technologies. The inclusion of these departments into one division greatly broadened the types of information services that could be offered, as well as the range of expertise in creating and delivering these services. The OAC had developed an expertise in computer based learning, and computer based instruction. It also managed several microcomputer labs. These labs existed in addition to the computers offered by the library. Medical Media Services employed a variety of talented graphics artists and individuals experienced in the development of multimedia. Individuals with a wide mix of skills, and perceptions of how to use those skills, were now brought together. As a result new points of view, and expertise, were brought to bear in the evaluation of JEFFLINE's interface and the manner in which it presented its services. We should also mention that shortly after the formation of the division AISR hired a new head of education who had spent several years evaluating and developing interfaces for commercial software companies. The challenge now was to make use of this expanded pool of expertise and resources and to integrate it into a unified whole.
We found that several social and organizational benefits resulted from the adaptation of the web as the underlying technology by which we would construct our new menu system. Since the old DCL based system required a fairly detailed knowledge of VMS to implement and extend, only systems personnel were able to actually make changes or extend the menus. And as pointed out above, the fact that the system was completely character based, meant that limited use could be made of the talents offered by the pool of graphics artists, educators and librarians that existed in the division. By initiating a system that made heavy use of multimedia we were able to tap the talents offered by the other members of the division. Graphic artists could now participate in the design of the system and suggest stimulating and eye catching icons and menu arrangements. The educators in AISR, who already had experience in interface design, could use this knowledge to stimulate the development of menus that were both easier and more intuitive to use. The librarians in the division were also invaluable in finding and organizing resources to include into JEFFLINE. The new technology has stimulated a great deal of cross collaboration between a widely diverse group of professionals. This collaboration had not been possible with the technologies we were currently using.
A large quantity of documentation on HTML is beginning to emerge. And although there is a learning curve associated with using HTML it is significantly less then learning DCL. As a result, a greater array of individuals could participate directly in the implementation of the menu system. This is also facilitated by the way in which the Web works. Through hyperlinks to documents located either on different directories, or different machines, the Web gives the user the impression she is using a unified system, even though in actuality, the resources that are being used may be dispersed across many different computers located in many different physical locations.
For example, the OAC had a RS6000 of its own which it had been using for CBL and database projects. By implementing a secondary HTTPD server on that machine, and by creating links to that server from the main server, individuals can go back and forth between OAC based resources and library resources with great ease. This arrangement allows the OAC staff to make changes to their menus in a timely manner, and without the need for intervention by the Systems Department. This allows AISR staff a great deal of flexibility in setting up and changing pages that deal with resources of concern to them. One of the charges of the division is to manage the university's CWIS. The CWIS incorporates information resources from a number of departments not directly associated with AISR.
In the future we hope to extend the ability of personnel in other departments to create department specific menus within the CWIS with minimal intervention by the Systems Department. The changes to these pages can be done in several ways. Individuals can use a local editor to create the HTML document and then give it to the Systems Department, who then in turn, load it onto our central server. This technique is facilitated by the fact that MAC based HTTPD servers exist. This allows individuals to draw up HTML documents on their own machines, test them with their local server, and when they are satisfied, submit them to the Systems Department for inclusion into the central server. A second technique is to create accounts on the RS6000 for designated individuals, and allow them access only to those directories and HTML documents that are appropriate for them to change. Since UNIX provides a number of sophisticated ways to set protections on files and directories it is possible to allow this type of access without compromising the entire system. Thus, staff are happy because they have greater control of pages specific to their areas of specialty, and the Systems Department is happy because it can be assured that the integrity of the whole system will not be violated. A final note on this topic should be mentioned. There are many computer phobic individuals in the university who nonetheless, have valuable insights into the organization of information. As a result of the WWW's use of multimedia, and the elegant appearance of web browsers, many individuals, who would previously not have been interested in participating in the development of an information system, are drawn into the process.
Although the new Web based version of JEFFLINE is clearly a major step forward, it has created its own set of technical problems. As we all know, no technology is without its costs.
The first is that individuals must acquire new skills, namely the ability to write HTML documents, and to use graphical clients on microcomputers. This does involve a learning curve, and is not accessible to everyone. The development of HTML compilers, that is, software which is able to translate word processing documents into HTML documents, would be a great help in making the Web more accessible. Certainly though, the ability to program in HTML is far more accessible then the ability to create DCL command files. Patrons must also get used to scrolling through documents, clicking on links, and navigating through the Web. In the old text based system patrons typed in a number corresponding to their service selection. Web browsers like Netscape may appear intuitive to experienced computer users. However, we have found that the level of computer expertise on the campus is not high, and many patrons find their initial contact with Web browsers disorienting. We have found though, that once they get used to using the new system, they find it far superior to the old menus. We also believe that this barrier can be overcome through workshops that are regularly run by the education department.
A second, far more important issue, is the shortage of bandwidth to handle the ever increasing size of data transferred over our network. Client/Server solutions allow for a great expansion in the types of services that can be offered. In general, this means that greater amounts of data are transferred over the network and a bandwidth shortage begins to occur. Since the networking infrastructure of the campus is insufficiently developed to begin with, the increased load stresses the system even more. The lack of a fully developed network infrastructure is one of the primary limiting factors on the further development of Client/Server technologies. Many members of the TJU community must use dial up lines to access JEFFLINE while they are on campus! This problem also exists for those individuals who wish to access JEFFLINE from their homes. With the consequent decrease in speed that modems imply, obstacles are placed in the way of users who want to use multimedia software from remote sites.
Lynx, a text based Web browser, has provided a partial solution to this problem. While many of the features that make the web so powerful are removed by using a text only browser, individuals still find it a convenient tool for accessing JEFFLINE and other Internet sites.
Our initial statistics indicate that despite the absence of multimedia capabilities, users find text based web browsers such as Lynx a significant improvement over the DCL based menu system. The advantages of using dispersed hardware platforms are maintained with Lynx, even if the multimedia components of the Web are lost. Lynx will continue to play a significant role in any future information strategies that are developed until the network infrastructure of Jefferson, and the country as a whole, are improved.
Client/Server solutions of any kind presuppose that an institution has made a major commitment to building and maintaining its network infrastructure. Jefferson, like many institutions, has significant discrepancies in the extent to which different buildings and floors are networked. There are many people on campus who can reach JEFFLINE only through a modem. Jefferson has recently committed substantial capital resources to improve its network infrastructure. We hope that in the near future at least everyone who is on the campus can be directly connected to the network. Home users currently can use ISDN, or the implementation of a serial line protocol for TCP/IP such as PPP. The Systems Department is currently exploring using PPP to access JEFFLINE. The initial results have been quite encouraging even though there are still quite a few management and technical issues to sort out. However, the ever increasing quantity of data being transferred over the net, such as large scale images and QuickTime movies, raises the question of how much bandwidth is enough. There are reasons to believe that even the 10 megabit networks in existence may not prove adequate to handle the load. Eventually, the university will have to move to one of the new 100 megabit protocols that are coming into existence. This will involve yet another significant investment of capital in the networking infrastructure.
Another problem has arisen in regards to the net. The net is a shared resource which is heavily used by AISR, but managed by the Department of Information Systems. This means that while network problems may cripple our ability to offer services, we often are not able to troubleshoot the problem ourselves, because in many instances, the problem does not stem from our equipment. To deal with these issues in the future, the AISR Systems Department and the Department of Information Services will need to maintain close cooperation in order to ensure the reliable delivery of information resources.
One problem the Web has not solved is the diverse interfaces users encounter once they run software supplied by various vendors. While the Web based menus provide a means of creating friendly and consistent looking interfaces, the individual software packages that make up JEFFLINE, such as Ovid from CD Plus, or our OPAC, use different interfaces. This is a problem endemic to the computer industry as a whole and not just JEFFLINE. Given the present state of the computer industry it is unlikely that a complete solution to this problem will arise in the near future. One possible solution is that as the WEB begins to become more and more common, software developers will use it as their front end. We are presently investigating a new OPAC, called Sirsi, which provides a WEB based interface to its product. Hopefully, the use of Web based interfaces will be adopted by other software vendors.
As we have pointed out several times in order to make full use of the capabilities of the WEB patrons must use a microcomputer, either MAC or PC, which is directly connected to the Internet. As we move towards replacing our old interface with a WEB based interface we will also need to replace our VT terminals with microcomputers. This involves a significant increase in capital expenditure since the average microcomputer costs approximately $2000.00, while VT terminals costs less then $500.00. In addition, the maintenance and management costs of microcomputers seem to be higher than that for VT terminals. There are far more things that can go wrong with a microcomputer than with a terminal. Setup time is also increased.
All of this means that more labor will have to be expended managing a C/S based system. This seems consistent with the reports coming from other sites who are migrating towards C/S platforms. The dollar cost of this increase in management time has yet to be measured.
Conclusion
In the next five years the Systems Department will be presented with a set of new technical challenges. The migration of JEFFLINE to a C/S system is at best half finished. Many of our databases are still based on standalone computer technologies, and we are still heavily dependent on the use of text based VT100 terminals. In the next year we hope to replace these terminals with microcomputers, and to gradually introduce C/S versions of our most important databases. However, even as we do this we are becoming aware of the limitations faced by this technology. Inevitably, the present ethernet based configuration of our network will prove to be inadequate to handle the ever increasing traffic that the Web provides. In the next five years we hope to replace our ten megabit network with one of the emerging 100 megabit protocols. Whether it will be fast ethernet, FDDI or ATM remains to be seen. We also plan to implement a technology which will allow dial in users, an important part of our user base, to access the multimedia capabilities of our new menu system. As described above they are presently limited to using LYNX, a text only Web browser. As of this writing PPP seems to be the technology of choice. We hope to implement some type of dial in modem pool connected to a PPP server, such as TribeLink's PPP server, in the next year. Our CD ROM network runs on a Novell network, and users not connected to the campus backbone are not able to access it. We are faced with the challenge of integrating this LAN into JEFFLINE, permitting access from remote sites. The future should be quite exciting!
