1. Field of the Invention
The present invention is related to a system for message queuing. More particularly, the present invention relates to a system for handling items sent between software applications utilizing, amongst other things, a relational database for storing a queue.
2. Background Information
Many business tasks require a series of steps to perform a job. In a computer system having multiple applications required to complete a job, one application finishes its part of the process and then sends the results to the next application. The receiving application will in turn finish its part of the job and pass on its results to the next application. This process is repeated until all the applications have finished their parts of the job resulting in completion of the job.
A problem is encountered with this system when one application sends its results to the next program, and the receiving application has to interrupt processing to receive the incoming data. In the alternative, the application sending the information may defer processing the next task and wait until the receiving application is finished its processing. In either case, resources are wasted.
Some reasons the receiving application may not be able to immediately receive the information sent from the sending application are that the receiving application may be down or may not operate during the same period the sending application operates. Additionally, the receiving application may run on a less powerful computer, may share a computer with other tasks, or possibly the receiving application's processing is more complicated than the sending application's processing. If the mismatch in processing capability between the sending and receiving system is temporary, queues can be used as a buffer between the two systems.
Thus, queued messaging is a solution to the problem. Queued messaging allows interoperating programs to exchange data asynchronously. When the parties communicate by leaving messages, we say that communication is asynchronous. Asynchronous communication requires the messages be left somewhere. In other words, the sending application may post the message to a queue upon completion of its part of the process. The receiving computer need not be ready at that moment and may dequeue the message from the queue and receive the message when the receiving program is finished processing the previous task.
A known system called TUXEDO /Q available from BEA Systems, Inc. located in Sunnyvale, Calif. is designed to handle asynchronous communications. /Q receive messages from one application and stores the items in a queue stored in a flat file format. A flat file format is a file such as an ASCII file where alterations to the file are not recorded. /Q then dequeues the messages from the queue stored in the flat file format and forwards the items to the receiving application when the receiving application is available.
However, a disadvantage of the flat file format that /Q uses to store the queue is with regard to recovery of the queue. For example, if something happens to the queuing system and the queue data becomes corrupted or lost, the only way to recover the data is to restore the last backup. There are a variety of events which may cause the queue data to be lost including natural disasters, a power surge, or power failure, equipment failure . . . Backups of flat file formats are not made continuously because the only time data may be backed up is when the system is quiescent. Thus, continuous backups would result in a significant loss of processing time. Therefore, backups are typically made infrequently (e.g., daily or weekly) and a substantial amount of data may be lost (i.e., all messages stored since the last backup).
In the alternative to storing the queue on disk, the queue may be stored in main memory. Main memory queues eliminate the overhead of disk writing. However, main memory queues have a great potential for loss because if the computer stops operation before the intended target retrieves the message, the queue is lost.
Thus, there is a need for a queuing system with a more reliable recovery method.
USPTO Backgrounds
USPTO Backgrounds