The present invention relates generally to the field of computer software development tools. It relates in particular to the generation of executable software components based on existing structured data in non-component-based languages to access the contents of the structured data at runtime.
Much of the new software development projects are moving to object-oriented development environments from the existing procedural, structured development environments. More progressive development environments also exploit the use of component-based design, which is an extension of object-oriented programming techniques. Developers have confirmed what computer science predicted a couple of decades ago—namely that object-oriented and component-based design yields more maintainable and reusable code. Given the complexity of modern network-based or “e-Business” applications, there is a strong desire among businesses to utilize modern development languages and techniques to manage the complexity.
One of the most popular programming languages for the development of network-centric applications is Java®. Java, developed by Sun Microsystems, is an object-oriented, multithreaded, platform independent programming language. The design of the language, coupled with the rich set of available class libraries along with the specification of a component model, called JavaBeans®, within the language make it well-suited to develop applications that interact with other business applications or customers via the World Wide Web.
One component framework built by Sun Microsystems for the Java environment is the JavaServer Pages (“JSP”) framework. A JSP document contains a mixture of a text-based markup language (usually HTML but it can also be an XML-derived grammar) with small segments of Java code and JSP-specific tags. This all-text document is dynamically translated into Java source code and compiled dynamically into a Java binary file that is suitable for execution within a Java Virtual Machine environment. At present, JSPs are used primarily as a technique to separate the business logic in server-based Java applications (“servlets”) from the presentation of the data to a web browser in HTML.
As companies create a presence on the Internet for business-to-business transactions and business-to-customer transactions (“web transactions”), there is a strong desire to use the design methodologies and language support for object-orientation and component based design. However, most of the application logic and data that are required to complete a web transaction are contained within existing procedural code. This procedural code was developed using languages such as COBOL and PL/I that are poorly-suited to network-based programming inherent in building web transactions. Furthermore, this business-critical procedural code was developed and is maintained by programmers who, by and large, do not have the skills in object-oriented design and development and component-based software architectures. Even for companies that have strong programmer skills in modern programming languages and software development techniques, there are substantial barriers in facilitating web transactions from an existing procedural code base. It is inherently cost-prohibitive to recreate the business applications in an object-oriented programming language such as Java. Even if the funding could be justified, the time-to-market is too long to meet business goals. Most companies have recently completed reinvesting in their existing procedural code base to ensure that it is compliant for date processing in the year 2000 (“Y2K compliant”). This indicates a strong willingness by corporations to continue to gain benefit from the existing base of code instead of simply replacing it.
Companies wanting to engage in e-Business face two conflicting desires. The first is the desire to manage software complexity inherent in web transactions with modern object and component-based programming languages. The second is the desire to continue to leverage business logic and data found in the existing applications developed with procedural programming languages and techniques.
One popular technique to bridge existing systems and new systems is the use of the Extended High-Level Language Application Programming Interface (“EHLLAPI” or “screen scraping”). The term “screen scraping” is indicative of how the solution operates. Applications are developed, presumably using modern development languages, to mimic the behavior of a human terminal user. The software reads (“scrapes”) the textual information from the terminal display and interprets the data much as a human would. Similarly, feedback is provided to the existing system by the new application simulating the entry of keystrokes by a human. This simulation of human terminal interaction with software is problematic. The nature of such applications is highly process-oriented, and at first glance, would appear to be easily automated in software. However, humans are vastly more capable of intelligent screen navigation than is present software. Humans are also able to recognize out-of-context situations, such as error screens or indications that the host computer is unavailable. The design of screen navigation logic and error detection and recovery logic is often as complicated as the network programming and complexities of web transactions that the solution was trying to avoid. The screen scraping solution often runs into problems of scalability and performance. The conventional or legacy software systems were designed to interact with dozens or perhaps hundreds of corporate terminal users. When these legacy software systems become the conduit for thousands or millions of Internet users, the architecture often fails to scale to meet the demand.
Another technique to bridge between web transactions and existing systems is to access the persistent data directly. Such a bridge is described in U.S. Pat. No. 6,081,808 (IBM patent) wherein the data from the legacy system is directly accessed, but the business logic of the legacy application is not applied. While workable solutions exist for accessing databases from client/server or network-centric applications, this technique completely bypasses the business rules that apply to the raw data. Most data processing systems of any complexity are more than the presentation of stored data. They use software applications to manipulate the data into usable information. Therefore, a great need exists for a method of accessing and incorporating the complexity of legacy processing system applications with the accessing of the legacy data while dynamically manipulating that legacy logic and data for use on present day object-oriented environments.
Other solutions to bridging the gap between modern multi-tier object-oriented network-centric applications and the existing procedural legacy applications exist in middleware products such as IBM's® MQSeries or the distributed features in IBM's CICS product. Even with these middleware products, there is a need for programmers to understand the differences in the underlying binary data formats of the legacy computing platform and the architecture of the platforms on which the object-oriented systems run. When data is passed between platforms, data conversion must be programmed to account for the architectural differences. For example, for each field in each record that is a text field, such as a person's name, if the source information comes from an IBM S/390 mainframe system, each letter will have to be converted from the internal mainframe EBCDIC encoding to the Java Unicode encoding for alphabetic letters. There is also an issue with the ordering of bytes in different computer architectures. For example, the number 6,091,960 is represented on an Intel Pentium® machine architecture as the hexadecimal number B8F45C00 whereas the same number on an IBM S/390 mainframe is represented internally as 005CF4B8. (Note that the ordering of the hexadecimal pairs of digits are backward with respect to each other). The code to translate all of the internal data type representations is error-prone due to the need for programmers to understand all of the machine architectures they will encounter and the low, bit-level manipulation that is required for many of the translations. The present invention provides a unique solution to the problem of bridging web transactions to existing applications.