Legacy system computer applications that have been executing on mainframe computers, in some cases, for decades, continue to play a vital role in American commerce, education, and industry. Such software, in fact, has vastly outlived the time period during which its creators believed it would be useful. Doubts about the truth of the foregoing proposition vanish in the face of the billions of dollars that have been (or will be) spent by U.S. companies and the United States government in correcting computer code that is not Year 2000 compliant. The vast bulk of this code is substantially more than five years old.
Added to this vast mass of legacy systems are modern systems executing in modern environments, such as the client/server environment. These systems, like the legacy systems, suffer from the same basic limitation--the business logic and associated data are locked up in architecture-specific systems. Those using different operating systems running on computers powered by entirely different central processing units cannot effectively access the data and business logic residing on these conventional systems.
These conventional systems (both the legacy systems and the more modern systems) are not only important, they also represent substantial investments by companies. They are the product of billions of dollars of programmer compensation and untold millions of hours of business planning, strategic design, and work flow description. In many respects, the code embodied in these conventional systems describes the operations of everyday commerce in this country.
Today's technology culture differs widely from the environment that existed when most of these conventional systems were created. Access to computers is no longer limited to an elite handful of technicians with dedicated terminals hooked to gargantuan boxes located in specially cooled rooms. Today, virtually every worker has a personal computer sitting on his/her desk. Others, on the go, carry their computers in brief cases that connect to the home office via telephone lines. Consumers, from their dens and living rooms, are buying and selling stocks, checking their bank accounts, and (in some cases) telecommuting. The need to get the data and business logic out of the hands of the specially trained technicians and into the hands of every day people is great. The demand is the same, and the problem is the same, whether the important data and business logic resides on a legacy system or on a modern client/server system. Accessing and interacting with it from the outside, an external system, is a huge chore.
The demand is great, but, even more importantly, it is growing exponentially--with the explosion in popularity of the Internet and, especially, the World Wide Web. The number of trademark applications alone with terms like "e-biz," "e-business," "e-commerce," and the like is staggering. Clearly, commerce has moved to the net. Virtually no television advertisement and certainly no television news program fails to include a reference to its Internet or World Wide Web address.
Coupled with the popularity of the Internet has been another trend that has silently but markedly transformed the landscape of commerce and, indeed, everyday life in the United States. This is the trend toward self-service. Full service filling stations, for example, have almost been relegated to a dim memory. ATM machines have replaced tellers, and even some banks charge an extra transaction fee for using a human teller, as opposed to an ATM machine. The Internet itself is the ultimate expression of the trend toward self-service. Banking, book buying, car and home shopping, teaching, and even church services are available when the cyber-consumer wants it and without the presence of any human tellers, brokers, clerks, teachers, professors, registrars, or ministers.
Regardless of the computer system on which the application is running, the same basic disability exists. The data and business logic are locked up in an architecture-specific format. Almost universally, raw data is stored in a format shaped primarily by storage constraints, e.g., in relational database tables, and by retrieval considerations, e.g., indexes. This data is presented in business-useful human-friendly form only when acted upon by the architecture-specific computer application that carry out instructions based on business logic. In other words, the data resides in one generally useless format and is put in useful form only when acted upon by a separate computer application, which application is typically architecture-specific in terms of its functionality. Thus, whether the information and business logic are locked up inside a venerable legacy system or are stored in client/server systems in database tables, systems on the outside have difficulty in reaching into these conventional systems for not just the raw data, but the data in a form and format that has been filtered, selected, organized, and processed by intelligence that embodies an organization's business logic.
The problem, as noted above, is not just converting the data from one system to another. Difficult as that problem is, converting the raw data from a format on one magnetic medium to a different format on another medium has been done before. As noted above, however, conversion of the data does not solve the problem. The business logic that sorts, parses, selects, combines, performs operations upon, and presents this data in useful form is left behind. The raw data, even if converted, is just sitting there. It is no longer part of the system. It is just plain data.
In order to make this data, even after it is converted into a form that can be processed by an external system, of any use, it has to be combined with the business logic, e.g., combined with computer code that sorts, parses, selects, combines, presents, and otherwise operates on the data in ways that are meaningful to the business or institution that owns the data. That business logic already exists in the executable code still residing on the conventional system. The business logic needs to be duplicated or replicated in a form that the external system can use.
The process of reinventing the business logic is inefficient, time-consuming, and (in many cases) ineffective. It is inherently inefficient to operate two parallel systems--the conventional system and the external system. The conventional system represents a huge investment of time and money--an investment likely to have painfully escalated with the cost of making these conventional systems Year 2000 compliant. Reinventing these programs in another environment--the environment of the external system--hardly makes sense now. Moreover, the programmers who best know the organization's business logic, as it is embodied in the programs executing on the conventional system, are probably not the people who are best equipped to recreate the business logic in the new (external) environment. Almost by definition, they are trained on and have developed expertise in the environment of the conventional system, not the external system. Thus, if the business logic is to be recreated on the external system, those with the best knowledge of the business logic will need to be retrained in the language of the external system or, in the alternative, the job of recreating the business logic in the external system will be handled by those with no experience in the organization's business logic. Both approaches fall far short of the ideal.
An alternative to the solution described above--translation of the data and recreation of the business logic--would be to graft external system awareness into the conventional system. This approach is best illustrated by the efforts of some to transplant HTML-aware routines, libraries, and tools into legacy systems. Modern flavors of RPG, COBOL, Fortran, and others sport new web awareness tools and extensions. This approach has both advantages and disadvantages.
The main advantage of this approach is that it allows the legacy system programmer to continue to function in the environment in which he/she feels comfortable. These legacy system programmers do not have to become web gurus or become proficient in Java, HTML, and other web-based or web-aware languages.
The disadvantage involves the same problem of duplication mentioned above. The legacy system programmers who have just spent the last two or three years plowing through lines of codes that haven't seen daylight in decades to fix the Y2K problem now have to go through all those lines of code all over again, rewriting them to become not Y2K compliant, but web compliant. In other words, the systems will all have to be modified and/or rewritten using these new web-aware tools.
The applicant's invention permits organizations, companies, and institutions with legacy and other conventional systems to make not only their raw data but their business logic available to external systems without having to create a duplicate system in a parallel external universe and without requiring major code revisions in the conventional systems themselves. The applicant's novel approach takes the data after business logic has been applied within a running program and channels it into the external system environment intact, where the intact data is reconfigured into data that is understandable by the external system.
Moreover, this packaging and processing of intelligent data (data acted upon by the conventional system's business logic) takes place at the "code level." To understand what is meant by the phrase "code level," it is important to understand the preexisting "translation" technology. Because of the inherent differences between legacy system data formatting and language conventions and those popularized by the PC revolution, the most popular translation form is commonly referred to as "screen scraping." This moniker is actually very descriptive of the process that is in fact used. The data and business logic inherent in a legacy system are presented in meaningful, humanly comprehensible form when it is printed on the computer screen. It does not really matter whether the computer screen is hooked to a mainframe computer or a PC connected to the World Wide Web. What meets the human eye is equally comprehensible. The screen scraping technique, therefore, basically uses a series of algorithms to read and/or intercept the display function, scraping, as it were, that human-readable information and piping the result into an image projected on the screen of an external system.
The screen scraping technique has numerous problems. First, it is very computer intensive and very, very slow. Second, it is, of necessity, screen dependent. Screen scraping requires one to model the flow of a particular application. Modeling program flow entails a huge number of complexities, particularly where user input is involved or error recovery is required. When one is literally scraping the screen, it is necessary to anticipate which screen is coming next in program flow. Third, with screen scraping, it is assumed that the screens will be static. If, however, circumstances require modifications to any of the screens, regardless of the reason, further modification to the screen scraping system will be required to avoid errors. Fourth, screen scraping is extremely difficult when the business logic requires one to gather pieces of data from different screens and assemble all those bits and pieces of information together. Fifth, screen scraping is not scalable at all. It is inflexibly dictated by the architecture of the conventional system and the external system. Sixth, the result of screen scraping in the web environment is not particularly desirable. Without substantial further processing, its presentation is less than fully satisfying to the Web-experienced user. Indeed, without additional processing, it may be incapable of interacting with the user. Although, for discussion purposes, the foregoing has focused upon screen-scraping of legacy systems to make them Web-aware, the same issues exist regardless of the types of conventional systems and external systems involved.
Rather than scrape the screen, Applicant's invention involves taking a snapshot of the in-memory data, as it is being processed by the software applications residing on the conventional system. By taking a snapshot, not of the screen, but of the in-memory, real time image of the data, Applicant's invention operates at the code level and, hence, is highly efficient. It is also highly scalable. To interact with the business logic and data residing on the conventional system, conventional system programmers can continue to call upon their conventional system tools and expertise.
The Applicant's invention has none of the limitations that have plagued the prior art solutions. Indeed the disadvantages of the prior art offerings are matched item-by-item by strengths of the applicant's invention. Some of the advantages of the Applicant's invention are that it allows proven functionality to continue, using mature code that has been thoroughly debugged and is reliable. New applications do not have to be written in order to make the business logic and precious data available for interaction by persons operating systems different from the conventional systems. The Applicant's invention is not screen-dependant. Rather, the execution-time in-memory representation of the data, as acted upon by the business logic, is translated and made available to the external systems. At the same time, information from an external system, may be fed into and processed by the conventional system by means of Applicant's invention. In addition, Applicant's invention is scalable to an almost unlimited degree in that, by making the data and business logic available in any external system, including markup language systems, such data and business logic may be accessed and used on any platform. The data and business logic become wholly and completely platform independent. Another benefit is in the nature of human cost. To satisfy the demand for external system access to conventional system data and business logic, including markup language versions of the data and business logic now trapped inside conventional systems, it would be necessary to rewrite the application, with the attendant human costs in terms of both programming and training or retraining. The Applicant's invention also has the advantage of making conventional system data and business logic available to external systems without making huge demands on processor and computing resources.