The present invention relates to a method for providing an Application Programming Interface (API) to existing applications that do not provide this service without modifying their internal operation. Moreover, this API is constructed in such a way that these applications appear to behave as standard Database Management Systems (DBMS). This makes such applications easily controllable from external software, allowing for task automation and also allowing them to participate in cross-application operations such as transactions.
Many modern applications provide programmatic access to the functionality they implement via an Application Programming Interface (API). By allowing this type of access, an API enables automation of common tasks and facilitates integration between disparate applications. Many older, a.k.a. legacy, applications do not provide an API. This deficiency is particularly glaring because these applications often stand to benefit the most from an API. The benefits, which are manifestly evident, include the following:    1. Having withstood the test of time, these are often applications that are at the core of an enterprise's business process.    2. New systems that have been installed since the legacy applications can benefit from integration therewith, and vice versa.    3. Legacy applications often run on legacy hardware, which makes external access to the data difficult.    4. Source code for legacy applications may be in an outdated programming language, or missing altogether. This makes it very difficult to reproduce the business logic that has been encapsulated in the legacy applications.    5. For the same reason, adding new functionality to such applications can also be difficult, impractical, or substantially impossible.
Another type of applications in which an API is generally not exposed at the client side is web applications. These applications run on a central server (web server) and expose their user-interface via a web browser. Such applications can also greatly benefit from an API because:    1. They may be running outside the enterprise, as a service provided by an external provider via the Internet, such as an Application Service Provider (ASP). In this case access to or modification of their source code may be impossible.    2. For the same reason, direct access to the data may also be impossible.    3. Because these applications were generally built to be accessed by a human via the web browser, it may be difficult to integrate them into the business process of an enterprise.
It is possible to graft an API on top of legacy applications without modifying the internal structure of these applications. Such systems are often accessed via specialized hardware (terminals). Over the past several years, this hardware has been replaced by software applications that emulate the behavior of the hardware on modem systems. By building an API into the emulation software, it is possible to achieve most of the same benefits as an API on the original legacy application itself. In the case of web applications, the solution is very similar: creating an application that emulates the browser's behavior and also provides an API.
A useful API must be easily usable from common programming environments/programming languages. In addition, the API should provide a development model that is familiar to users and exposes logical units that match the processes (tasks) that the users wish to perform.
There is therefore a recognized need for, and it would be highly advantageous to have, a method for providing high-level application programming interface for legacy systems that is user-friendly, universal, and adaptable to client applications such as web servers. It would be of further advantage if such a method would support most software, hardware and network configurations.
USPTO Backgrounds
USPTO Backgrounds