Automatic system for updating data

Abstract

An automatic gateway that runs as an HTML solution and is capable of automatically generating service requests in response to a condition precedent for service by an On-Line Transaction Processing (OLTP) style application running on an enterprise server. The OLTP server provides a result which is utilized by the automatic gateway to update a data presentation. The services on the OLTP system are designed to accomplish a specific task, for example, update the schedules and pricing of an airline. In a preferred embodiment, the OLTP system is X/Open compliant. The users of the system can access the updated data presentation without further communication with the OLTP enterprise server.

Description

CROSS REFERENCE TO CO-PENDING APPLICATIONS

The present application is related to U.S. patent application Ser. No. ______, filed ______, entitled “AN AUTOMATED DEVELOPMENT SYSTEM FOR DEVELOPING APPLICATIONS THAT INTERFACE WITH BOTH DISTRIBUTED COMPONENT OBJECT MODEL (DCOM) AND ENTERPRISE SERVER ENVIRONMENTS”, and application Ser. No. ______, filed ______, entitled “A COMMON GATEWAY WHICH ALLOWS APPLETS TO MAKE PROGRAM CALLS TO OLTP APPLICATIONS EXECUTING ON AN ENTERPRISE SERVER”, both of which are assigned to the assignee of the present invention and incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a communications gateway for providing access to data generated by an enterprise server application from a Distributed Component Object Model (DCOM) environment, and more specifically, to a technique for automatically updating certain data by a call to the Transaction Processing (OLTP) Enterprise Server Application such that the requested data is available to the user without the need for a further service request of the enterprise server.

2. Description of the Prior 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 prospect of using component software technology—the idea of breaking large, complex software applications into a series of pre-built and easily developed, understood, and changed software modules called components—as a means to deliver software solutions much more quickly and at a lower cost (source: DCOM: A Business Overview, online at http://www.microsoft.com/ntserver/guide/dcom.asp). The goal is to achieve economies of scale for software deployment across the industry.

A component architecture for building software applications will enable this by: 1) speeding development—enabling programmers to build solutions faster by assembling software from pre-built parts; 2) lowering integration costs—providing a common set of interfaces for software programs from different vendors means less custom work is required to integrate components into complete solutions; 3) improving deployment flexibility—making it easier to customize a software solution for different areas of a company by simply changing some of the components in the overall application; and 4) lowering maintenance costs—isolating software function into discreet components provides a low-cost, efficient mechanism to upgrade a component without having to retrofit the entire application.

A distributed component architecture applies these benefits across a broader scale of multiuser applications. The Distributed Component Object Model (DCOM), developed by Microsoft Corporation, has several strengths that make it a key technology for achieving this. Because it is an ActiveX technology, DCOM works natively with Internet technologies like TCP/IP, the Java language, and the HTTP network protocol, providing “object glue” that will enable business applications to work across the Web. DCOM is also an open technology that runs on multiple platforms.

DCOM has its roots in Microsoft's object technology, which has evolved over the last decade from DDE (Dynamic Data Exchange, a form of messaging between Windows programs), OLE (Object Linking and Embedding, embedding visual links between programs within an application), COM (the Component Object Model, used as the basis for all object binding), and ActiveX (COM enabled for the Internet). As stated earlier, applications built from components are simply easier to debug and evolve than large, monolithic applications.

The logical boundary for component applications is no longer on a single machine. Businesses want to leverage the benefits of component development across a broader set of shared applications that operate on multiple machines. These types of applications are referred to as “three-tier” or “n-tier” applications, where “tiers” of application logic, presentation services, business services, and information retrieval and management services, are broken into different components that can communicate directly with each other across a network. To the end user, these applications appear as a seamless extension of their existing desktop environment.

The simplicity, ubiquity, and industry momentum of standard Internet protocols like HTTP make it an ideal technology for linking components together for applications that span machine boundaries. HTTP is easy to program, is inherently cross-platform, and supports an accessible, universal naming service. Much of the excitement around the Java language derives from its potential as a mechanism to build distributed component applications on the Internet. In addition to Java support, DCOM enables components written in other languages, including C, COBOL, Basic, and Pascal, to communicate over the Internet, providing a growth path for existing applications to support Web technology.

As distributed component architectures, such as DCOM, are making their mark as a technology that enables software components to communicate directly with each other across networks, many businesses have a wealth of information that is managed by prior art data base 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 ability to interconnect a distributed component architecture, such as DCOM, with existing enterprise On-line Transaction Processing (OLTP) systems. It defeats the two main goals of component-based development, fast time-to-market and lower development costs, if companies are forced to “hand code” into their component applications the mission critical services that are required for online production systems.

However, there are certain types of applications wherein it is expected that a large number of users will request access to the same data between actual changes to the data. In such cases, it may become quite wasteful to permit each user to access the enterprise server for computation of the same data.

SUMMARY OF THE INVENTION

The present invention overcomes many of the disadvantages associated with the prior art by providing a gateway mechanism whereby automatic service requests are generated within a Distributed Component Object Model (DCOM) environment for service by an enterprise On-Line Transaction Processing (OLTP) system to update data for future reference. Thus, the gateway of the present invention provides updated, standardized data to a user in the DCOM client/server environment using the full resources of the enterprise server. Yet the services on the OLTP system are accessed to update the data at intervals associated with the much slower rate of change of the data rather than the rapid rate of requests to access the data by a potentially large number of users.

A typical application for which the subject invention is particularly efficient involves the flight schedules and pricing of scheduled airline travel. The airline may choose to update the data at certain intervals (e.g., weekly). Yet during each week, between updates, the scheduling and pricing information may be accessed many thousands of times. The present invention requests the enterprise server to update the schedule and pricing information once at a particular point during the week. Subsequently, individual users may readily access the updated schedules and prices in a “canned” format without the need for the enterprise server to redo the computations for each access request.

Each automatic update service request is designed to accomplish a specific task. In a preferred embodiment, the OLTP system is X/Open compliant. When an automatic OLTP request is generated by the gateway, the service request containing the service call and the appropriate set of input parameters is sent to as a buffer to the communications program, which in a preferred embodiment is the Open/OLTP HTPic program. The communications program passes the input buffer to the enterprise node for processing by the requested service.

After the OLTP system services the request, a response is passed back via an output buffer to the AutoGate Gateway, which updates the appropriate HTML files on the NT Server. As DCOM users request access to the data, the DCOM Server provides the updated data without the need to request further service from the OLTP enterprise server.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects of the present invention and many of the attendant advantages of the present invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof and wherein:

FIG. 1 is a functional block diagram of an exemplary computing environment in which the present invention could be used to make automatic service requests of an enterprise based transaction processing system interoperable with a PC/Workstation based requester;

FIG. 2A is a functional block diagram of a generalized WebTx environment;

FIG. 2B is a functional block diagram of WebTx components utilized within a Microsoft NT environment;

FIG. 3 is a diagram showing the relationship of the key software components which allow DCOM clients to access enterprise applications for non-automatic updates;

FIG. 4 is an illustration of the software environment;

FIG. 5 is a flow diagram illustrating how an automatic request is issued to an enterprise OLTP enterprise application;

FIG. 6 is a flow diagram illustrating how to set up an automatic update application; and

FIG. 7 is a flow diagram showing an automatic service request to update data within the DCOM environment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The detailed descriptions which follow are presented largely in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art.

An algorithm is here, generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be kept in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

Furthermore, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention; the operations are machine operations. Useful machines for performing the operations of the present invention include general purpose digital computers or other similar devices. In all cases, it should be kept in mind the distinction between the method operations in operating a computer and the method of computation itself. The present invention related to method steps for operating a computer in processing electrical or other (e.g., mechanical, chemical) physical signals to generate other desired physical signals.

The present invention also relates to apparatus for performing these operations. This apparatus may be specially constructed for the required purposes or it may comprise a general purpose computer as selectively activated or reconfigured by a computer program stored in the computer. The algorithms present herein are not inherently related to a particular computer system or other apparatus. In particular, various general purpose computer systems may be used with computer programs written in accordance with the teachings of the present invention, or it may prove more convenient to construct more specialized apparatus, to perform the required method steps. The required structure for such machines will be apparent from the description given below.

FIG. 1 is a functional block diagram of an exemplary computing environment in which an enterprise based transaction processing system is interoperable with a PC/Workstation based requester. A plurality of PC/Workstations, designated as Clients 10, 12, 14 and 16 are coupled to a Server 18 via Network 20. The Network 20 may be an internal local area network or the Internet.

Each of the Clients 10, 12, 14 and 16, is a Personal Computer/Workstation having operating system software and application software designed to provide Graphical User Interface (GUI) and communications capabilities which enable the Client to communicate with an associated Server application 18 via a Network 20.

The Workstation Server System 50 may be any class of machine(s) which are capable of running a Server application 18 along with a Distributed Transaction Processor 54. The Transaction Processing system 54 is designated as Distributed to make clear that a transaction is formatted on the Workstation Server System 50 and forwarded to the Enterprise Server system 52 for processing.

The exemplary Enterprise Server System 52 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 a monolithic transaction processing system, however, it is designated as Distributed to be compatible with the Distributed Transaction Processing System 54. The exemplary Distributed Transaction Processing Systems 54 and 56 are intended to encompass transaction manager software, such as Open/OLTP Transaction Manager software from Unisys, and user implemented Open/OLTP services. 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 Distributed Transaction Processing System 56 serves data from the Database 28 to the Transaction Clients 30, 32, 34 and 36. The Transaction Clients 30, 32, 34 and 36 are coupled to the Distributed Transaction Processing System 56 via line 38, of which the underlying technology is driven by the application of the Distributed Transaction Processing System 56.

The Transaction Gateway Client 40 allows the Server 18 to interoperate with the Transaction Processing System. When a Client 10, 12, 14 or 16 selects an enterprise based service, the request is routed to the Server 18, which in turn routes the request to the Transaction Gateway Client 40. The Transaction Gateway Client 40 determines the requested service and forwards the necessary information to the Distributed Transaction Processing System 54 and 56. The Distributed Transaction Processing System 54 and 56 processes the request against the Database 28 according to the specified request (e.g., select, update, delete). The Distributed Transaction Processing System 54 and 56 returns data and/or status information to the Transaction Gateway Client 40, which in turn formats the data in an appropriate manner for the Server 18. The Server 18 then returns the information to the requesting Client 10, 12, 14 and 16.

FIG. 2A is a functional block diagram of a generalized WebTx environment. In general, WebTx is middleware in a client/server computing environment which accepts requests from the client side and routes the requests to the correct place on the server side, then passes a response from the server side back to the client side. In the context of the present invention, this is really an HTML solution.

The WebTx environment, as utilized in the present invention, is comprised of several components, including a Monitor 201, a Web Server Extension 237, one or more Gateways 213, 217, 221, and 207, the WebViewC compiler 290, and a set of libraries 288.

The WebTx Monitor 201 communicates with the Web Server Extension 237 via interface 203, and a Gateway 207 via interface 209. The Monitor 201 functions as the WebTx administrative tool. One function of the Monitor 201 is to start and stop the gateways 207, 213, 217, and 221, as needed. Within a Unix environment, the WebTx monitor module is known as WebMon, while under the Windows NT environment, the WebTx monitor module is known as WtxSvc.

The WebTx Web Server Extension component 237, is a run-time extension of the Web Server 235 (such as Netscape FastTrack, Netscape Enterprise, or Microsoft IIS). The function of the Web Server Extension 237 is to intercept requests intended for WebTx 218, and instead route the requests to the Gateways 207, 213, 217, and 221. The Web Server Extension 237 will also interpret the response from the Gateways, and route the reply. The Web Server Extension is connected to the Gateways 213, 217, 221 and 207 via interfaces 211, 215, 219 and 205. The Web Server Extension is connected to the Monitor 201 via interface 203, an HTML requestor component 224 via interface 228, and a Java Applet 226 via interface 234.

The Gateways 213, 217, 221 and 207 perform tasks which are grouped into conceptual areas. The Gateways 213, 217, 221 and 207 receive requests from the Web Server Extension 237 or from the Applications 212 and take whatever action is necessary to fulfill the request. This typically involves transforming a request (such as a URL from a Web Browser or remote procedure calls RPC's from a DCOM client) into a format which is understandable by a Distributed Transaction Processing System such as a Unisys 2200 Enterprise System 200. The Gateways 213, 217, 221 and 207 also transform data returned from the Distributed Transaction Processing System 200 into a formatted response which is returned to the requester.

As explained in more detail below, one of the gates also makes the automatic service requests associated with the present invention. In this manner, data updates are made utilizing these automatic service requests of the enterprise server. The updated data is produced for subsequent client requests without the need for further communication with the enterprise server.

The WebViewC compiler 290 is used in conjunction with specific Gateway implementations, such as ViewGate, TUXGate, and JGate. The WebViewC compiler 290 compiles Open/OLTP view files generated on the OLTP enterprise system to create WebTx view files (.wv) and HTML files (.html). The WebViewC compiler is a free-standing component with no direct communication to any of the other components within the WebTx environment.

Other WebTx Components include libraries 288 such as the Software Development Kit (SDK) libraries, which provide framework and functions for building Custom Gateways. The SDK is specifically designed to allow customers to build their own gateways. Another type of library present within the WebTx system are Java Class Libraries, which provide class definitions for building JavaGate compatible applets.

Another tool 290 that may exist as a WebTx component is DGateAce. DGateAce is analogous to WebViewC, and is used specifically in conjunction with DGate, as part of the Unisys Pathmate system. DGateAce is further described in a co-pending application entitled, “AN AUTOMATED DEVELOPMENT SYSTEM FOR DEVELOPING APPLICATIONS THAT INTERFACE WITH BOTH DISTRIBUTED COMPONENT OBJECT MODEL (DCOM) AND ENTERPRISE SERVER ENVIRONMENTS”.

Unix WebTx uses Inter-Process Communications (IPC) objects such as semaphores, shared memory, message queues and signals, while NT WebTx uses IPC objects such as handles, pipes, mutexes, and events.

FIG. 2B is a functional block diagram of WebTx components utilized within a Microsoft NT environment. This figure shows specific Gateway implementations within the Windows NT node. The SimpleGate Gateway 236 is specifically utilized as a test tool. It merely echoes a request. The TUXGate Gateway 240 provides generalized access to OLTP services through BEA TUXEDO 266. BEA TUXEDO acts as the hub for a distributed enterprise and Internet 3-tier applications. It provides an open environment that supports a wide variety of clients, databases, networks, legacy systems, and communications options. The FileGate Gateway 244 works in conjunction with a specific OLTP service to access textual files on the Unisys 2200 node. ViewGate 248 provides generalized access to OLTP services on the Unisys 2200 note (specifically HTML output). JGate 252 provides generalized Java applet access to OLTP services on the Unisys 2200 node. The DGate Gateway 256 provides generalized DCOM access to OLTP services on the Unisys 2200 node. The MapperGate Gateway 260 provides generalized access to Mapper applications within the Microsoft Windows NT environment. The AutoGate Gateway, shown at 264, will automatically generate the service requests to the Unisys 2200 node to update the appropriate data within the NT Node. In almost every case, AutoGate 264 will make the necessary service request(s) on a time basis (e.g., daily, weekly, monthly, etc.). Subsequent access requests to the NT Node for the updated data may be honored without a specific further service request of the Unisys Node.

FIG. 3 is a diagram showing the relationship of the key software components which allow DCOM clients to access enterprise applications for those data elements which automatically updated. The Unisys ClearPath IX Server 310 includes both an OS 2200 environment 312 and a Windows NT environment 314. All ClearPath HMP IX Servers 310 include On-Line Transaction Processing (OLTP) software that complies with the X/Open model for Distributed Transaction Processing (DTP). This enables client/server access to existing OLTP applications as well as allowing development of new, distributed client/server applications.

The X/Open DTP software provided for the OS 2200 environment 312 is TransIT Open/OLTP, available commercially from Unisys Corporation. The TransIT Open/OLTP Transaction Manager 317 is the base product for all Open/OLTP software in the OS 2200 environment 312. It includes: 1) a transaction monitor, which executes and routes transactions, performs load balancing, and recovers transactions after failures and 2) A communications resource manager (CRM), which controls communications among distributed applications.

The Open/OLTP Transaction Manager 317 includes interfaces to applications and to database systems (resource managers), including the Database Management System (DMS) and the Relational Database Management System (RDMS).

The OS2200 Environment also includes an Open/OLTP Heritage Application Access component 316. This component 316 allows use of existing OS 2200 OLTP applications, many without modification, as Open/OLTP server programs. This provides an easy way to provide GUI client/server access to existing applications. These Open/OLTP server programs can be Transaction Processing (TIP), High-Volume Transaction Processing (HVTIP) or other online batch programs (as shown at 318). Tools are provided for formatting the data from the existing program into Open/OLTP buffer formats.

When used with Open/OLTP, the present invention makes it possible to provide access to the following types of OS 2200 applications from a DCOM environment: 1) Native Open/OLTP applications (local), 2) native Open/OLTP applications that participate in distributed transactions with other platforms running Open/OLTP and BEA TUXEDO software, and 3) Heritage applications that use TIP, HVTIP, and DPS.

Existing transactions can be reused without modification, as long as they meet the following criteria: 1) Open/OLTP services must use the request/response model. Conversational services are not supported, and 2) Open/OLTP services must use X_C_TYPE or X_COMMON buffers. X_OCTET buffers are not supported.

The key software components that enable DCOM clients to access Open/OLTP applications reside in the Windows NT environment 314 of the ClearPath IX server 310. The Open/HTPic software component 320 is middleware which enables applications in the Windows NT environment to execute transactions against OS 2200 applications that use the Open/OLTP transaction manager 317. The DGate runtime software component 322 (DGate.exe) acts as a conduit between the Windows NT DCOM environment 314 and the Open/OLTP environment 312. The DCOM Server software component 324 accepts requests from DCOM Clients, repackages the parameters into the format required by the Open/OLTP transaction manager 317, and then forwards the parameters over a named pipe to the DGate runtime 322. The DCOM Server 324;could also include a variety of distributed objects. The stub software component 326 accepts remote procedure calls from object proxies on client PCs and converts them to interface calls to the DCOM Server application 324.

DCOM Client components 328 reside in a Windows 95 or Windows NT Workstation environment on a personal computer 315. The DCOM Client program 328 provides a graphical user interface (GUI) for submitting transaction requests to the DCOM Server 324 and viewing the data it returns. The Object Proxy software component 330 converts requests from the DCOM client 328 to remote procedure calls (RPC) 334. The RPCs 334 are subsequently sent across a network 332 to the stub component 326 in the Windows NT environment 314.

In addition to the DGate runtime components, the present invention also includes a utility called DGateAce (not shown) that simplifies the process of defining the DCOM Client and Server programs used with the DGate runtime environment. DGateAce is further described in co-pending patent application, Ser. No. ______, entitled, “AN AUTOMATED DEVELOPMENT SYSTEM FOR DEVELOPING APPLICATIONS THAT INTERFACE WITH BOTH DISTRIBUTED COMPONENT OBJECT MODEL (DCOM) AND ENTERPRISE SERVER ENVIRONMENTS”, which is herein incorporated by reference.

FIG. 4 is an illustration of the general software environment. Open/OLTP services 450 are created by a user on an enterprise server 452, such as a Unisys 2200. These services 450 are capable of operating under an OLTP-style transaction processing system. In a preferred embodiment, this OLTP-style system is X/Open compliant. The service 450 is designed to accomplish a specific task, for example, update a presentation of airline scheduling and pricing.

Each service is associated with an input view (.V) file 458 which defines how the input parameters will be provided to the service 450. In particular, the V file 458 indicates where each input parameter is located in the view file, and the size and type of each input parameter. If a service 450 is to provide output to the user (for example, the updated scheduling or pricing information), another output view file is required to communicate how the information will be presented within the output view buffer.

For all services 450 that are to accessed from a particular Windows NT node 490, the associated view files 458 must be copied (via FTP or other copy service, shown at 459) to that node 490. Once the view files 458 have been successfully copied to the Windows NT node 490, the MakeView compiler 460 is used to generate “.hv” files 462.

The WebTx DGateAce software component 472, further described in co-pending application, Ser. No. ______, entitled, “AN AUTOMATED DEVELOPMENT SYSTEM FOR DEVELOPING APPLICATIONS THAT INTERFACE WITH BOTH DISTRIBUTED COMPONENT OBJECT MODEL (DCOM) AND ENTERPRISE SERVER ENVIRONMENTS”, also must have access to the view files 458. DGateAce 472 uses the view files 458 to automatically generate files needed for an application to operate within a DCOM environment. These files include the DCOM Server Applcation.exe 470, the Stub.dll 482, and the Proxy.dll 484.

The Distributed Component Object Model (DCOM) is a Microsoft model for distributed object computing. Within the DCOM environment, a remote DCOM Client Application 486 can make a request. The DCOM client 486 can be any type of client, including a Visual Basic client, a C++ client, or a Web Browser with Active Server Pages (ASP). If the request made by the DCOM client 486 is a request for access to a remote process (interprocess request) the request is routed to proxy.dll 484. Proxy.dll 484 is a code segment which receives any client requests targeted for a remote server, and will facilitate the necessary interprocess communications. The proxy.dll 484 understands how to communicate with the Client 486, and also understands how to communicate over an interface 485 which is shared by two or more processes. The proxy.dll 484 “marshals” the request parameters into an independent format so that they may be provided by the client process 486 over the COM-based interface 485, which conforms with the Microsoft DCOM Model. The stub.dll 482, which also understands how to communicate over the common interface 485, “un-marshals” the parameters into a format that can be understood by the DCOM Server Application.exe 470. Thus, the DCOM environment allows machines with entirely different architectures (PCs, Workstations, etc.) to communicate using a common interface.

The specifics of the common interface are described in an Interface Definition Language (IDL) 474. The IDL 474 is operated on by the Microsoft Interface Definition Language (MIDL) compiler 476 to create a set of .c (C) and .h (header) files 478. Then, a second compiler (C++) 480 operates on the c and .h files to create the stub.dll 482 and the proxy.dll 484. The proxy.dll 484 is linked to the DCOM Client Application.exe 486, and the stub.dll 482 is linked to the DCOM Server Application.exe 470.

Once the DCOM Server 470 un-marshals the parameters, the parameters are packaged into a single buffer and passed to the DGate-Server.dll 468. The DGate-Server.dll 468 and the DGate.exe 466, both of which are the subject of the present invention, are the modules which “DCOM-enable” an OLTP enterprise server 452 such as the Unisys 2200 System.

FIG. 5 is a flow diagram illustrating how data is updated in the DCOM server using an automatic service request to an enterprise OLTP enterprise application. The process begins at block 500, with the initialization of the automatic gateway function. Ordinarily, the updates will be performed on a timing basis (e.g., daily, weekly, monthly, etc.). The automatic update function experiences the condition precedent (e.g., timing signal indicates need for update) at 502. Next, the proxy.dll code in the AutoGate executable determines if the function is remote, and if so, it marshals parameters, as shown at 504. The proxy.dll accomplishes this function by converting requests from the AutoGate application to remote procedure calls.

The stub.dll code in the server executable receives the request from the proxy.dll, then un-marshals the parameters, as shown at 506. In other words, the stub accepts remote procedure calls from object proxies and converts them to interface calls to the DCOM server application.

On the Unisys 2200, the request will first be handled by the TransIT Open/OLTP Transaction Manager, available commercially from Unisys Corporation, which is the base product for all Open/OLTP software in the OS 2200 environment. The Open/OLTP Transaction Manager includes interfaces to applications and to database systems (resource managers), including the Database Management System (DMS) and the Relational Database Management System (RDMS). The service routine on the enterprise OLTP system eventually sends a response back to the AutoGate executable, which reformats the response into an output buffer and returns the output buffer to the TransferToGateway( ) function in AutoGate_Server.dll, as shown at 514.

Next, the TransferToGateway( ) function in DGate_server.dll releases its connection to AutoGate.exe and returns the output buffer to the AutoGate code in the server executable, as shown at 516. The AutoGate code in the server executable unpacks the output buffer into individual output parameters, as shown at 518.

The stub.dll code in the server executable then marshals the output parameters, as shown at 520. Finally, the proxy.dll code in the AutoGate executable un-marshals the output parameters into a form that the data update executable can use, as shown at 522. The internal server data is updated pending user access request at 524.

FIG. 6 is a flow diagram illustrating how to set up an AutoGate application. Beginning at 650, the first step in the process is to define the view files 652. View file definitions show input and output parameters that will be received and transmitted to/from the On-Line transaction processing system application. In particular, the view file definitions indicate where each input/output parameter is located in the buffer subtype, and the size and type of each input parameter (e.g. whether the parameter is an 80-byte character string, a long integer, etc). Another output view file definition is required to communicate how the information will be presented within the output view buffer.

Next, buffer subtype definitions must be installed on the Unisys 2200 OLTP enterprise system 654. Open/OLTP users X/Open typed buffers and user-defined buffer subtypes to define data structures. These structures ensure that applications programs can successfully exchange data, even when they reside on different types of machines. Unisys OLTP-TM2200 VIEW utilities are used to define and install buffer subtypes. When the buffer subtypes and defined and installed, the Unisys On-Line Transaction Processing Transaction Manager (OLTP-TM2200) encodes and decodes the buffer data on behalf of the application programs.

Following installation of the buffer subtype definitions on the 2200, the next step in setting up an AutoGate application to write the service code, create the server, and append it to the 2200 OLTP 656. The MAS utility, a component of the OS2200 TransIT Open/OLTP Transaction Manager, is a processor that creates a runstream of Executive Control Language (ECL) statements that call OS2200 tools to build a server. The MAS utility is used to build extended mode and basic mode servers of all supported type (HVTIP, TIP, and batch).

Next, the view definition files which were defined on the 2200 Enterprise OLTP server are copied (via FTP, or other copy service) to the Windows NT Node 658. After the view definition files have been copied to the Windows NT node, the HTPic MAKEVIEW and WebTx WebviewC compiler are used to generate binary files (.WV and .hv/.V) 660.

FIG. 7 is detailed diagram showing the operation of AutoGate 700. Communication with the enterprise OLTP server is as shown with the issuance of service requests and the receipt of results. These transactions are made automatically in response to the list of transactions as shown. As discussed above, most of these will be time related (e.g., daily, weekly, monthly, etc.), although other conditions precedent may also be utilized.

The resultant data presentation after data update is provided by final published html file 702, as shown. This presentation is in the format provided by the html template. Final published html file 702 is available for access by any of the DCOM users directly from the DCOM server.

Having thus described the preferred embodiments of the present invention, those of skill in the art will readily appreciate that the teachings found herein may be applied to yet other embodiments within the scope of the claims hereto attached.

Claims

1. In a data processing system having an On-Line Transaction Processing (OLTP) system, the improvement comprising:

an automatic gateway which automatically updates data within said data processing system by automatically making a service request of said OLTP system in response to a condition precedent.

2. A data processing system according to claim 1 wherein a user may access said updated data without generating a subsequent access to said OLTP system.

3. A data processing system according to claim 2 wherein said condition precedent further comprises the passage of an interval of time.

4. A data processing system according to claim 3 wherein said user accesses said updated data with an industry standard personal computer.

5. A data processing system according to claim 4 wherein said OLTP system further comprises a Unisys 2200 system.

6. An apparatus comprising:

a. an OLTP server for processing a service request and providing a result;

b. a DCOM server responsively coupled to said OLTP server; and

c. an automatic gateway within said DCOM server which automatically generates said service request and receives said result in response to a condition precedent.

7. A data processing system according to claim 6 wherein said DCOM server is responsively coupled to said OLTP server via the world wide web.

8. A data processing system according to claim 7 further comprising a user terminal responsively coupled to said DCOM server wherein said user terminal accesses said result.

9. A data processing system according to claim 8 wherein said user terminal further comprises an industry standard personal computer.

10. A data processing system according to claim 9 wherein said OLTP system further comprises a Unisys 2200 system.

11. An apparatus comprising:

a. means for offering On-Line Transaction Processing of a service request;

b. means responsively coupled to said offering means for providing a DCOM environment; and

c. means located within said offering means for automatically generating said service request in response to a condition precedent.

12. An apparatus according to claim 11 wherein said condition precedent further comprises elapse of a predetermined time interval.

13. An apparatus according to claim 11 wherein said offering means further comprises a Unisys 2200 system.

14. An apparatus according to claim 11 wherein said offering means is responsively coupled to said providing means via the internet.

15. An apparatus according to claim 11 further comprising means responsively coupled to said providing means for providing a user to interface with said providing means.

16. A method of providing updated data to a user comprising:

a. automatically generating a service request within a DCOM server in response to a condition precedent;

b. transferring said service request from said DCOM server to an OLTP server via a publically available communication system;

c. honoring said service request within said OLTP service to produce a result;

d. transferring said result from said OLTP server to said DCOM server via said publically available communication system;

e. modifying a presentation to produce said updated data; and

f. providing access by said user to said updated data via said DCOM server.

17. A method according to claim 16 wherein said OLTP server is responsively coupled to said DCOM server via the world wide web.

18. A method according to claim 17 wherein said access providing step further comprises providing access via an industry standard personal computer.

19. A method according to claim 18 wherein said two transferring steps further comprises transferring via the internet.

20. A method according to claim 19 wherein said condition precedent further comprises and elapsed time period.