Transaction service independent HTTP server-to-transaction gateway

I claim:

1. In a data processing system having a HyperText Transport Protocol (HTTP) server for responding to requests from one or more external browser programs coupled to the HTTP server, a transaction processing system having transaction services for providing access to respectively coupled databases, wherein the transaction processing system processes transactions of a predetermined type and outputs transaction data in data structures having a predetermined format, an apparatus for receiving transaction requests and associated input transaction data from the browser programs and in response thereto, serving output transaction data to the browser programs, the apparatus comprising:

a predetermined number of transaction gateway clients, each coupled to said HTTP server and coupled to said transaction processing system and each being capable of translating a transaction request and associated input transaction data from a browser program into a predetermined transaction type to be processed by the transaction processing system, and each further being capable of translating results of the transaction request received from the transaction processing system into a predetermined format which is provided to the browser program as output transaction data.

2. The apparatus of claim 1, wherein said predetermined format for the browser program is hyper-text markup language.

3. The apparatus of claim 1, wherein each of said predetermined number of transaction gateway clients, is ready for processing prior to receipt of a request from a browser program.

4. The apparatus of claim 3, wherein said predetermined number of transaction gateway clients each have preestablished and static connections with the transaction processing system, whereby time associated with connecting a transaction gateway client to the transaction processing system to process a request from a browser program is eliminated.

5. The apparatus of claim 1, wherein the requests from the browser program are translated into On-Line Transaction Processing (Open/OLTP) style transactions.

6. The apparatus of claim 1, further comprising:

a variable number of dynamically initiated gateway link threads resident on the HTTP server, each for connecting with an available one of said predetermined number of transaction gateway clients in response to a request from a browser program.

7. In a data processing system having a HyperText Transport Protocol (HTTP) server for responding to requests from one or more external browser programs coupled to the HTTP server, a transaction processing system having transaction services for providing access to respectively coupled databases, wherein the transaction processing system processes transactions of a predetermined type and in response thereto, provides transaction data in data structures having a predetermined formats, a method for providing a HTTP interface to the transaction processing system, comprising the steps of:

(a) translating a request and request data received from a browser program into a transaction of a predetermined type;

(b) initiating the transaction processing system to process said transaction of said predetermined type;

(c) translating the transaction data received from the transaction processing system into a predetermined format for the browser program; and

(d) returning the transaction data from said translating step to the HTTP server for returning to the browser programs.

8. The method of claim 7, further comprising the step of:

pre-establishing a predetermined number of transaction gateway clients, each for performing steps (a)-(d) for a respective request from a browser program, whereby each said client is ready for processing prior to receipt of a request from a browser program.

9. The method of claim 8, wherein said predetermined format for the browser program is hyper-text markup language.

10. The method of claim 9, wherein the requests from the browser program are translated into On-Line Transaction Processing (Open/OLTP) style transactions.

11. The method of claim 8, further comprising the step of

pre-establishing static connections between said predetermined number of transaction gateway clients and the transaction processing system, whereby time associated with connecting one of said predetermined number of transaction gateway clients to the transaction processing system to process a request from a browser program is eliminated.

12. The method of claim 11, further comprising the step of

dynamically initiating gateway link threads by the HTTP server in response to requests from browser programs, each for connecting with an available one of said predetermined number of transaction gateway clients and transferring a request to said available one of said predetermined number of transaction gateway clients.

13. In a data processing system having a HyperText Transport Protocol (HTTP) server for responding to requests from one or more external browser programs coupled to the HTTP server, a transaction processing system having transaction services for providing access to respectively coupled databases, wherein the transaction processing system processes transactions of a predetermined type and in response thereto provides transaction data in data structures having a predetermined formats, an apparatus for providing a HTTP interface to the transaction processing system, comprising:

means for translating a request from a browser program to a transaction of a predetermined type;

means for initiating processing by the transaction processing system of said transaction of said predetermined type;

means for receiving the transaction data from the transaction processing system in response to processing said transaction, and for further translating the transaction data into a predetermined format for the browser program; and

means for returning the transaction data from said translating step to the HTTP server for returning to the browser programs.

14. The apparatus of claim 13, further comprising:

means for pre-establishing one or more transaction gateway clients, each for performing steps (a)-(d) for a respective request from a browser program, whereby each said client is ready for processing prior to receipt of a request from a browser program.

15. The apparatus of claim 14, wherein said predetermined format for the browser program is hyper-text markup language.

16. The apparatus of claim 15, wherein the requests from the browser program are translated into Open/OLTP style transactions.

17. The apparatus of claim 14, further comprising

means for pre-establishing static connections between said one or more transaction gateway clients and the transaction processing system, whereby time associated with connecting a transaction gateway client to the transaction processing system to process a request from a browser program is eliminated.

18. The apparatus of claim 17, further comprising

means for dynamically initiating gateway link threads by the HTTP server in response to requests from browser programs, each for connecting with an available one of said one or more transaction gateway clients and transferring a request to said available one of said one or more transaction gateway clients.

19. In a data processing system having a HyperText Transport Protocol (HTTP) server for responding to requests from external browser programs, a transaction processing system having transaction services for providing access to respectively coupled databases, each service capable of respectively performing selectable predetermined functions, wherein function requests and function results are communicated in buffers having predetermined formats, a method for providing a HTTP interface to a transaction processing system, comprising the steps of:

(a) reading a service name, a function name, a command field name, data field names, and associated values from a request from a browser program;

(b) allocating memory for a buffer;

(c) writing at predetermined locations in said buffer said values which were read from the browser request;

(d) initiating the transaction processing system with said service name and the buffer; upon receiving in the buffer a transaction response from the transaction processing system, performing steps (e)-(h);

(e) reading values of the data field names from the buffer;

(f) creating an HTML document having a predetermined format;

(g) writing to said HTML document said values from step (a) at predetermined locations; and

(h) transferring the HTML document to the HTTP server.

20. The method of claim 19, further comprising the step of

pre-establishing a predetermined plurality of transaction gateway clients, each for performing steps (a)-(h) for a respective request from a browser program, whereby each said client is ready for processing prior to receipt of a request from a browser program.

21. The method of claim 20, further comprising the step of

dynamically initiating gateway like threads by the HTTP server in response to requests from browser programs, each for connecting with an available one of said transaction gateway clients and transferring a request to said available one of said transaction gateway clients.

22. In a data processing system having a HyperText Transport Protocol (HTTP) server for responding to requests from external browser programs, a transaction processing system having transaction services for providing access to respectively coupled databases, each service capable of respectively performing selectable predetermined functions, wherein function requests and function results are communicated in buffers having predetermined formats, a method for providing a HTTP interface to a transaction processing system, comprising the steps of:

(a) establishing a hyper-text markup language (HTML) template that is associated with a predetermined function, said HTML template including a service name that identifies a predetermined transaction service, a function name that identifies said function, a predetermined database command field name, and predetermined database data field names;

(b) reading a service name and a function name from a browser request;

(c) allocating memory for a buffer;

(d) reading a command field name, data field names, and associated values from the browser request;

(e) writing at predetermined locations in said buffer said values which were read from the browser request;

(f) initiating the transaction processing system with said service name and the buffer; upon receiving in the buffer a transaction response from the transaction processing system, performing steps (g)-(j);

(g) reading values of the data field names from the buffer;

(h) creating an HTML document from the HTML template;

(i) writing to said HTML document said values from step (a) at locations reserved by respective data field names; and

(j) transferring the HTML document to the HTTP server.

23. The method of claim 22, further comprising the step of

pre-establishing a predetermined plurality of transaction gateway clients, each for performing steps (b)-(j) for a respective request from a browser program, whereby each said client is ready for processing prior to receipt of a request from a browser program.

24. The method of claim 23, further comprising the step of

dynamically initiating gateway link threads by the HTTP server in response to requests from browser programs, each for connecting with an available one of said transaction gateway clients and transferring a request to said available one of said transaction gateway clients.

25. In a data processing system having a HyperText Transport Protocol (HTTP) server for responding to requests from external browser programs, a transaction processing system having transaction services for providing access to respectively coupled databases, each service capable of respectively performing selectable predetermined functions, wherein function requests and function results are communicated in buffers having predetermined formats, a method for providing a HTTP interface to a transaction processing system, comprising the steps of:

(a) establishing a hyper-text markup language (HTML) template that is associated with a predetermined function, said HTML template including a service name that identifies a predetermined transaction service, a function name that identifies said function, a predetermined database command field name, and predetermined database data field names;

(b) establishing a template-to-buffer mapping table which is associated with said function and has mappings of said command field name and said data field names to predetermined offsets into a buffer;

(c) reading a service name and a function name from a browser request;

(d) selecting the mapping table associated with the function name;

(e) allocating memory for a buffer;

(f) reading a command field name, data field names, and associated values from the browser request;

(g) obtaining from said mapping table from said selecting step offsets associated with said database command field name and said database data field names read from the browser request;

(h) writing at locations respectively indicated by said offsets from said obtaining step said values which were read from the browser request;

(i) initiating the transaction processing system with said service name and the buffer; upon receiving in the buffer a transaction response from the transaction processing system, performing steps (j)-(m);

(j) reading values of the data field names from the buffer as respectively specified by said offsets from said obtaining step;

(k) creating an HTML document from the HTML template;

(l) writing to said HTML document said values from step (a) at locations reserved by respective data field names; and

(m) transferring the HTML document to the HTTP server.

26. The method of claim 25, further comprising the step of

pre-establishing a predetermined plurality of transaction gateway clients, each for performing steps (c)-(m) for a respective request from a browser program, whereby each said client is ready for processing prior to receipt of a request from a browser program.

27. The method of claim 26, further comprising the step of

dynamically initiating gateway link threads by the HTTP server in response to requests from browser programs, each for connecting with an available one of said transaction gateway clients and transferring a request to said available one of said transaction gateway clients.

28. In a data processing system having a HyperText Transport Protocol (HTTP) server for responding to requests from one or more external browser programs coupled to the HTTP server, a transaction processing system having transaction services for providing access to respectively coupled databases, each service capable of respectively performing selectable predetermined functions, wherein the transaction processing system processes transactions of a predetermined type and outputs transaction data in data structures having predetermined formats, the data processing system further including a transaction gateway client capable of translating requests and responses between the HTTP server and the transaction processing system, a method for interfacing the HTTP server with the transaction processing system, comprising the steps of:

pre-establishing a predetermined plurality of transaction gateway clients, whereby each client is ready for processing prior to receipt of a request from a browser program;

pre-establishing static connections between said gateway clients and the transaction processing system, whereby time associated with connecting a transaction gateway client to the transaction processing system to process a request from a browser program is eliminated;

dynamically initiating a gateway link thread by the HTTP server in response to a request from a browser program;

establishing a connection between said gateway link thread and an available one of the gateway clients;

transferring the request from said gateway link thread to said available one of the gateway clients;

translating the request received by said available one of the gateway clients into a transaction of a predetermined type;

initiating the transaction processing system by said available one of the gateway clients with said transaction of a predetermined type, whereby connection time is eliminated by pre-establishing said static connections;

translating transaction data received from the transaction processing system into a predetermined format for the browser program;

returning said transaction data in said predetermined format to said gateway link thread for returning to the browser programs; and

disconnecting said gateway link thread from a respectively connected gateway client process after said transaction data in said predetermined format is returned to the gateway link thread, whereby the gateway client is thereafter available to process a subsequent request from a browser program.

29. The method of claim 28, wherein said predetermined format for the browser program is hyper-text markup language.

30. The method of claim 29, wherein said predetermined transaction type is an Open/On-Line Transaction Processing (Open/OLTP) style transaction.

31. In a data processing system having a memory and having a HyperText Transport Protocol (HTTP) server for responding to transaction requests from external browser programs, a transaction processing system having transaction services for providing access to respectively coupled databases, each of the transaction services for receiving ones of the transaction requests and associated transaction data from the external browser programs in a predetermined first format as specified in an associated web-view file associated with the transaction service, each transaction service further for returning transaction results in the predetermined first format to be provided to a selected one of the external browser programs in a predetermined second format as specified in an associated template file associated with the selected one of the external browser programs, a method for providing an HTTP interface to a transaction processing system, comprising the steps of:

(a) reading transaction data and a transaction service name identifying an identified transaction service from a transaction request received from one of the external browser programs;

(b) reading an associated web-view file for said identified transaction service;

(c) translating said transaction data from said step (a) into a predetermined first format specified by said associated web-view file for said identified transaction service; and

(d) providing said translated transaction data to the transaction processing system for processing by said identified transaction service.

32. The method of claim 31 and further comprising the steps of:

(e) receiving transaction results provided by the transaction processing system, said transaction results being provided in a results buffer in the memory and being the results of said transaction request of said step (a) as processed by said identified transaction service;

(f) reading an associated template file for said identified transaction service;

(g) translating said received transaction results into an associated predetermined second format specified by said associated template file read in said step (f); and

(h) providing said translated transaction results to the HTTP server.

33. The method of claim 32 wherein said transaction results received in said results buffer includes one or more data fields each containing associated data signals, wherein said associated web-view file maps each of said one or more data fields to an associated address offset value in said results buffer, and wherein said receiving step (e) comprises the step of reading, for each of said one or more data fields, said associated data signals from an associated address in said results buffer as determined by said associated address offset value.

34. The method of claim 33 wherein said template file includes an associated document address offset value for each of said one or more data fields, and wherein said translating step (g) comprises the steps of:

(g1) creating a document in the memory having a predetermined format; and

(g2) writing said associated data signals for each of said one or more data fields to a location in said document as determined by said associated document address offset value.

35. The method of claim 34 wherein said document is in the form of an HyperText Markup Language (HTML) document.

36. The method of claim 31 wherein said transaction data includes multiple data fields each containing associated data signals, wherein said associated web-view file maps each of said multiple data fields to an associated address offset value, and wherein said translating step (c) comprises the steps of:

(c1) allocating memory to be used as a view buffer;

(c2) writing said associated data signals associated with each of said multiple data fields to a predetermined location within said view buffer as determined by said associated address offset value.

Description Submit all comments and votes

BACKGROUND

1. Field of the Invention

This invention generally relates to gateway processors for providing access to database management systems by browser programs, and more particularly to a generalized gateway processor for making various transaction databases accessible by browser programs.

2. Description of the Related Art

The methods by which companies conduct business with their customers are undergoing fundamental changes, due in large part to World Wide Web technology. In addition, the same technology that makes a company accessible to the world, may be used on internal company networks for conducting operational and administrative tasks.

One of the technologies underlying the World Wide Web is the Web Browser. Web Browsers are quickly becoming a de facto user interface standard because of their ability to interpret and display information having standard formats (e.g., HyperText Markup Language (HTML), standard text, GIF, etc.). Client software programs, popularly referred to as Web Browsers (e.g., Mosaic, Lynx, etc.), execute on client systems and issue requests to server systems. The server systems typically execute HyperText Transport Protocol (HTTP) server programs which process requests from the Web Browsers and deliver data to them. The system that executes a HTTP server program and returns data to the Web Browser will hereinafter be referred to as a Web Server System. An HTTP server program itself will be referred to as Web Server.

A Web Server System has access to on-line documents that contain data written in HyperText Markup Language (HTML). The HTML documents contain display parameters, capable of interpretation by a Web Browser, and references to other HTML documents and Web Servers (Source: World Wide Web: Beneath the Surf, from UCL Press, by Mark Handley and Jon Crowcroft, on-line at http://www.cs.ucl.ac.uk/staff/jon/book/book.html).

As Web Browsers are making their mark as a "standard" user interface, many businesses have a wealth of information that is managed by prior art database management systems such as DMS, RDMS, DB2, Oracle, Ingres, Sybase, Informix, and many others. In addition, many of the database management systems are available as resources in a larger transaction processing system.

One key to the future success of a business may lie in its ability to capitalize on the growing prevalence of Web Browsers in combination with selectively providing access to the data that is stored in its databases. Common Gateway Interface programs are used to provide Web Browser access to such databases.

The Common Gateway Interface (CGI) is a standard for interfacing external applications, such as Web Browsers, to obtain information from information servers, such as Web Servers. The CGI allows programs (CGI programs) to be referenced by a Web Browser and executed on the Web Server system. For example, to make a UNIX database accessible via the World Wide Web, a CGI program is executed on the Web Server system to transmit information to the database engine, receive the results from the database engine, and format the data in an HTML document which is returned to the Web Browser.

A disadvantage with the CGI program approach described above is that the application developer must be acquainted with the HTML, the CGI, and the database engine. In addition, a different CGI program may be required for each different database, thus adding to the cost of creating and maintaining the database access for the Web Browser.

Businesses are faced with the challenge of adapting their present usage of yesterday's technology to new opportunities that are made available with the World Wide Web. Most business application software and underlying databases are not equipped to handle interaction with Web Browsers. It would therefore be desirable to have a flexible and efficient means for allowing interoperability between business application software and the World Wide Web.

SUMMARY OF THE INVENTION

The present invention makes prior art on-line transaction processing (OLTP) systems and their associated databases accessible using HyperText Transport Protocol (HTTP) interfaces. The response time for an on-line user seeking HTTP access to the transaction processing system is minimized by pre-establishing a transaction gateway client having a static connection to the transaction processing system. In addition, the HTTP access to the transaction processing system is available for multiple concurrent users. The invention further provides a gateway that is independent of the underlying service provided by the transaction processing system, whereby the same gateway client is capable of usage with different databases and operations thereon.

An on-line transaction processing system is made accessible to Web Browsers by establishing a predetermined plurality of transaction gateway clients to receive HTTP requests that are received by a Web Server from the Web Browsers. Concurrent processing of multiple transaction requests from the Web Browsers is performed by the plurality of transaction gateway clients. Each transaction gateway client pre-establishes a static connection with the on-line transaction processing system. The pre-established connection allows requests from the Web Browsers to be quickly routed to the transaction processing system. Time is saved by elimination of the traditional steps of connecting with and then disconnecting from the transaction processing system for each request from a browser program. The gateway client translates between HTTP formatted requests from the Web Browsers and the request format expected by the on-line transaction processing system.

The invention handles multiple concurrent requests from the Web Browsers and makes the requests available for concurrent processing by the on-line transaction processing system. A predetermined number of instances of the transaction gateway client are established to be available for performing the necessary translations. Each of the instances of the transaction gateway client establishes a static connection with the on-line transaction processing system as described above. As requests are received by the Web Server from the Web Browsers, the requests are routed to an available one of the instances of the transaction gateway client. Each instance of the transaction gateway client is capable of processing one request at a time.

The transaction gateway client of the present invention is independent of the underlying service initiated by the on-line transaction processing system. For example, the transaction gateway client may be utilized with different database managers (the database manager being the service), so long as the on-line transaction processing system is capable of utilizing the services provided by the different database managers. Multiple styles of transaction gateway clients may be established, however, to interface with different styles of on-line transaction processing systems and to accommodate differences in data format requirements.

The independence of the transaction gateway client from the underlying service is accomplished with each HTTP request from a Web Browser program specifying a requested service and a respective predetermined mapping file for each available service. A predetermined HyperText Markup Language (HTML) template file is also established for each desired service. Each of the predetermined mapping files sets forth the format and content of the data buffer that is used for communicating between the transaction gateway client and the on-line transaction processing system for the particular service. A mapping file directs the transaction gateway client where to write data to and read data from the data buffer for predetermined fields of the database. The HTML template file is used in creating an HTML document that is returned to a Web Browser. The transaction gateway client reads data values from a data buffer returned from the transaction processing system (as specified by the mapping file), the data values are written to appropriate locations in the HTML document as directed by information contained in the HTML template file.

Still other objects and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein only the preferred embodiment of the invention is shown, simply by way of illustration of the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of a computing environment in which a transaction system and a Web Server interoperate in a single system;

FIG. 2 is a functional block diagram of an exemplary computing environment in which the present invention could be used;

FIG. 3 is a functional block diagram of the software components that make a transaction database accessible to one or more Web Browsers;

FIG. 4 is a dataflow diagram showing the flow of data between the components of the exemplary system;

FIG. 5 is a flowchart of the steps for initializing an environment on a Web Server System to provide Web Browser access to a transaction database;

FIG. 6 shows the relationship between the Web-View File and the View Buffer;

FIG. 7 illustrates a portion of the HTML Template created for the View Definition of FIG. 8;

FIG. 8 illustrates a sample View Definition;

FIG. 9 is a sample screen display of the image produced by a Web Browser from an HTML document based on the HTML Template;

FIG. 10 is a flowchart of the general processing of the Web Server;

FIG. 11 is a flowchart of the processing performed by a Gateway Link thread; and

FIG. 12 is a flowchart of the processing performed by each of the instances of the Transaction Gateway Client.

DETAILED DESCRIPTION

FIGS. 1 and 2 are functional block diagrams of exemplary computing environments in which the present invention could be used to make a transaction processing system interoperable with the World Wide Web. FIG. 1 is a functional block diagram of an environment in which the transaction system and the Web Server operate in a single system, and FIG. 2 shows an environment in which the Web Server System acts as a front-end for the Enterprise Server System.

FIG. 1 is a functional block diagram of a computing environment in which a transaction system and a Web Server interoperate in a single system. A plurality of micro-computers, designated as Web Browser 10, 12, 14, and 16, are coupled to a Web Server 18 via Network 20. The Network may be an internal local area network or the Internet.

Each of the Web Browsers 10-16 is comprised of software for browsing the World Wide Web, such as Mosaic, Netscape Navigator, etc., and a suitable micro-computer or computer workstation along with operating system software. The Web Server may be off-the-shelf software such as the Microsoft Internet Information Server and Netscape Commerce Server.

The typical operating mode for the Web Server 18 is to receive requests from the Web Browsers 10-16 and return the requested data from the Pre-formatted Data element 22. The Pre-formatted Data consists of HTML documents.

The Server System 24 may be any data processing system that is suitable for transaction processing applications, such as the 2200 Series, A-Series, and UNIX based data processing systems from Unisys Corporation. The exemplary Transaction Processing System 26 is intended to encompass transaction manager software, such as Open/OLTP Transaction Manager software from Unisys, user implemented Open/OLTP services (application programs), and Open/OLTP resource managers (such as a database management system). The Open/OLTP transaction model is described in the X/Open Guide, Distributed Transaction Processing Reference Model as published by the X/Open Company Ltd., U.K. The present invention would be applicable to other non-standard or proprietary transaction based systems, as well as to other data servers in general.

The Transaction Processing System 26 serves data from the Database 28 to the Transaction Clients 30, 32, 34, and 36. The Transaction Clients 30-36 are coupled to the Transaction Processing System via Line 38, of which the underlying technology is driven by the application of the Transaction Processing System 26.

The Transaction Gateway Client 40 allows the Web Server 18 to interoperate with the Transaction Processing System 26. Specifically, a predetermined Open/OLTP service, as defined by an application programmer, is referenced in an HTML document in the Pre-formatted Data element 22. When a Web Browser 10, 12, 14, or 16 selects the service, the request is routed to the Web Server 18, which in turn routes the request to the Transaction Gateway Client. The Transaction Gateway Client determines the requested service and forwards the necessary information to the Transaction Processing System 26. The Transaction Processing System processes the request against the Database 28 according to the specified request (e.g., select, update, delete). The Transaction Processing System returns data and/or status information to the Transaction Gateway Client, which in turn formats the data into an HTML document that is forwarded to the Web Server. The Web Server sends the HTML document to the requesting Web Browser.

FIG. 2 is a functional block diagram of an exemplary computing environment in which the present invention could be used. The environment of FIG. 2 differs from that of FIG. 1 in that the Web Server 18 and the Database 28 reside on separate data processing systems. The Web Server 18 resides on a Web Server System 50, and the Database 28 resides on an Enterprise Server System 52.

The Web Server System 50 may be any class machine that is capable of running a Web Server 18 along with a Distributed Transaction Processor 54. In the exemplary Web Server System, the Distributed Transaction Processing System 54 is similar to the Transaction Processing System 26 of FIG. 1 in that both are Open/OLTP compatible. The Transaction Processing System 54 of FIG. 2 is designated as Distributed to make clear that a transaction is formatted on the Web Server System 50 and forwarded to the Enterprise Server System for processing. A suitable Distributed Transaction Processing System 54 for the Web Server System is the Transactional Desktop software product from Unisys. The Transactional Desktop software is Open/OLTP compliant, but does not have the required components for processing service requests. However, the Transactional Desktop software is capable of initiating service requests.

The exemplary Enterprise Server System is a 2200 Series data processing system from Unisys and also includes a Distributed Transaction Processing System 56. The Distributed Transaction Processing System 56 is intended to encompass the same functionality as the Transaction Processing System 26. However, it is designated as Distributed to be compatible with the Distributed Transaction Processing System 54. The Distributed Transaction Processing System 54 and the Distributed Transaction Processing System 56 are coupled via Network 58. Preferably, the network interface for Network 58 is separate from the network interface for Network 20.

The environment of FIG. 2 may be preferable to the environment of FIG. 1 in that the Web Server System 50 maybe used prevent request from the Web Browsers 10-16 from entering Network 58. The Windows NT operating system is configurable to prevent routing of data packets between two network interfaces. In this fashion, the only traffic that is allowed on Network 58 in response to requests on Network 20 is in the form of Open/OLTP service calls which are referenced by HTML documents.

FIG. 3 is a functional block diagram of the software components that make a transaction database accessible to one or more Web Browsers. Before discussing the various software components, it may be useful to illustrate a high level data flow between the components.

The data flow is illustrated by the labeled directional arrows 72, 74, 76, and 78. The Web Server 18 receives Uniform Resource Locator (URL) character strings from the Web Browsers 10, 12, 14, and 16. URL character strings are passed to the Transaction Gateway Client instances 40, which in turn translate the URL character strings into View Buffers. View Buffers are passed to the Distributed Transaction Processing System 54 as shown by Line 74, and in turn passed on to the Distributed Transaction Processing System 56. Note that a View Bohfer is a data structure that is understood by the Open/OLTP style Distributed Transaction Processing Systems 54 and 56. The invention would be equally applicable to transaction and/or database systems which expect different data structures. The Distributed Transaction Processing System 56 returns View Buffers to the Distributed Transaction Processing System 54, which in turn returns View Buffers to the Transaction Gateway Client instances 40. The Transaction Gateway Client instances transform the View Buffers into HyperText Markup Language documents which are returned to the Web Server 18 as shown by Line 78. The Web Server returns the HTML documents to the respective Web Browsers.

In terms of the software components that make a transaction database Web Browser efficiently accessible, two main components provide the accessibility. The first component is the Gateway Link Thread 82 and the second is the Transaction Gateway Client 40.

Web Servers such as the Netscape Commerce Server support multiple threads. That is, a single Web Server process is multiplexed between the threads. In the exemplary embodiment, the Web Server software (i.e., Netscape Commerce Server) is configured with a Dynamic Link Library function designated as the Gateway Link. Each of the Gateway Link threads 82, 84, and 86 correspond to a URL received from a respective one of the Web Browsers 10-16. The basic function of a Gateway Link is to establish a connection with an available Transaction Gateway Client instance 40, forward a URL to the Transaction Gateway Client instance, receive an HTML document from the Transaction Gateway Client instance, and return the HTML document to the respective Web Browser. The Gateway Link threads are designated with dashed lines to indicate that their existence is dynamic.

The second main software component is the Transaction Gateway Client 40. The main function of the Transaction Gateway Client is to transform a request which is in the form of a URL from a Web Browser 10-16 into a format which is understandable by the Distributed Transaction Processing Systems 54 and 56, and transform the data returned from the Distributed Transaction Processing Systems 54 and 56 into a HTML document that is returned to a Gateway Link.

In the exemplary embodiment, a predetermined number of Transaction Gateway Client instances are started and available to process requests from the Web Browsers 10-16. Each of the Transaction Gateway Client instances processes one request at a time. An equally suitable approach would be to have one Transaction Gateway Process instance with a multi-thread capability.

Each of the Transaction Gateway Client instances creates an instance of a Named Pipe. The instances of the Named Pipe are collectively referenced as 102. An instance of the Named Pipe is used for communicating between one of the Gateway Link threads 82-86 and an available one of the Transaction Gateway Client instances.

In addition to instances of the Named Pipe 102 , each instance of the Transaction Gateway Client 40 establishes a connection with the Distributed Transaction Processing System 54. This connection is established prior to a Transaction Gateway Client receiving a request from a Web Browser and maintained for the life of the processor instance so that time is not wasted in connecting and disconnecting every time a request appears. In the exemplary system the connection is made with the tpinit program call to the Distributed Transaction Processing System 54. In this manner, each of the Transaction Gateway Client instances has a preestablished and continuous connection with the Distributed Transaction Processing System 54. The connections between the Transaction Processing System Gateway instances and the Distributed Transaction Processing System are collectively referenced as 104.

Connections between the Distributed Transaction Processing Systems 54 and 56 are established as requests are forwarded from the Transaction Gateway Client instances. The connections are collectively referenced as Lines 106. The connections are designated with dashed lines to indicate that the connections are dynamically established and undone (as compared to the static connections between the Transaction Gateway Client instances 40 and the Distributed Transaction Processor 54).

FIG. 4 is a dataflow diagram showing the fl