JP2003524827A - Message queuing system and method - Google Patents

Abstract

(57) Summary Intelligent queues can be used to facilitate communication between a set of business application programs. In one embodiment, the intelligent queue may interface with various business application programs that provide consistent service operation across various data storage products. Intelligent queues provide enhanced message storage, effective journaling, and interoperability with other intelligent queues, as well as detailed message state information that tracks each message state from both the sender and receiver perspectives. Provides load balancing, one-time processing.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD OF THE INVENTION

The present invention relates to the field of network messaging, and more particularly queues.

[0002]

[Background technology]

We have found that the rapid development of the software industry has created a vast variety of applications available to the general public, and that the general public depends heavily on these applications. Furthermore, in the business field, it is common to introduce various applications within the company for daily work. Since these applications are provided by different vendors, coordination efforts to support routine multiple business activities often require manual effort provided by resources available elsewhere. It is an undesired job. Therefore, in the business field, it is important to communicate and share applications in an efficient and reliable manner.

While businesses need to integrate applications for coordination and information sharing, they seek to minimize the cost of performing such integration. A common problem with traditional approaches is that they are forced to purchase custom message queues that are difficult and expensive to integrate into existing systems. As the business changes, these custom queues need to be replaced or updated, which in turn requires time and money.

Another problem with the conventional approach is that the system administrator faces a cumbersome task of managing various data recording devices. Tracking messages is difficult both in normal transmission and when the system is bearing.

Another problem with the conventional approach is that it allows duplicate processing of messages. In some applications, it is inevitable that the message will be processed only once. For example, a financial application bills a user's bill once for each transaction. Duplicate processing of messages results in inaccurate information and requires enormous resources to restore the data to the proper state.

Yet another problem with the conventional approach is that it often has excessive queues, which is a bottleneck in the system.

[0007]

[Outline of the Invention]

One embodiment of the present invention includes a plurality of first message queues of a first data storage type and a second message queue of a second data storage type that exhibit consistent behavior across multiple computer media. And a message queue management system configured to manage the queues. The message queue management system stores journaled messages in the first message queue and the second message queue, including a journaled state held in the first message queue and the second message queue. A journal module configured to track and manage the message state of the captured message.
The message queue management system is also configured to track a plurality of message states so as not to reprocess already stored messages stored in the first message queue and the second message queue. It has a one-time message processing module. The message queue management system further includes an interaction between the first message queue and the second message queue for performing data recovery of the first message queue and the second message queue in the event of a failure. And a compatibility storage module configured to coordinate the journal state and an extended storage module configured to store the first message queue and the second message queue when the journal module identifies the journal state. . The message queue management system is also configured to track a plurality of message states so as not to reprocess already stored messages stored in the first message queue and the second message queue. It has a one-time message processing module. The message queue management system is further configured with a compatibility module configured to coordinate interactions between multiple queues to enable distributed workflows and to provide data recovery for multiple queues in the event of failure. And a configured recovery module. The message queue management system also includes a central management module configured to provide centralized control of multiple queues, including control of multiple issuers and multiple participants,
A plurality of participants in at least the first message queue in the participant pool such that the message in the first message queue is processed by the first valid participant in the participant pool. A load balancing module configured to specify a subset of parties.

Another embodiment of the invention relates to an intelligent queue that facilitates communication between a set of business application programs. The intelligent queue can use various data storage products to interact with various business application programs. This intelligent queue provides detailed message status information that tracks message status from both extended message storage, one-time processing, and / or contact between sender and receiver.

One embodiment of the present invention relates to a message queue management system for a computer network that provides reliable communication, guarantees non-repeatable distribution, and is implemented in a media independent environment. The message queue management system comprises a message queue running on one of a number of environments and storing messages received from message publishers. Further, the message monitors read by a plurality of message participants, the message being retained in a message queue after at least a plurality of message participants have accessed the message and allowed additional access to the message. Becomes The message status module is configured to track the message status of the message, the message status information indicating whether the message was validated and read by at least one of the plurality of message participants. The recording module is configured to selectively retain message state information associated with the corresponding message, at least until the message is removed from the message queue. The interface module is
It is configured to send and receive multiple data object types in a message, and to communicate with multiple data message system types that act as message publishers or message participants.

Another embodiment of the invention relates to a method of message queuing between multiple message publishers and multiple message participants. The method comprises receiving a data object from a message publisher intended for at least one message participant, processing the data object and generating a corresponding message including the data object and message information. Storing the message in a message queue, tracking the message state from the perspective of the message issuer, tracking the message state from the perspective of at least one message participant, and having the message by at least one message participant. Selectively retaining the message so that it remains in the message queue after being read.

A further embodiment of the present invention relates to a method of journaling a plurality of messages to a message queue when the messages include corresponding message states. The method includes receiving a message that includes a publisher message state and a participant message state. The method also includes placing the message in a message queue and changing the issuer message state of the message to a journal state. This method
Holding the message in the message queue.

Another embodiment of the present invention is a method of participant pooling a plurality of messages containing corresponding publisher status in a message queue. This method places a message in a message queue, notifies a plurality of participants that the message is available, and puts the issuer message state in the read state by one of the participants to an end state. Modifying to prevent other participants from reading the message.

A further embodiment of the present invention is a system for queuing messages between multiple message publishers and multiple message participants. This system
A message queue module configured to communicate with the plurality of message publishers and the plurality of message participants and receive a data object from the message publisher intended for at least one of the plurality of message participants. The data object processing module is configured to process the data object to generate a corresponding message, where the corresponding message includes the data object and message information. The issuer tracking module is configured to track message status from the perspective of the message publisher. The plurality of participant tracking modules are configured to track message status from at least one of the plurality of message participants of interest. The message tracking module is configured to selectively retain messages that remain in the message queue after the message has been read by at least one of the plurality of message participants of interest.

Another embodiment of the invention is a method of queuing a message received from an issuer for reading by a participant, the queue interface module being configurable to interface with multiple database protocols. And
Performing a one-time delivery, storing a message using a queue and the queue interface module, extending message storage beyond the time the message was read by all intended participants. To track message status in order to:

Another embodiment of the present invention is a first message queue implemented with a first type of data retention and a second message queue implemented with a second type of data retention. It is a method of repairing message communication with the queue. This method
Processing the first message queue to verify the location of the undisclosed message. For undisclosed messages, path information is retrieved to find the message's parent message. The status of the parent message in the second message queue is checked. At least one of the parent messages has "do
If "ne" is marked, the parent message is marked "done" and the message is "revealed". In addition, if the parent message is not marked "done", all parent messages are marked "clean" and the message is marked "deleted", and if the parent message does not exist, the message is marked "revea".
marked as "led". Also, processing is performed so that messages marked "clean" are recovered and the second message queue finds messages marked "fetched" rather than "done". Furthermore, instead of "done", "fetche
Messages in the second message queue marked "d" are marked "clean".

Another embodiment of the invention is a system for queuing a message received from an issuer for reading by a participant, the queue interface module configured to interface with multiple database protocols. Possible, means for storing messages using the queue and said queue interface module, means for extending message storage beyond the time the message was read by all intended participants, and one-off Means for tracking message status to perform delivery.

For the purpose of summarizing the invention, certain aspects, advantages and novel features of the invention are described herein. It should be understood that not all such advantages may be achieved with certain embodiments of the invention. Thus, for example, it is understood by one of ordinary skill in the art that one or more effects described herein may be embodied or implemented to achieve one or more of the effects described herein without necessarily achieving the other effects described or suggested herein. Will be done.

[0018]

Detailed Description of the Preferred Embodiments

A system and method showing an embodiment and an application example of the present invention will be described with reference to the drawings. Variations on systems and methods that illustrate other embodiments are also described. The system and method in one disclosed embodiment is used to enable communication in a set of business application programs.

For illustrative purposes, one embodiment is described with respect to business application programs. The present invention is not limited by the format of the program considered, and the format of the object can be various programs such as software modules, business application programs, databases, accounting programs, music programs, telephone systems, etc. Can be included. However, the drawings and description relate to an embodiment of the invention in which the program is a business application program. Furthermore, it is understood that in other embodiments, the message queuing system and method can be implemented as a single module and / or with various other modules and the like. Furthermore, the particular embodiments described herein are disclosed for purposes of illustration and not limitation of the invention. The scope of the invention is defined by the claims.

These features will be explained with reference to the drawings. The drawings and associated descriptions are
It is provided to illustrate the invention and not to limit the scope of the invention. Reference numbers are sometimes used repeatedly to indicate correspondence between referenced elements throughout the figures. Further, the first digit of each reference number indicates the figure number in which the element first appeared.

In the application integration system, the new intelligent queue is
It can be used to facilitate communication in a set of business application programs. In one embodiment, intelligent cues can interact with different business application programs that use different data storage products. Intelligent queuing is an enhanced message store that tracks each message from both the sender and receiver's perspective, one-time processing, and / or
Alternatively, it provides detailed message status information.

An advantage of one embodiment is that the intelligent cues are, for example, B + tree, Sybase CT library database, Oracle OCI database, Oracle AQ database, IBM-MQ series database, Microsoft MSM.
It is semi-independent in that it can use various data storage components such as Q databases, flat file directories, and so on. Thus, while a system administrator may be managing five different queues performed using different data storage products, five intelligent queues are independent of the underlying data storage. Can act and communicate. In addition, this flexibility allows businesses to use existing commercial products to support their intelligent queues and change data retention without confusing or recognizing the entire system. To do.

An additional advantage of one embodiment is that intelligent queues are easily managed in large environments. Large enterprises may use hundreds of intelligent cues. Therefore, it becomes possible to use a single type of queue throughout the system, regardless of the underlying data storage.
It gives the system administrator the ability to perform message tracking while processing only one type of queue.

Another advantage of one embodiment is that the intelligent queue provides a way to track the status of its messages so that the system administrator knows the message status from both the sender and the recipient. Is to become. Moreover, knowing the message state allows messages to be recovered and resent after a system failure. Further, the state of a message may be changed to select a function, rather than tie up system resources to move the message to a different location or delete the message. Compatibility between queues performed using different data stores is also provided. Regardless of the type of data storage, messages can be recovered in case of system failure.

A further advantage of one embodiment is that intelligent queues provide enhanced message storage. The system administrator can specify when a message should be removed from an intelligent queue that allows the message to remain in the intelligent queue even after all participants in the message have processed the message. it can. Thus, when needed, the system administrator has time to track, distribute, archive, edit, and perform other administrative tasks. Furthermore, in the event of a system failure, the system administrator can view the messages in the queue and take appropriate message recovery. Intelligent queues can make available outstanding messages to the appropriate application without exposing already processed messages to the outside.

A further advantage of one embodiment is that intelligent queues can provide load balancing using participant pool processing. One message is made available to several recipients, with the first available recipient handling the message maximizing resources and improving message queuing efficiency. Recipients can also be designated as members of a participant pool by intelligent cues. Further, load balancing and publish / participate operations can be used in combination to improve efficiency. For example, a member of the participant pool may subscribe to a message at the same time as a recipient who is not in the participant pool.

Another advantage of one embodiment is that intelligent queues can be centrally managed to allow remote users to maintain and monitor various intelligent queues.

Intelligent Queues (“IQ”) provide persistent data storage to facilitate communication among various applications and components. The following example illustrates IQ in operation in publish / join mode. Figure 1A
1 illustrates a transaction system including a point of sale system 110 that sends transactions for credit approval by an automatic credit approval system 120. First, point-of-sale (“POS”) module 130 receives a transaction from point-of-sale information management system 110 and converts the transaction into a standard message format. Thereafter, the point-of-sale information management module 130 issues a message to the Sybase IQ 140 executed using the Sybase database. Next, the customer database module 150
The message is read from Q140, and related customer information (for example, accounts receivable, establishment of banking, etc.) is requested from the customer database 160. The customer database module 150 then adds the relevant customer information to the message and publishes the message to the MSMQ IQ 170 implemented using Microsoft's MSMQ queue. Finally, the credit approval module 180 reads the message from the MSMQ IQ 170 and converts the message into a format understood by the credit approval system 120.

FIG. 1B illustrates another embodiment of a transaction system that includes a point-of-sale system 110 that sends transactions for credit approval to the automatic credit approval system 120 as well as the central management module 190. There is. The central management module 190 enables management and monitoring of intelligent queues from remote locations. For example, the central management module 190 assigns participants and issuers, or performs error checking. In one embodiment, the central management module 190 may be executed on a system remote from one or all intelligent queues. A detailed description of one embodiment of the central management module is incorporated herein by reference, entitled "SYSTEMS AND METHODS FOR PROVIDING CENTRA.
LIZED MANAGEMENT OF HETEROGENEOUS DISTRIBUTED ENTERPRISE APPLICATION INT
EGRATION OBJECTS "(internal reference number SOFTEC P.014A) is shown in the application filed at the same time. FIG. 2A shows a second embodiment of a transaction system, in which a customer database module 150 is provided to enable load balancing.
And the MSMQ IQ 170 is duplicated. In this second transaction system, Sybase IQ 140 may include messages that may be read by any of customer database modules 150. This load balancing is performed using participant pool processing so that the first available customer database module 150 can process the message. This system reduces the occurrence of bottlenecks and improves processing time for messages read from Sybase IQ 140.

FIG. 2B shows a transaction system according to the third embodiment,
There, some of the customer database modules 150 and MSMQ IQ 170 are duplicated to allow load balancing and participant pool processing, while other customer database modules 150 and MSMQ IQ 170 are duplicated. , In issue / participation mode. In the second transaction system, the Sybase IQ 140 can include a message that can be read by any of the customer database modules 150. This load balancing is performed using participant pool processing so that the first available customer database module 150 can process the message. This system reduces the occurrence of bottlenecks,
Improves processing time for messages read from Sybase IQ 140.

The embodiments shown in FIGS. 2A and 2B do not include a central management module 190, but in other embodiments, one or more of the intelligent queues are in load balancing mode. 190 may also be included. FIG. 3 illustrates one embodiment of intelligent cue 310. Intelligent cue 3
10 is a set of intelligent queue process 320 and index database 330.
And a data storage component 340.

Intelligent queues 310 include many processes that are used to add information to and extract information from queues. In one embodiment, the intelligent queue process 320 includes a message receive process 322, a message status update process 324, and some other process 326 that provides information about messages in the queue. The intelligent cue process 320 is described in detail below. The index database 330 stores message state information for each message issued to the queue. In one embodiment, the index database 330 is implemented using a flat file structure,
Updated whenever the message state changes. The index database 330 can communicate with an archive database (not shown), where information is stored periodically, such as hourly, daily, weekly, bi-weekly, etc. The index database 330 can be used after a system outage to determine the state of each message before and after the system outage and to provide information about how the system should be restored.

The data storage component 340 is for storing the messages read by the participants. The data storage component 340 acts as a temporary storage unit, where messages are issued or stored until all participants have retrieved and processed the message.

Index database 330 and data storage component 340 are represented as two separate data structures. In another embodiment, the index database 330
And the data storage component 340 are combined and / or implemented using the same data structure. For example, index database 330 and data storage component 340 are implemented as a set of tables in the same relational database. Additionally, various data structures are used to implement index database 330 and / or data storage component 340. For example, linked lists, flat files, binary trees, B + trees, arrays, queues, databases, etc. In addition, different types of databases are also used. For example, relational databases, object-oriented databases, hierarchical databases, etc. In addition, some commercial data storage products are also used. For example, Cybase CT Lib database, Oracle OCI database, Oracle AQ database, IBM-MQ series database, Microsoft MSMQ database, Microsoft Access, Oracle, Paradox,
It is a database such as Fox Pro and Microsoft (registered trademark) SQL server.

The intelligent queue 310 of FIG. 3 is implemented using several components, and in other embodiments, the intelligent queue 310 includes one component, for example, an index database similar to the intelligent queue process 320. Implemented as a proprietary data storage component 340 including 330.

The intelligent queue 310 can be in various modes, such as publish / join mode,
It is executed in the load distribution mode and the combination mode.

When the intelligent queue 310 is implemented in publish / join mode, the publisher places the message in an intelligent queue that can be read by more than one participant. In this publish / join mode, duplicate messages are avoided so that only one message is stored in this queue even if it is accessed by multiple participants.

When the intelligent queue 310 is implemented in load balancing mode, this queue allows participant pool processing. In this mode, the intelligent cue 31
0 receives messages from publishers scheduled for one of the participants. The issuer does not care which participant came to pick up the message, unless the message was picked up by one or more participants. A feature of load balancing is to reduce the average queue time and alleviate the bottleneck.

The intelligent queue 310 is configured to run in publish / join mode at any time. In another embodiment, the intelligent cue 310 is
It is configured to run in load-balancing mode at all times, and in yet another embodiment, triggers some things, such as when the amount of information on the network exceeds a predetermined threshold. When it comes to, it is supposed to run in load balancing mode. Further, in other embodiments, the intelligent cue 310 is
Each individual message is executed in the issue / participation mode, the load distribution mode, or the combination mode.

The intelligent queue 310 keeps track of the message state for each state as the message comes in. These message states correspond to events that arise from the perspective of the issuer and the perspective of the participants. FIG. 4 shows an embodiment of the message state and its transition.

The intelligent queue has two states: the issuer state 410 and the participant state 420.
Provides a class for one message state.

The issuer state 410 allows the message issuer to identify each message after placing the message in the message queue. PUT: Issuer puts a message in the message queue. REVERALED: The publisher makes the message available to participants. UNAVAILABLE: The message is unavailable to all participants. JOURNALLLED: All interested participants read the message.
The message becomes journaled (thus allowing extended message retention times), which causes other message processing to be performed (eg, archived by the system administrator, read by non-participants). Things etc.).

Participant state 420 allows each message participant to identify the state of each message after the message has been made available to the publisher in the intelligent queue. Message status information records the status of each message participant,
This prevents the already read message from being read by the participants. GET: The message participant initiates the read process. FETCHED: The message participant has successfully read the message, but has not finished. INPROCESS: The message participant is processing the message. UNABLE: The message read of the message participant failed. DONE: The participant has finished reading the message, but processes the message as needed. JOURNALLED: The message participant ends the message when the participant has successfully read it. The message is processed if necessary, and the message read fails or the message expires. The message is left in the journaled state (which allows extended message retention time), which causes other message processing to take place (for example, being archived by the system administrator, non-participant). To be read). EXPIRED: The message has expired beyond the prespecified deadline. This condition is automatically controlled or triggered by the issuer or participant.

In the embodiment shown in FIG. 4, some termination states, UNAVA
ILABLE state, JOURNALLED state, EXPIRED state, UNUS
There are an ABLE state, a DONE state, and a JOURNALLLED (IMPLIED) state. By changing the message state, the message is effectively journaled. This is because it is not necessary to copy the message to the archive directory or delete it. The resources normally required to copy or delete messages are allocated to other tasks.

To illustrate the publish / participant mode, assume that publisher X wants to publish a message that is read by participant 0, participant 1, and participant 2. Issuer X does not care about the order in which the messages are read, but wants to ensure that all participants read the message. In other embodiments,
The issuer specifies the order in which the messages are read, eg, the order in which the messages are simultaneously visible to the participants.

Referring to the first example, issuer X first places a message in the queue as an issue / join message. Next, the issuer X discloses the message to the participant 0, the participant 1, and the participant 2.

It is assumed that the participant 2 next starts processing the message and enters the Get state. Participant 2 then proceeds to fetch the message, to the Done state, and then to the Journaled state.

While Participant 2 was in the Fetched state, Participant 0 then begins processing the message in the Get state, then retrieves the message and proceeds to the Fetched state. Participant 0 determines whether the message is readable and then Unusable
The state may progress to the Journalled state. Participant 0 can then notify issuer X that the message cannot be retrieved.

Finally, the participant 1 can start message processing in the Get state and move to the Fetched state. Participant 1 can then process the message in the In Process state and proceed from the Done state to the Journalled state.

After all the participants 0, 1 and 2 have entered the Journalled state, the issuer X next proceeds to the Journalled state.

In this example, to describe the load balancing mode, assume that publisher X wishes to publish a message read by participant 0, participant 1, or participant 2. Issuer X does not care which participant reads the message, but wants it to be read by the first available participant. First, issuer X places a message in the queue as a load / balanced message. Next, the issuer X discloses the message to the participant 0, the participant 1, or the participant 2. If participant 2 starts processing the message,
Suppose you have entered the state. The message status for participant 0 and participant 1 is participant 0
And Expired in response to participant 1 being free and processing another message
It changes to the (expired) state and then to the Journalled state. As soon as Participant 2 successfully retrieves the message and moves to the Journalled state, Issuer X changes the message state to the Journalled state.

Although the examples above show intelligent queues that process specified messages in publish / join mode or load balancing mode, messages can be specified as a combination of both. For example, issuer X may wish to issue a message read by participant 0 or participant 1, participant 2, and participant 3. Therefore, in the end, the participant 0, the participant 2, and the participant 3 have the read message, or the participant 1, the participant 2, and the participant 3
Will have a message.

First, the issuer X places a message in the queue. In one embodiment, the intelligent queue can handle this as two messages, one message utilizing load balancing between participant 0 and participant 1 and another message participating. Use issue / participation mode for person 2 and participant 3.
In another embodiment, the issuer can specify to which participant the message is disclosed. Thus, after Participant 0 or Participant 1 has begun processing a message, the message expires the Participant (s) who did not read the message.

An advantage of one embodiment of the present invention is that message recovery can be performed in the event of a system failure. Moreover, message recovery also allows compatibility between intelligent queues that are implemented utilizing different data storage devices. In addition, compatibility enables data conversion, interfacing, correlation functions, and / or data recovery. Data conversion allows conversion of data from one format to another format, for example from MS IQ format to Oracle IQ format. In addition, the interface processing may be, for example, a network protocol,
It may include providing connection details such as application programming interface calls, long connections. The correlation function may include combining multiple messages into a single message and issuing it to another message queue. Data recovery may include the process of repairing messages in the queue. Therefore, regardless of the type of data storage device, messages can be recovered in the event of a system failure.

In this example, assume that the system shown in FIG. 1A is recovering from a system failure in order to demonstrate message recovery utilizing message state information during operation. In addition, the Sybase IQ140 comes in (inbound
) Queue and the MSMQ IQ 170 is an outbound queue. When a message is processed by the module, the original message is called the parent message and the processed message is called the child message. The following is one of a set of repair logical steps that can be used to repair a system. Step 1: Go through MSMQ IQ 170 to find messages not marked "Revealed". These messages have a "Clean" status. Step 2: When a "Clean" message is found, extract the path information and find the parent of that message. If the message does not have a parent, go to step 4. Step 3: Sybase IQ140 to check the status of each parent message
go to. If one of the parent messages is marked "Done", then all parent messages are marked "Done" and child messages are marked "Revealed".
If the parent message is not marked "Done", mark all parent messages as "Clean" and child messages as "Deleted". Step 4: If the message does not have a parent, add "Reve
Mark as "aled". Step 5: The “Clean” message in MSMQ IQ 170 is processed (“
After being recovered "), it goes through the Sirbase IQ 140 and" Fetche "instead of" Done ".
Find the message marked "d". Instead of these "Done,""Fetched
Mark messages that are "Clean". Therefore, if the POS module 130 fails, the following guidelines can be utilized to recover the message. Scenario 1: If the message is issued to the Sybase IQ 140 and the message is not retrieved, the process moves to step 1 and step 2, and then to step 4. Scenario 2: If the message is placed on Sybase IQ 140 and the message is marked "Fetced", let the participant recover. If the credit approval module 180 fails, the following guidelines can be used to recover the message. Scenario 1: Message is not marked as "Done" but retrieved (
fetched), go to step 5. If the customer database module 150 fails, the following guidelines can be used to recover the message. Scenario 1: If the message has not been put into MSMQ IQ 170 but fetched from Sybase IQ 140, go to step 5. Scenario 2: If the message is not put into MSMQ IQ 170 but fetched from Sybase IQ 140, go to step 1, step 2, then go to step 3. Scenario 3: Message is fetched from Sybase IQ140
), Is put on the MSMQ IQ170 (put), and "Don
If it is marked "e", the process moves to step 1 and step 2, and then to step 3.

It will be appreciated that the recovery logic described above illustrates one embodiment of message recovery utilizing message state information, and that other embodiments may be utilized.

In one embodiment, the message state is recorded in the file corresponding to the message and stored within the intelligent queue index. In other embodiments, the message states may be, for example, linked lists, finite state machines, trees,
It will be appreciated that it can be recorded in other data structures such as graphs. Further, in other embodiments, message status information may be placed within the message, such as with information about other messages.

FIG. 5 is a diagram showing an embodiment of the message object 510. The message object 510 includes message status information such as a message identifier, an issuer ID and a participant ID. Further, for each publisher and participant, the message status information includes a timestamp for each status that has already occurred and the current status. It will be appreciated that other forms of message information may be used in alternative embodiments. For example, in one embodiment the message identifier is automatically generated by the intelligent queue, while in another embodiment the message identifier is set by the issuer of the message.

For example, FIG. 5 illustrates a typical message object 510 issued by issuer X to participants 0-2 in issue / participate mode.
Issuer X places the message in the queue at 12:14:03. After 9 seconds, the message was informed, made available to the participant and read.
Finally, after the message has been journaled by all participants, issuer X
Journaled a message at 12:16:09.

Participant 0 started processing the message at 12:14:13. After 30 seconds, participant 0 took out the message and read the message at 12:14:54. Participant 0 then journaled the message at 12:15:02.

Participant 1 started processing the message at 12:14:25 and took out the message 61 seconds later. Participant 1 started processing the message at 12:15:51 and ended 10 seconds later. Participant 1 journaled the message at 12:16:07.

Participant 2 started processing the message at 12:15:08. Participant 2 is
I retrieved the message at 12:15:32, declared the message unusable at 12:15:44, and journaled the message at 12:15:59.

After the message has been journaled, Participant 2 can inform the Issuer that Participant 2 has encountered a problem reading the message, whereby
The issuer can make the message available again to the participant 2.

Furthermore, even if a system failure occurs, the system administrator can
Only Participants 0 and Participants 1 know that they have successfully read the message.

Intelligent queue 310 includes an intelligent queue process 320 that is used to add information to and extract information from the queue. In one embodiment, the intelligent queue process 320 includes a message receive process 322, a message status update process 324, and some other process 326 that provides information regarding the information contained in the queue. .

The receive message process 322 receives a message object from the issuer and queues the message object. FIG. 6 is a diagram illustrating one embodiment of a receive message process 322 in which a participant sends a message object to an intelligent queue.

Starting in the start state (block 610), the message receiving process 322 receives a message object from the issuer (block 620). The message receiving process then performs checks on the message object, such as error detection, error correction, and / or caller verification (block 630).
The receive message process 322 then stores the message in the data store (block 640). As mentioned above, storage of data is performed utilizing various data structures. For example, B + tree, flat file directory, linked list, tree, array, database, etc. Next, the receive message process 322 determines which participant is considering reading the message (block 660). This determination includes determining all participants that read messages such as publish / participate mode, i.e., all participants eligible to read messages such as load balancing mode. Finally, the receive message process 322 sends an alert to each participant that the message is available in the queue (block 670) and transitions to the end state (block 680).

The message status update process 324 receives a request for update from the issuer or participant and updates the corresponding message status in the index. FIG. 7 is a diagram illustrating one embodiment of a message state update process 324 in which an issuer or participant sends an update request to an intelligent queue.

Start in start state (block 710) and update message state process 32
4 receives a request for update from the issuer or participant (block 720). Requests for updates are in various formats such as e-mail, data structures, data records, message objects, etc. Next, the message status update process 324
Locates message status information in the index corresponding to the update request (block 730).
). Finally, the message status update process 324 updates the message status information with the update information (block 740) and proceeds to the end state (block 750). For example, the message state update process 324 adds a new timestamp of the current state to the corresponding state and modifies the value of the "current state" field corresponding to the current state.

It will be appreciated that in another embodiment, the message status information may be updated automatically. For example, when a participant receives a message, the intelligent queue can automatically record the time when the read was made.

Intelligent queue process 320 may include another process that provides information regarding information in a queue. For example, an intelligent queue can include a read message process of reading a copy of a message from the queue and sending that copy to the participants. Intelligent queues may also include a view message process that allows an external party to view message information and / or message status information in the queue without making any changes to the information. The set message priority process may also include the process of setting the priority of messages in the queue.
It is, for example, a set of Get Information processes that retrieve information about a specified portion of a message, which is a message subject, message handle, message header, and so on.

Although some examples according to the present invention, that is, some embodiments have been shown, the above examples are only meant to illustrate some applications according to the present invention. It does not limit the technical scope.

Although specific embodiments according to the present invention have been disclosed, these embodiments are shown as specific examples and do not limit the technical scope of the present invention. Therefore, the technical scope of the present invention should be determined according to the claims and their equivalents.

[Brief description of drawings]

FIG. 1A is a high-level block diagram illustrating one embodiment of an application integration system including intelligent queues.

FIG. 1B is a high-level block diagram illustrating another embodiment of an application integration system including intelligent queues.

FIG. 2A is a high-level block diagram illustrating another embodiment of an application integration system including intelligent queues.

FIG. 2B is a high-level block diagram illustrating another embodiment of an application integration system including intelligent queues.

FIG. 3 is a high level block diagram illustrating one embodiment of an intelligent queue.

FIG. 4 is a flow chart illustrating one embodiment of a state diagram for message states.

FIG. 5 is a diagram showing an embodiment of message information recording.

FIG. 6 is a flowchart illustrating one embodiment of a message receiving process.

FIG. 7 is a flow chart illustrating one embodiment of a message status update process.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW (72) Inventor Narbandian Jevik H.             United States 91326 California               North Bridge Los Alimos Sutri             18837 (72) Inventor Waldorf Jerry A.             United States 91317 California               West Hills Glen Havenco             Red 13172 (72) Inventor Nathan Kay.             United States 91104 California               Pasadena Casa Grande 1740 (72) Inventor Srihari Langaswami             United States 91007 California               Arcadia Santa Cruz Road               305 (72) Inventor Demetriades Alexander             United States 91106 California               Pasadena Blanche 1447 F term (reference) 5B085 AA08 AC13 AC16 BA07 BG02                 5B098 AA10 GA01 GB13 GC16 JJ08

Claims (52)

[Claims] 1. Managing a plurality of queues including a first message queue of a first data storage type and a second message queue of a second data storage type that exhibit consistent behavior across a plurality of computer media. A message queue management system configured to include a journaled message comprising a journaled state held in the first message queue and the second message queue, the first message queue and the A journal module configured to track and manage the message state of messages stored in a second message queue; and messages already stored in the first message queue and the second message queue. Track multiple message states to avoid reprocessing A one-time message processing module configured to do so, a compatibility module configured to coordinate interactions between multiple queues to enable distributed workflows, and data from multiple queues in the event of a failure. A recovery module configured to perform recovery; a central management module configured to provide centralized control of multiple queues, including control of multiple issuers and multiple participants; and the first message. Assigning a subset of participants to at least the first message queue in the participant pool so that the message in the queue is processed by the first valid participant in the participant pool A message queue management system comprising: a load balancing module configured to: 2. The message queue management of claim 1, wherein the load balancing module is further configured to allow participation in at least the first message queue with participants not in the participant pool. system. 3. A message queue management system for computer networks that provides reliable communication, guarantees non-repeated distribution, and is implemented in a media independent environment, wherein at least a plurality of message participants are provided with the message. Storing the message received from the message issuer, running on one of a number of environments, where the message will be held in a message queue after accessing the message and allowing additional access to the message, A message queue that monitors reading by a plurality of message participants, and a message status of the message, the message status information indicating whether the message has been validated and read by at least one of the plurality of message participants. Message state module configured to track Sending and receiving multiple data object types in a message, with a recording module configured to selectively retain message state information associated with the corresponding message, at least until the message is removed from the message queue; And a message queuing system comprising an interface module configured to communicate with a type of multiple data message system acting as a message issuer or message participant. 4. At least one of the plurality of data messaging systems comprises:
The message queue system according to claim 3, which acts as both a message issuer and a message participant. 5. The message queue system of claim 3, wherein the message queue is further configured to provide load balancing. 6. The load balancing is performed using a pool of participants.
The message queue system described in. 7. The message queuing system of claim 3, wherein the message state information is used to ensure that it is obtained in an order specified by at least one of a plurality of message participants. 8. The message queue system of claim 3, wherein the message is intended for one message participant. 9. The message queue system of claim 3, wherein the message is intended for multiple message participants. 10. The message is during a specified cleanup process.
The message queue system according to claim 3, wherein the message queue system is deleted from the message queue. 11. The message queue system of claim 3, wherein the message is retained in the message queue to assist in message recovery during system failure. 12. The message queue system of claim 3, wherein the message is retained in a message queue to assist in at least one of storing the message, manually distributing the message, editing the message, or resending the message. . 13. The message queue system of claim 3, wherein the message is intended for multiple message participants. 14. The message queue system of claim 3, wherein the message status information includes message issuer status information and corresponding message participant status information. 15. The message queuing system of claim 3, wherein the message status information is stored in the message. 16. The message state reflects the state of the message publisher of the message associated with the message participant of interest and the state of individual message participants of the message associated with the individual message participant. The message queue system described in. 17. The message queue system of claim 3, wherein the message status includes a sequence number, issuer status information and participant status information. 18. Issuer status information includes information related to an "unrevealed" status, information related to a "revealed" status, information related to an "unavailable" status, and a "journalled" status. 18. The message queuing system of claim 17, including relevant information. 19. The participant status information includes information related to a "get" status, information related to a "fetched" status, information related to an "unusable" status, and an "expired" status. Related information, information related to the "inprocessed" state,
18. The message queuing system of claim 17, including information associated with the "done" state and information associated with the "journalled" state. 20. The message queue system of claim 3, wherein the message queue is configured to interface with multiple different database protocols. 21. At least one of a plurality of data message system types
The message queue system according to claim 3, wherein one is a database. 22. At least one of a plurality of data messaging system types
The message queue system of claim 3, wherein one is a flat file directory. 23. At least one of a plurality of data message system types
4. The message queue system according to claim 3, wherein one is a second message queue system. 24. The message queuing system of claim 3, wherein at least one of the plurality of data objects is a database record. 25. The message queuing system of claim 3, wherein at least one of the plurality of data objects is an email message. 26. The message queue system of claim 3, wherein at least one of the plurality of data objects is a web page. 27. A method of message queuing between multiple message publishers and multiple message participants, wherein a data object from a message publisher intended for at least one message participant is received. Processing the data object and generating a corresponding message containing the data object and the message information; storing the message in a message queue; tracking the message state from the perspective of the message issuer; Tracking the message state from the perspective of at least one message participant, and selectively retaining the message so that it remains in the message queue after being read by the at least one message participant. Comprise How to be. 28. The method of claim 27, wherein the message queue can be configured to run on multiple platforms. 29. The method of claim 27, wherein the message queue can be configured to provide load balancing. 30. The method of claim 27, wherein the message queue is configurable to provide participant pool processing. 31. The method of claim 27, wherein the message information includes a message identifier and a message header. 32. The method of claim 28, wherein the message header includes message status information. 33. The message header includes message status information for the message publisher and at least one of the message participants.
The method described in. 34. The message information for the message issuer includes information related to a message issuer state, the message issuer state being "pu.
34. The method of claim 33, including a "t" state, an "unavailable" state, a "revealed" state, and a "journalled" state. 35. The message information for at least one of the message participants includes information related to a message participant state, the message participant state being a "get" state, a "fetched" state, an "unusable". 34. The method of claim 33, including "states,""expired" states, "inprocess" states, "done" states, and "journalled" states. 36. The method of claim 32, wherein the message status information is stored in a log that includes a time stamp for the corresponding message status. 37. A method of journaling a plurality of messages to a message queue, the plurality of messages including a plurality of corresponding message states, the method comprising receiving a message including a publisher message state and a participant message state. A method comprising placing the message in a message queue, changing the issuer message state of the message to a journal state, and holding the message in the message queue. 38. The method further comprising changing the participant message state of the message to an end state to avoid reprocessing the message.
7. The method according to 7. 39. A method of pooling a plurality of messages in a message queue to a participant queue, the plurality of messages including corresponding issuer status, the step of placing the message in the message queue, the message being available. The step of notifying a plurality of participants that the message is read by one of the plurality of participants, by changing the issuer message state to an end state, a message read by another person of the plurality of participants can be performed. A step of preventing. 40. A system for message queuing between a plurality of message issuers and a plurality of message participants, the system comprising: communicating with a plurality of message issuers and a plurality of message participants; A message queue module configured to receive a data object from a message issuer for at least one of: a corresponding message including the data object and message information; A data object processing module configured to process a data object, an issuer tracking module configured to track the message state from the perspective of a message issuer, and at least one of a plurality of message participants of interest. From one standpoint, A plurality of participant tracking modules configured to track message status and at least one of a plurality of targeted message participants selectively selects the messages remaining in the message queue after the messages have been read. And a message tracking module configured to hold the system. 41. The system of claim 40, wherein the message queue module is further configured to provide load balancing. 42. The system of claim 40, wherein the message queue module is further configured to provide participant pooling. 43. The system of claim 40, wherein the message information includes a message identifier and a message header. 44. The message header includes message status information for the message publisher and the at least one message participant.
The system described in. 45. The system of claim 40, wherein the message information comprises message status information. 46. The system of claim 45, wherein the message status information is stored in a log that includes a time stamp for the corresponding message status. 47. A method of queuing a message received from an issuer for reading by a participant, wherein the queue interface module is configurable to interface with multiple database protocols, the queue and the queue interface. Save the message using the module, extend the message save beyond the time the message was read by all intended participants, and set the message state to perform a one-time delivery. Tracking step. 48. Tracking message status comprises tracking information related to message publisher status and message participant status.
7. The method according to 7. 49. The message issuer status is "put" status, "unavailab"
49. The method of claim 48, including a "le" state, a "revealed" state, and a "journalled" state. 50. The message issuer status is “get” status, “fetched”
49. The method of claim 48, including states, "unusable" states, "expired" states, "inprocess" states, "done" states, and "journalled" states. 51. A system for queuing a message received from an issuer for reading by a participant, the queue interface module being configurable to interface with a plurality of database protocols, the queue and the queue. A means to store messages using the interface module, a means to extend message storage beyond the time the message was read by all intended participants, and message status to perform one-off delivery. And a means for tracking the system. 52. A message communication between a first message queue performed with a first type of data retention and a second message queue performed with a second type of data retention. A method of repairing, processing the first message queue to confirm the location of an undisclosed message, and for an undisclosed message, a path to discover a parent message of the message. Deriving information, checking the status of the parent message in the second message queue, and if at least one of the parent messages is marked as "done", the parent message is "done" If marked as "revealed" and the parent message is not marked as "done",
"clean", and marking the message as "deleted" and if the parent does not exist, marking the message as "revealed" in the second message queue, and marked "clean" To recover the message and to find the message marked as "fetched" instead of "done"
A method comprising: processing the second message queue; and marking the message marked "fetched" instead of "done" as "clean".