Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
1998-10-01
2001-04-03
Maung, Zarni (Department: 2758)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C704S201000, C704S202000, C704S217000, C704S219000, C704S223000, C704S228000, C713S152000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06212546
ABSTRACT:
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention relates generally to interfaces which interface a variety of requester types coupled to a server with a variety of communications programs coupled to an on-line transaction processing system, and more particularly, to such interfaces which isolate attributes of the requesters and the communications programs into individual software components. 2. Description of the Prior Art
The methods by which companies conduct business with their customers are undergoing fundamental changes, due in part to world wide web technology. This same technology which makes a company accessible to customers around the world, may also be used on internal company networks, to complete operational and administrative tasks.
One of the technologies within the world wide web is the web browser. Web browsers are quickly becoming a defacto user interface standard to the world wide web because of their ability to interpret and display information having standard formats (e.g. HyperText Mark-Up Language (HTML), standard text GIF, etc.). Client software programs, typically referred to as web browsers (e.g. Mosaic, Lynx, etc.), execute on client systems and issue requests to server systems. Server systems typically execute HyperText Transport Protocol (HTTP) server programs, and process requests received from the web browsers.
Many businesses still have information maintained and managed by data base management systems such as DMS, RDMS, DB
2
, Oracle, Ingres, Sybase, Informix, and many others. Many of these database management systems are being utilized as resources within larger transaction processing systems. In view of this, businesses have begun to recognize and capitalize on the growing utility of web browsers to provide access to data stored within their database management systems.
To provide the access, software gateways, also known as “middle ware”, execute on the server systems in order to link the web browsers to the data base management systems. A gateway typically receives a user request and associated data from the web browser, and packages the data into a specific format, and forwards the request and data to the data base management system. The data base management system then processes the request, and sends the result back to the gateway. The gateway may then provide the result to the requester in a specified format.
Gateways must accommodate many different types of user requests, as web browsers typically utilize any number of software languages. One type of request may be an application on the web browser which is executing the Java programming language (e.g. a Java applet). This approach is described in U.S. patent application Ser. No. 09/164,759. entitled “A Common Gateway Which Allows Java Applets to Make Program Calls to OLTP Applications Executing on an Enterprise Server” still pending, which has been incorporated herein by reference. Another type of request may be an application running under the MicroSoft DCOM environment. This approach is described in U.S. patent application Ser. No. 09/164,932 entitled “A Multi-client User-customized DCOM Gateway for an OLTP Enterprise Server Application” still pending, which has been incorporated herein by reference. Yet another type of requester is when the Web Browser provides requests in Hyper Text Markup Language (HTML) format. This approach is described in U.S. patent application Ser. No. 08/622,099 entitled “Transaction Service Independent Http Server-to Transaction Gateway”, now U.S. Pat. No. 5,754,772, which has been incorporated herein by reference.
Each of the different types of requests described above require a specific gateway to be serviced. For example, a Java gateway must be provided to service requests from the Java applets. A DCOM gateway must be provided to service requests from applications running under the MicroSoft DCOM environment. And yet another gateway must be provided to support requests from the Web Browser in the HTML format.
These various gateways must also support a wide variety of communications programs which are used to provide communications between the server systems and the database management systems. Each communication program has specific communications protocol requirements, thus requiring unique input and output formats. Examples of communications programs include Pathway (commercially available from the Unisys Corporation), HTP/ic (commercially available from the Unisys Corporation) and COMAPI.
Thus gateways must accommodate many different types of requesters and a variety of communications programs. The gateway typically includes software code which accepts and processes a specific type of requester, which is integrated with the code to interface to the communications programs. For example, if the requester is the Java Applet, the gateway to support the Java Applet must support each type of communications program the Java Applet may access. Thus, for example, three Java gateways must be created if a Java Applet is to have access to three different communications programs such as Pathway, HTP/ic, and COMAPI. The same is true for DCOM and HTML request types.
Thus, in prior art systems where each requester must access a number of communications programs, the required number of gateways resident on the server is equal to the number of requester types times the number of communications programs to which access is required. Unfortunately, this approach requires a potentially large number of different types of gateways. And each time a new communications program is added, a new version of each gateway must be created. Since each new gateway requires customized interfaces involving extensive rewriting of gateway software, this task can be prohibitively time consuming and expensive.
SUMMARY OF THE INVENTION
The present invention overcomes the disadvantages found in the prior art by providing a new gateway architecture which reduces the number of software components required to interface a number of requesters with a number of communications programs. The new interface architecture isolates attributes of the requesters and communications programs into individual software components or modules, so that all software code associated with each requester type is included within a corresponding requester software module, and all software code associated with each communications program is included within a corresponding communications software module. Each requester software module can communicate with every communications software module through a standardized interface consisting of a number of program calls.
The new gateway architecture reduces the amount of software code required to add a new requester or communications program. Each new requester type added requires the addition of only one requester software module, and each new communications program added requires the addition of only one communications software module. This reduces the overall number of software modules required to interface the requesters to the communications programs to a number equal to the number of requesters plus the number of communications programs.
In a preferred embodiment of the present invention, an interface is provided for linking each one of a number of requesters to each one of a number of communications programs. The interface comprises a number of first modules wherein each first module Corresponds to one of the number of requesters. The interface further comprises a number of second modules wherein one of a number of second modules corresponds to one of the number of communications programs. The first modules interface with the second modules by passing a number of function calls between the first modules and the second modules, thus allowing requests to be submitted from the first module to the second module and results to be returned from the second module to the first module.
One of the number of function calls is a first initialize function. The first initialize function is called once when a new requester is added. The first initialize function ma
Gambrel Robert J.
Starkovich Daniel P.
Barot Bharat
Johnson Charles A.
Maung Zarni
Nawrocki, Rooney and Silvertson, P.A.
Starr Mark T.
LandOfFree
Providing a modular gateway architecture which isolates... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Providing a modular gateway architecture which isolates..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Providing a modular gateway architecture which isolates... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2460384