A popular mechanism for carrying out such distributed data processing is called asynchronous message queuing, where applications communicate with each other by sending messages to queues, which can then be accessed by the receiving application at a time that is convenient for that receiving application. IBM's WebSphere MQ software product, which has been on the market for a number of years, is a popular example of this type of software.
More and more companies are providing services based on message queuing systems as underlying information transportation infrastructure. The order in which messages are processed on a queue can be either first-in-first-out (FIFO) or priority based. The priority of a message is stored in the message descriptor of the message and is set by the application putting the message in the queue. Many messages in different business contexts are processed through the message queuing system. The number and the size of the messages can vary over huge ranges and is normally unpredictable as are the consequences of this variation. This implies that a specific priority is valid for a message when it is put in a queue but may become invalid while the message remains in the queue waiting for further processing. Furthermore, some applications may not know the correct priority of the message when putting it in the queue.
The problem in a message queuing system is that the priority of a message is static as long as the message stays in a queue. It is not possible to dynamically adjust the priority of a message already stored in a queue according to deal with the effects of changes in system workload, changes in business processes, changes in the environment, or any other changes in the systems and/or resources required for the processing of the message. Changes may include easy-to-detect situations like a broken network connection or an outage of a process on the system, but may also include a complex construct of several events on different systems in combination with the content of the message. An example for this would be payment messages for different banks with different amounts processed in a payment hub. A condition would be to process a message until a specific time of the day. If the processing throughput of the participating systems decreases in a way that this condition would not be fulfilled (either because some resources fail or because the system usage increases unexpectedly), the system automatically has to detect this and to change the sequence of the messages on that queue so that the specific message is processed before the stated deadline. Changing the message priority does not necessarily mean increasing it but may also mean decreasing it.
Known message queuing systems do not provide any functionality for changing message priority according to the environmental and processing conditions and/or message content once the message is stored in a queue.
USPTO Backgrounds
USPTO Backgrounds