Message queue architecture and interface for a multi-application platform

Patent metadata

Field	Value
Publication number	US-11277369-B1
Application number	US-202117189782-A
Country	US
Kind code	B1
Filing date	Mar 2, 2021
Priority date	Mar 2, 2021
Publication date	Mar 15, 2022
Grant date	Mar 15, 2022

Abstract

Non-volatile memory may contain definitions of: (i) a plurality of message queue implementations respectively associated with different queue behaviors, the different queue behaviors specified by corresponding sets of modes, and (ii) an application programming interface (API) through which applications can access one or more message queues. One or more processors may be configured to: create a message queue of a particular message queue type, supported by a corresponding message queue implementation, by specifying a set of modes corresponding to a queue behavior; receive, from a producing application and by way of the API, one or more messages for the message queue; store the one or more messages in a data structure associated with the message queue; receive, from a consuming application and by way of the API, a request to read from the message queue; and provide a message from the message queue to the consuming application.

First claim

The invention claimed is:

1. A system comprising:
non-volatile memory containing definitions of: (i) a plurality of message queue implementations respectively associated with different queue behaviors, wherein the different queue behaviors are specified by corresponding sets of modes, and (ii) an application programming interface (API) through which applications executing on the system can access one or more message queues of the message queue implementations, wherein the sets of modes includes an ordering mode that is either chronological or priority, wherein the ordering mode being chronological results in the message queue having first-in-first-out (FIFO) operation, wherein the ordering mode being priority results in the message queue having non-FIFO operation, wherein the non-FIFO operation involves all messages in the message queue being assigned one of a plurality of priorities, wherein a first priority of the plurality of priorities has a higher precedence than a second priority of the plurality of priorities, wherein the system is configured to cause the message queue to deliver m messages of the second priority for every n messages delivered of the first priority, and wherein n>m; and
one or more processors configured to:
create a message queue of a particular message queue type, supported by a corresponding message queue implementation, by specifying a set of modes corresponding to a queue behavior of the particular message queue type;
receive, from a producing application executing on the system and by way of the API, one or more messages for the message queue;
in response to receiving the one or more messages, store the one or more messages in a data structure associated with the message queue and in accordance with the set of modes;
receive, from a consuming application executing on the system and by way of the API, a request to read from the message queue; and
in response to receiving the request, provide a message from the message queue to the consuming application in accordance with the set of modes.

2. The system of claim 1 , wherein the one or more processors are further configured to:
create a second message queue of a second particular message queue type, supported by a corresponding message queue implementation, by specifying a second set of modes corresponding to a second queue behavior of the second particular message queue type;
receive, from a second producing application executing on the system and by way of the API, one or more further messages for the second message queue;
in response to receiving the one or more further messages, store the one or more further messages in a second data structure associated with the second message queue and in accordance with the set of modes;
receive, from a second consuming application executing on the system and by way of the API, a second request to read from the second message queue; and
in response to receiving the second request, provide a second message from the second message queue to the second consuming application in accordance with the set of modes.

3. The system of claim 1 , wherein the message queue is created with a name, wherein the producing application provides the name with the one or more messages, wherein the consuming application provides the name with the request, and wherein the system uses the name to identify the message queue.

4. The system of claim 1 , wherein a messaging framework within the system includes: (i) a producer module configured to receive the one or more messages from the API and place the one or more messages in the message queue, and (ii) a consumer module configured to receive the request from the API, identify the message, and provide the message to the API.

5. The system of claim 4 , wherein the message contains a body, a client header, and a service header, wherein the body contains content from the producing application that the producer module and the consumer module transparently provide to the consuming application, wherein the client header contains metadata from the producing application that the producer module and the consumer module transparently provide to the consuming application, and wherein the service header contains metadata that is not provided to the consuming application, and is used by the producer module or the consumer module.

6. The system of claim 4 , wherein the messaging framework also includes a context configured to store mappings between the different queue behaviors and their associated message queue implementations, and wherein the producer module and the consumer module use the context to identify the message queue.

7. The system of claim 1 , wherein the set of modes includes a messaging mode that is either point-to-point or publish/subscribe, wherein the messaging mode being point-to-point results in the message being removed from the message queue when provided to the consuming application, and wherein the messaging mode being publish/subscribe results in the message persisting in the message queue when provided to the consuming application.

8. The system of claim 1 , wherein the set of modes includes a delivery mode that is either in-memory, persistent, or persistent cached, wherein the delivery mode being in-memory results in messages in the message queue being stored only in volatile memory, wherein the delivery mode being persistent results in the messages in the message queue being stored only in the non-volatile memory, and wherein the delivery mode being persistent cached results in the messages in the message queue being stored in the volatile memory and at least some of the messages being cached in the non-volatile memory.

9. The system of claim 1 , wherein the set of modes includes a connection mode that is either unidirectional or bidirectional, wherein the connection mode being unidirectional results in messages in the message queue only flowing from the producing application to the consuming application, and wherein the connection mode being bidirectional results in some of the messages in the message queue flowing from the producing application to the consuming application and other messages in the message queue flowing from the consuming application to the producing application.

10. A computer-implemented method comprising:
creating a message queue of a particular message queue type by specifying a set of modes corresponding to a queue behavior of the particular message queue type, wherein non-volatile memory contains definitions of: (i) a plurality of message queue type respectively associated with different queue behaviors, wherein the different queue behaviors are specified by corresponding sets of modes, and (ii) an application programming interface (API) through which applications can access one or more message queues of the message queue types, wherein the sets of modes includes an ordering mode that is either chronological or priority, wherein the ordering mode being chronological results in the message queue having first-in-first-out (FIFO) operation, wherein the ordering mode being priority results in the message queue having non-FIFO operation, wherein the non-FIFO operation involves all messages in the message queue being assigned one of a plurality of priorities, wherein a first priority of the plurality of priorities has a higher precedence than a second priority of the plurality of priorities, wherein the message queue delivers m messages of the second priority for every n messages delivered of the first priority, and wherein n>m;
receiving, from a producing application and by way of the API, one or more messages for the message queue;
in response to receiving the one or more messages, storing the one or more messages in a data structure associated

Assignees

• Servicenow Inc

Inventors

• Motamedi Khosrow Jian
• Bendre Nikhil Prashant
• Nelson Harry Thomas
• Kumar Sunil

Classifications

• H04L51/226 Primary

  Delivery according to priorities · CPC title

• H04L51/214

  using selective forwarding · CPC title

• H04L51/18

  Commands or executable codes · CPC title

• G06F9/546

  Message passing systems or structures, e.g. queues · CPC title

• H04L41/342

  between virtual entities, e.g. orchestrators, SDN or NFV entities · CPC title