GB2319640A - Transaction processing system - Google Patents

Abstract

A transaction processing system comprises a transaction manager 20, responsive to transaction requests from an application 10, and adapted to run in the same process as the application. A set of stub modules 35 is adapted to run in the same process as the application, and each stab module is adapted to relay transaction request data passed from the transaction manager across a process boundary. A server 40 is adapted to run in a second process, the server being adapted to receive requests from the set of stab modules across the process boundary and to queue the requests for execution. A set of hardware modules 30 executes requests, each hardware module corresponding to a stab module, and each hardware module being responsive to the requests and being adapted to convert said requests to respective hardware-specific calls for a device associated with each hardware module. The system allows the possibility of various equipment vendor devices being connected to it. In addition, an application is able to recover transaction information in the event of the application abending.

Description

TRANSACTION PROCESSING SYSTEM The present invention relates to a transaction processing system.

As financial and other commercial institutions become increasingly automated, they continually wish to develop both in-house computer applications and customer related applications. This automation often depends on acquiring newly developed hardware, and it is critical for gaining a competitive advantage that institutions are able to select between different hardware suppliers.

Without the ability to write vendor independent applications, financial institutions would be forced to adapt their ATM applications if they change ATM vendors; similarly supermarket chains would be forced to adapt their applications if they changed till vendors. This increases application development time and costs and restricts the freedom of the institutions to choose between vendors.

WOSA/XFS (windows Open Services Architecture for Extended Financial Services) is an emerging standard enabling financial institutions, whose branch and office solutions run on the Windows NT platform, to develop applications independent of vendor equipment.

Figure 1 shows the standard WOSA model. Using this model, an application 10 communicates hardware requests 12 to various hardware devices in, for example, an ATM 14 via a wOSA manager 20. The application issues transaction requests 12 which are hardware independent, and thus vendor independent. The requests are queued by the WOSA manager 20 which manages concurrent access to the ATM hardware 14 from any number of applications 10.

When a piece of hardware is installed on the ATM, it registers its controlling software, known as a service provider module (SPM) 30, with the WOSA manager by using, for example, the Windows registry. The WOSA manager 20 is thus able to relay a hardware request 12 to an appropriate SPM 30, using the Windows registry as a look-up table. The SPM 30 takes relayed hardware independent requests 16 from the WOSA manager and actuates the appropriate piece of hardware to process the requests. The results of a request can be returned by an SPM 30 synchronously via the WOSA manager 20 or asynchronously by generating a Windows event.

WOSA is a classic single process model, where all components of the solution run in the same process. If a single thread within this process abends, it will normally take the entire process down. Although this is acceptable in non-critical applications, for example printing, it is not acceptable where security is involved and where detailed audit trails are required. The best example of this case is where ATM cash dispensing is involved. If the process abends while a dispense is taking place, the error needs to be recoverable in order to determine the disposition of the cash involved.

Accordingly, the present invention provides a transaction processing system comprising a transaction manager, responsive to transaction requests from an application, and being adapted to run in the same process as the application; a set of stub modules adapted to run in the same process as the application, each stub module being adapted to relay transaction request data passed from said transaction manager across a process boundary; a server adapted to run in a second process, said server being adapted to receive requests from said set of stub modules across the process boundary and to queue said requests for execution; a set of hardware modules for executing requests, each hardware module corresponding to a stub module, and each hardware module being responsive to said requests and being adapted to convert said requests to respective hardware specific calls for a device associated with each hardware module.

It will be seen, however, that the invention is not limited to WOSA or an ATM and is applicable wherever an application needs to recover transaction information after the application fails.

The transaction processing system according to the invention provides a server which runs in a process separate from the application process, and is capable of handling all wOSA functions in a transparent manner to the application. This approach has a number of benefits. In the case of an audit trail, the server process is protected if the application process 10 dies, and vice-versa. Should the application die, when it restarts the server will inform it that it already has a session open. Conversely if the server dies, the application 10 will receive a timeout from the WOSA manager 20. A well written application can therefore recover from any abend therefore and accurately update any audit trail.

Another benefit of the invention, is that it still provides to the end user a generic WOSA engine, as the hardware specifics are encapsulated in a lower level of code. The server includes a generic software interface to the hardware 14 to define how drivers can be connected to the server. This gives the server the ability to deliver WOSA support for any given hardware set with the minimum of new software development.

It will also be seen that the invention provides a solution flexible enough to take into account the possibility of various equipment vendor devices connected to the same system. If some vendor devices do not support the system according to the invention, because they do not provide stub modules, then their respective SPMs can communicate directly with the WOSA manager 20 within the same process. The invention will still provide a benefit because both processes still operate and are able to inform one another of the status of a transaction in the event of a thread in either process abending.

An embodiment of the invention will now be described with reference to the accompanying drawings, in which: Figure 1 shows the standard WOSA single process model; Figure 2 shows the transaction processing system according to the present invention; Figure 3 shows a server component of the transaction processing system according to the invention in more detail; and Figure 4 is a schematic view of a portion of a Windows NT registry employed by a WOSA manager.

The standard WOSA model includes three layers, Figure 1. An application layer 10 issues transaction requests in the form of hardware independent Application Programming Interface (API) calls 12 to a WOSA Manager 20 layer in order to access services from a Service Provider 30 layer. All components exist within the same process (the Application's) and memory address space.

In the server model according to the invention, Figure 2, the application 10 and wOSA Manager 20 exist within the same user application process. The WOSA manager 20, however, communicates with stub Dynamic Link Libraries (DLLs) 35 each corresponding to a respective SPM 30 of Figure 1. The preferred embodiment of the invention is implemented in an object oriented manner and will be described in those terms.

Transaction requests 12 from the application layer 10 pass through the WOSA Manager 20 to the stub DLLs 35, where the data is repackaged and passed across process boundaries to a server 40 running in a separate process, where the required transaction request is actually executed. The server 40 communicates with SPM's 30 to execute the transaction request, and any execution results are either passed back from the SPMs to the application 10 through the WOSA manager 20, via the stub DLLs 35, or via an operating system messenger 50. In a Windows NT operating system embodiment of the invention, the SPMs 30 generate windows events using an application nominated window handle, whereas in an embodiment of the invention using IBM's OS/2 operating system, the SPMs generate presentation manager events to communicate directly with an application 10.

The method of response is determined by the Application 10, depending on whether a transaction request issued is specified as synchronous (the server responds through the stub DLL mechanism) or asynchronous (the server responds via the Windows Event mechanism).

Information is also accessible by both the application 10 and the SPMs using shared memory. When, for example, an SPM 30 wishes to transmit information to an application 10, the SPM sends a WOSA call to the WOSA manager 20 which communicates with an operating system memory manager 55 to allocate the shared memory. Once allocated, then SPMs 30 in the server 40 process or applications 10 can read or write information from this shared memory.

Figure 3, shows the server 40 in more detail. The server is a multi-threaded application supporting the simultaneous execution of transaction requests on all of its supported WOSA device classes explained below. The server 40 consists of the following major components: A server object 41 runs in its own thread and has responsibility for creating and monitoring memory 'pipes' 42 connecting the server process to respective stub DLLs 35, running in the user application process. When the server object detects a transaction request packet from one of the stub DLLS 35 waiting in its associated 'pipe' 42, it moves the packet into a master queue 43 and thus frees the pipe for more communications. The server also detects packets in the master queue 43 that are response packets from service provider modules 30, and channels these back through the 'pipes' to the correct stub DLL 35, which then passes the response back to the user application 10 via the wOSA Manager.

The memory pipes 42 are implemented in a class including essentially three methods: readPipe(), writePipe(), queryPipe() with the methods being passed an identifier corresponding to the stub DLL associated with the pipe. In the application process, a stub DLL 35 receives a WOSA transaction request from the transaction manager and calls the writePipe method to place the request in its pipe 42. writePipe essentially writes a message to a designated location in shared memory with a flag indicating that the message needs to be read. Once the stub DLL 35 has written the message to the pipe, it then polls its pipe 42 continually using queryPipe to determine when a response has been sent from the server 41 or if the message has been read.

Within the server process, the server object 41 continually polls each of the pipes 42 using the queryPipe method for each pipe in turn to determine if messages are waiting to be processed. If a pipe has a message, the server calls readPipe to read the message from the pipe, reset the message flag indicating that the message has been read and places the message in the master queue 43. The server also interrogates the master queue 43, and if a message for the server 41 is in the master queue 43, the server 41 pops the messages from the queue and calls writePipe to place the message in the appropriate pipe and thereafter reverts back to querying the pipe for the next message.

A client object 44 runs in its own thread and is responsible for creating and managing the supported service provider modules 30 below it.

The client object 44 monitors the server master queue 43 and when it detects an inbound packet for one of its managed hardware devices, it moves the packet from the queue 43 on to a private queue 45 associated with a target device.

Instances of service provider module objects 30 are created at startup time by the client. In the case of an ATM, objects would be instantiated for a journal printer, receipt printer, passbook printer, statement printer, deposit unit, cash dispenser, magnetic card reader / smart card reader, sensors and indicators unit, pinpad unit, encryptor unit, vendor dependant mode (VDM) unit, and text terminal unit. Each instantiation spawns its own control thread that is responsible for monitoring its own private queue 45 for requests that are placed there by the client object 44. When an SPM object 30 detects a request waiting on its private queue 45, or if there is a request pending execution and it is time to attempt to process pending requests again, the SPM object spawns an execution thread that handles the execution of that single request. The execution thread has the responsibility of processing the request to its conclusion, either returning the relevant data to the caller application 10 via events, marking the request as 'pending' on the queue 45 and completing, or returning a response by returning a completed packet back to the server queue 43 for transmission to the stub DLL 35 associated with that hardware device.

Each SPM 30 converts all WOSA transaction requests into one or more generic commands that are processed by a layer of small hardware DLLs 46.

An Application Programming Interface (API) for each type of hardware device is published by the hardware vendor and consists of the minimum number of hardware level commands (example read~card on a magnetic stripe reader device, or dispense~cash on a dispenser) that can satisfy the complete set of wOSA transaction requests for that device type. For example, a respective hardware DLL is supplied for both an IBM Dispenser and an Olivetti dispenser. The user only has to change which DLL is active, by updating the Windows registry in order to switch between the different devices. At the application and server layers, nothing changes.

The same is true for all device types.

The Windows NT registry is a hierarchy of keys, Figure 4, each key containing one or more data values. The wOSA Manager 20 uses the system provided HKEY~CLASSES~ROOT key to store and obtain data on Logical Service Providers, for example, "msrspmt". The application 10 opens a service by providing the wOSA manager with that services' logical name 20. The manager finds the key entry, "msrspm in the HKEY~CLASSES~ROOT\WOSA/XFS~ROOT\LOGICAL~SERVICES key for that service.

One of the data fields, "provider", within that key is an entry describing the service provider key name, tjtestmsrr. The manager then accesses the relevant service provider key within the HKEY CLASSES ROOT\WOSA/XFS~ROOT\SERVICE~PROVIDERS key, which will contain an entry describing the exact path to the physical dll that contains the executable code for that service provider, "d:\path\msrdll.dll|.

In the conventional wOSA transaction processing system, or for service providers who do not support the present invention, the path to the physical file in the Windows registry will point to a service provider module 30, whereas for service providers who support the current invention, the path points to a stub DLL 35. This stub DLL 35 will thus direct any WOSA transaction requests across the process boundary to the server 40 as described above.

In order to reduce processing overhead for applications, WOSA allows a library of standard forms to be defined, for example, a receipt or statement. When, for example, an application wishes to instruct a printer to print a form, it simply sends an identifier for the form as well as the user information to be printed on the form to the WOSA manager. This information is relayed to the server process and on to the SPM associated with the printer. The SPM is able to access the form library, and inserts the user information into the form before sending the information to the hardware DLL which converts the generic information into dedicated printer commands.

Claims (10)

1. A transaction processing system comprising: a transaction manager, responsive to transaction requests from an application, and being adapted to run in the same process as the application; a set of stub modules adapted to run in the same process as the application, each stub module being adapted to relay transaction request data passed from said transaction manager across a process boundary; a server adapted to run in a second process, said server being adapted to receive requests from said set of stub modules across the process boundary and to queue said requests for execution; a set of hardware modules for executing requests, each hardware module corresponding to a stub module, and each hardware module being responsive to said requests and being adapted to convert said requests to respective hardware specific calls for a device associated with each hardware module.

2. A transaction processing system as claimed in claim 1 wherein said hardware modules execute said requests in separate threads of said second process.

3. A transaction processing system as claimed in claim 1 wherein each stub module corresponds to a hardware device supported by the transaction manager.

4. A transaction processing system as claimed in claim 1 wherein said server and said transaction manager are adapted for bidirectional communication, the stub modules being adapted to receive responses from the second process and pass said responses to said transaction manager.

5. A transaction processing system as claimed in claim 1 wherein each stub module is adapted to run validity checks on transaction requests.

6. A transaction processing system as claimed in claim 1 wherein said transaction processing system is implemented on a Windows NT operating system, said operating system including a Windows registry, said stub modules are implemented as stub dynamic link libraries which are adapted to be registered in the registry and said transaction manager is adapted to call said stub DLLs by looking up the Windows registry.

7. A transaction processing system as claimed in claim 6 wherein said hardware modules comprise a service provider dynamic link library and a hardware dynamic link library.

8. A transaction processing system as claimed in claim 6 wherein said transaction manager is a Windows Open System Architecture (wOSA) manager, said transaction requests are WOSA calls and said manager is adapted to relay said WOSA calls to said server via said stub modules, said server being adapted to convert said wOSA calls into constituent components, each component corresponding to a low level generic hardware function call.

9. A transaction processing system as claimed in claim 8, said system being connectable to a printer, said printer having an associated hardware module comprising a service provider module and a hardware dynamic link library, the system including a plurality of wOSA forms and said service provider module being adapted to read said wOSA forms and to combine transaction request data with a transaction request form before forwarding said combination to said hardware module.

10. A transaction processing system as claimed in claim 1, said system comprising: a second set of hardware modules, each hardware module of said second set being adapted to run in the same process as the application and being adapted to convert transaction requests passed from said transaction manager to respective hardware specific calls for a device associated with each hardware module of said second set.