Patent Description:
Distributed systems, such as cloud computing environments, are becoming more widely used to offer an array of software services. As these software services grow and businesses integrate multiple services into their workflow, the coordination between these services may become increasing critical. That is, a client's reliance on the compatibility between services demands robust communication between processes of these services. Additionally, clients prefer the robust collaboration between processes to operate in a cost efficient manner from both a computing cost as well as a financial cost. This translates to the fact that when messaging systems coordinate actions between processes, the communication between these processes should avoid wasteful and latency-inducing operations.

<CIT> discloses a framework for dynamic brokerage and management of topics and data at a service layer.

One aspect of the disclosure provides a computer-implemented method of implementing an event-based distributed messaging service. The computer-implemented method, when executed by data processing hardware, causes the data processing hardware to perform operations. When instantiating a requesting process that publishes a request for a response from a responding process, the operations include identifying a response topic of a distributed messaging service that receives the response for the request from the responding process where the responding process is configured as a publisher for the response topic. Also when instantiating a requesting process that publishes a request for a response from a responding process, the operations include generating a plurality of subscriptions for the response topic where each subscription includes a subscription identifier. During runtime for the requesting process, the operations further include publishing a request message to a request topic subscribed to by the responding process where the request message includes a unique message identifier and generating a subscriber using a respective subscription identifier of a respective subscription selected from the plurality of subscriptions where the subscriber includes the unique message identifier. Furthermore, during runtime for the requesting process, the operations also include receiving, at the subscriber, a filtered response message from the responding process in response to the request message published to the response topic. Here, the filtered response message is filtered based on one or more subscription identifiers associated with the plurality of subscriptions for the requesting process.

Another aspect of the disclosure provides a system for implementing an event-based distributed messaging service. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that when executed on the data processing hardware cause the data processing hardware to perform operations. When instantiating a requesting process that publishes a request for a response from a responding process, the operations include identifying a response topic of a distributed messaging service that receives the response for the request from the responding process where the responding process is configured as a publisher for the response topic. Also when instantiating a requesting process that publishes a request for a response from a responding process, the operations include generating a plurality of subscriptions for the response topic where each subscription includes a subscription identifier. During runtime for the requesting process, the operations further include publishing a request message to a request topic subscribed to by the responding process where the request message includes a unique message identifier and generating a subscriber using a respective subscription identifier of a respective subscription selected from the plurality of subscriptions where the subscriber includes the unique message identifier. Furthermore, during runtime for the requesting process, the operations also include receiving, at the subscriber, a filtered response message from the responding process in response to the request message published to the response topic. Here, the filtered response message is filtered based on one or more subscription identifiers associated with the plurality of subscriptions for the requesting process.

Implementations of either the computer-implemented method or the system of the disclosure may include one or more of the following optional features. In some implementations, the operations also include, during runtime for the requesting process, randomly selecting the respective subscription from the plurality of subscriptions. In some examples, the operations during runtime for the requesting process further include generating the request message for the request topic. The subscription identifier may be unique among a plurality of instances of the requesting process. The subscription identifier may include a unique filter value and the filtered response message that filtered based on the unique filter value of the respective subscription used to generate the subscriber. In some examples, each respective subscriber of a respective topic of the distributed message system functions as a multicast subscription that retrieves all messages communicated on the respective topic.

In some configurations, when instantiating the requesting process that publishes a request for a response from the responding process, the operations also include storing each subscription identifier of the plurality of subscriptions for the response topic at a hash map. In these configurations, during runtime for the requesting process, the operations include randomly selecting the respective subscription identifier from the hash map storing each subscription identifier of the plurality of subscriptions for the response topic.

In some implementations, during runtime for the requesting process, the operations also include filtering one or more messages by publishers of the request topic. Here, the filtering occurs by determining whether the one or more messages by the publishers of the request topic include the unique message identifier. When a respective message of the one or more messages by the publishers of the request topic fails to include the unique message identifier, the operations include preventing the respective message from being received by the subscriber. In these implementations, the one or more messages by the publishers of the request topic include the filtered response message. When the filtered response message includes the unique message identifier, the operations, during runtime for the requesting process, additionally include generating an acknowledgement message.

Optionally, the requesting process may be instantiated in response to receiving an initial request to perform a computing task. When the requesting process is instantiated in response to receiving an initial request to perform a computing task, the operations during runtime for the requesting process further include, upon receipt of the filtered response message from the responding process in response to the request message published to the request topic, generating an initial response to the initial request to perform the computing task.

As more businesses and individuals use distributed computing systems (i.e., cloud-based computing systems), these distributed computing systems may use some type of client-facing mechanism to perform tasks for various processes associated with one or more service offered by the distributed system. For example, a client (i.e., the businesses and/or individual users) may use an analytical platform (i.e., data analytics service) that performs data analytics on client data. An action hub that serves as a type of client-facing mechanism may be part of the analytical platform and enable the client to perform actions on the data being analyzed by the analytical platform. Here, by having a client-facing mechanism, such as an action hub, integrated with the analytical platform (e.g., a data analytics system), the client avoids having to use one system to coordinate tasks and another separate system to perform the data analytics.

Moreover, clients will often integrate a component of one software service with functionality of another software service. To continue the example of the analytical platform, a client of the action hub for the analytical platform may want to send an email to users of the client. In this example, the client may use the analytical platform to generate a visual financial report for the client based on the client's data and the client may then want to communicate that visual financial report to several users of the client (e.g., employees of a business who is the client). To produce this email of the visual financial report, the client schedules an action with the action hub where the action is to communicate the financial report as an email to the intended recipients. Action hub would generate a request to retrieve the visual financial report and, once the financial report is retrieved, the action hub would perform a triggered action to send the financial report to the intended recipients. Here, the send action is a triggered action or event-based action because the action of sending the visual financial report is triggered by the event of receiving the visual financial report in response to the retrieval request. That is, an event-based action refers to an action that occurs in response to a particular event or set of events.

One issue that arises with a client-facing mechanism like the action hub is that the tasks being coordinated through the action hub may be important or even critical workloads for the client. In other words, the client may be a business that depends on the actions being coordinated from the action hub to operate. For instance, a financial client or team of the client may rely on financial data management or financial data storage in conjunction with data analytics for that financial data. For example, a finance team at the client relies on the email that includes the visual financial report to assess financial investments. If the action hub has some failure due to workload across all clients or for some other reason, this failure can compromise client relationships and may even lead to clients controlling or hosting their own version of an action hub as a failsafe.

Failure may happen for various reasons, but one issue that may lead to failures is the way events are coordinated to perform a particular task. To coordinate a particular set of events that enable the task to occur, a client-facing mechanism, such as the action hub, employs a distributed messaging system. A distributed messaging system allows messages to be published about a particular topic and for subscribers of that topic to receive the messages published about that topic. A topic generally refers to a named resource configured by the distributed messaging system for a publication-subscription relationship. In this sense, a client-facing mechanism like the action hub operates in conjunction with the distributed messaging system to request that a particular action is performed and to communicate when that particular action has been performed.

To illustrate with the email of the visual financial report, the action hub uses the distributed messaging system to generate a request message for the retrieval of the visual financial report for the topic of retrieving visual financial reports. A subscriber of that topic may be an application or service that either generates or is capable of retrieving the visual financial report. The subscriber may then function as a publisher to generate a message that includes the visual financial report and to publish that message to a topic of retrieved visual financial reports. The action hub may then use the distributed messaging system to generate a request message to send the report as an email to a topic of generating emails. A subscriber of the topic of generating emails may receive the request message with the visual financial report and use an email service or email application to send the visual financial report to the intended recipients. When the action of sending the email has been performed, that subscriber then operates as a publisher to publish a response message to a topic of communicated emails that communicates that the email with the report has been sent. A subscriber of the topic of communicated emails receives the response message. At this stage, the action hub may indicate that the action of emailing the visual financial report to the designated recipients is complete and no further action may be taken for the task.

Although this messaging sequence appears successful for the client's action, scaling this process may become problematic. For instance, in a publisher-subscriber messaging system, a subscriber generally does not solely receive the relevant message related to the client's action, but rather a subscriber subscribes to a topic and is configured to receive all messages for that particular topic. With a publisher-subscriber system, the distributed messaging system may push messages to a subscriber when messages are received on a particular topic to which the subscriber subscribes or the subscriber may pull (i.e., retrieve) messages from a topic to which the subscriber subscribes on its own accord. Yet unfortunately in either scenario, the subscriber receives a message on a topic and often has no understanding of the context of the message prior to receipt (other than the general context that the message relates to the topic). In a system of scale when multiple publishers (e.g., thousands of publishers) generate different messages related to a myriad of actions, for a subscriber to identify a particular message becomes cumbersome and leads to a large amount of data egress. For example, in the case of the report email, the final subscriber to the topic of communicated emails is waiting for a publisher associated with an action container to indicate that the email with the visual financial report has been sent. Yet the topic of communicated emails may receive thousands of messages regarding email communication and the final subscriber is left trying to identify if any of these thousands of messages relate particularly to the email of the visual financial report.

One approach to attempting to identify if any of these thousands of messages relate to the email of visual financial report is for the final subscriber to pull all messages received on the topic and to sift through the one thousand messages until the final subscriber identifies the single message of interest. This process generates a large amount of data egress because the distributed messaging system, in the case of one thousand messages, has to transmit an additional nine-hundred and ninety-nine extra messages to the subscriber; generating additional computing costs and having the potential to trigger false events during the process. Also as businesses themselves, cloud service providers typically charge the client for data egress making this process costly for each party involved.

To extend this example further, there may be multiple subscribers for a topic and each subscriber may be trying to identify a message that confirms an action has been completed. Therefore, instead of a single subscriber having nine-hundred and ninety-nine extra messages, the egress becomes multiplied across all the subscribers. That is, with one hundred subscribers, these one hundred subscribers are receiving a total of <NUM>,<NUM> additional message because each of the one hundred subscribers is interested in a single message. Moreover, distributed computing infrastructure providers generally have rate limits that limit the rate of requests for a particular call. That is, the cloud provider may have a rate limit of two-hundred request per second per call, which would cause the subscriber to wait <NUM> seconds in response to a call to generate the one thousand requests for the one thousand messages on the topic. With rate limits, clients may be forced to experience high latency especially in regard to actions with multiple events (e.g., multiple subscription calls).

One approach to overcome these egress issues is to generate a filter or unique request identifier each time a particular action request occurs. This would mean that a request to generate an email of the visual financial report would cause an instance to be created with a unique request identifier for that particular action. This instance would generate a subscription to the necessary topics for the action to be performed, but the subscription would include the unique request identifier as a means of filtering response messages to prevent the potential of a large amount of egress. Although this approach may reduce egress, this approach also generates unique instances that cannot be leveraged by the system for other tasks. In other words, with the unique request identifier, the instance is completely unique to the request and cannot reuse its structure for any other requests. Unfortunately, the financial team at the client may generate the email of the visual financial report weekly because the report may be dynamic and an instance generated by the system for one week with a unique request identifier is unable to be used again the following week. In other words, this unique request identifier approach results in potentially frequent instantiation by the system.

To address these egress issues while also being conscientious of instantiation, the approach described herein changes the way a process is instantiated such that the instantiation of the process includes filters, but the filters that are not unique to a particular action request. Rather, during instantiation for a process, the system generates N number of subscriptions to a topic for the process where each subscription includes a unique value (e.g., unique filter value). Instead of tying these unique values to a particular request during creation (i.e., instantiation of the process) and thereby generating limited purpose subscriptions, the system generates subscribers based on these subscriptions when the system receives an action request. That is during runtime following instantiation of the process with the N subscriptions, the system receives a request for the process and creates a subscriber that uses a unique value associated with a particular subscription that was previously instantiated. In this sense, the unique value functions as a filter for the particular request, but the creation of this filter does not restrict the subscription to that particular request. This means that, for a first request, the system may create a subscriber based on an instantiated subscription by using the unique value of the instantiated subscription, but, when a second request occurs in the future, another subscriber may be generated that uses the same unique value of the instantiated subscription for its filter. Therefore, when the first request is complete, the subscriber specific to the first request may be obsolete, but the value serving as its filter value may be used for some later request on the process. Furthermore, by instantiating N number of subscriptions, the process may be scaled to operate N number of simultaneous requests. For example, each simultaneous request is able to use one of the N subscriptions' unique value to form a subscriber.

<FIG> is an example of a cloud computing environment <NUM>. The environment <NUM> includes one or more clients <NUM> who communicate via a network <NUM> with a remote system <NUM>. The clients <NUM> communicate with the remote system <NUM> to access and to execute various computing platforms. In other words, a remote system <NUM>, such as a cloud computing environment, may offer various software as a service (SaaS) platforms where customers of the cloud environment <NUM> are the clients <NUM>. In this respect, a client <NUM> may range from being a business or enterprise to an individual user of the cloud environment <NUM>.

The client <NUM> may generally refer to any user of the remote system <NUM>. The client <NUM> communicates with the remote system <NUM> using a client device <NUM> that may correspond to any computing device associated with the client <NUM>. Some examples of client devices <NUM> include, but are not limited to, mobile devices (e.g., mobile phones, tablets, laptops, e-book readers, etc.), computers, wearable devices (e.g., smart watches), music player, casting devices, smart appliances (e.g., smart televisions) and internet of things (IoT) devices, remote controls, smart speakers, etc. The remote system <NUM> may include remote resources, such as remote data processing hardware <NUM> (e.g., remote servers or CPUs) and/or remote memory hardware <NUM> (e.g., remote databases or other storage hardware). The client device <NUM> may utilize the remote resources to perform various functionality related to processes of services of the remote system <NUM>. These processes may be hosted by the remote system <NUM> or integrate with local resources of the client device <NUM>.

The client <NUM> (e.g., via the client device <NUM>) interacts with an action system <NUM> (e.g., also referred to as an action hub <NUM>) to have the action hub <NUM> perform a particular action submitted by the client <NUM> as an action request <NUM>. Here, an action may refer to any computing task utilizing some functionality of the various services associated with the remote system <NUM>. Often, a client <NUM> may generate an action request <NUM> to have client data that has been processed or analyzed by a particular service of the remote system <NUM> be integrated or used by another service. For example, the client <NUM> requests an action <NUM> to use an email service to send an email that includes the financial report about the client data that has been generated by an analytical service of the remote system <NUM>.

Once the action associated with the action request <NUM> has been completed or attempted to be completed, the action hub <NUM> may generate a response <NUM> to inform the client <NUM> (e.g., client device <NUM>) of the status for the action from the action request <NUM>. When the response <NUM> is that the action has been completed (e.g., a response message <NUM> indicates that a process <NUM> has performed the action), the action hub <NUM> may communicate an actual message or some other form of communication to the client <NUM> to indicate completion of the action. In some examples, the action hub <NUM> displays that the action has been completed as a status for the action in a client-facing interface. In some configurations, the request <NUM> and/or the response <NUM> are messages using Hypertext Transfer Protocol Secure (HTTPS) or Hypertext Transfer Protocol (HTTP).

As shown in <FIG>, the action hub <NUM> may be associated with or include a messaging system <NUM> and an event servicer <NUM>. The action hub <NUM> is shown as a dotted box around the messaging system <NUM> and the event servicer <NUM> because these components may be part of the action hub <NUM> itself or separate from, yet in communication, with the action hub <NUM>. Here, the messaging system <NUM> may refer to a distributed messaging system that operates by coordinating asynchronous events. Here, asynchronous refers to the fact that the events do not have to be concurrently occurring. The same is generally true about asynchronous messaging. Messages may be exchanged between, for example, two processes (e.g., the first process <NUM>, 170a and the second process <NUM>, 170b) without the need for a current conversation (i.e., direct contact) to be taking place between the processes <NUM>.

If the request <NUM> was to send an email with the visual financial report and the visual financial report was already obtained, the events to fulfill that request would be to communicate a request to some service capable of sending the email and to solicit a response that the action has been completed. Here, the service capable of performing an action is generally referred to as an action container. An action container refers to an instance of a process <NUM> that is capable of performing the designated action. A distributed system often may prefer to use an action container because the action container may be contained (i.e., isolated) in the distributed system such that operations performed in the action container do not unnecessarily impact other services or workloads of the distributed system. In this sense, an action container may contain an instance of a particular service or application such that the remote system <NUM> may scale the number of instances to accommodate for the current workload or anticipated workload on resources of the remote system <NUM>.

When using action containers to perform some or all of a particular action, the action hub <NUM> generally is not able to know whether the requested action <NUM> has been performed unless there is some feedback that the action has been processed. That is to say that the process <NUM> in the action container may perform the designated action, but the action hub <NUM>, without more information, is unaware of the process's performance. In this respect, the process <NUM> also leverages the messaging system <NUM> to communicate that the action is complete.

In some examples, to function asynchronously, the messaging system <NUM> operates in a publisher-subscriber configuration. A publisher-subscriber configuration is such that certain processes <NUM> function as publishers <NUM> who publish a message <NUM> on a particular topic <NUM> while a subscriber <NUM> of that topic <NUM> has a subscription to the topic <NUM> that makes it aware that a message <NUM> has been generated on the topic <NUM>. For example, the messaging system <NUM> configures topics <NUM> where each topic <NUM> includes a storage space where messages <NUM> are stored on that particular topic <NUM>. When a subscriber <NUM> receives an indication that there is a message <NUM> on the topic <NUM> to which it subscribes, the subscriber <NUM> may retrieve (e.g., pull) the message <NUM> from the corresponding storage location. In some implementations, the messaging system <NUM> is configured to push messages <NUM> on one or more topics <NUM> to the subscribers <NUM> of that topic <NUM> such that when a message <NUM> about a topic <NUM> is received, the messaging system <NUM> communicates that message <NUM> to all subscribers <NUM> who have subscriptions to that topic <NUM>. The publisher-subscriber relationship may be one to many, meaning that one publisher <NUM> publishes a message <NUM> about a topic <NUM> to which multiple subscribes <NUM> subscribe, many to one, meaning that multiple publishers <NUM> publish a message <NUM> about a topic <NUM> to one subscriber <NUM>, or some variation thereof. Moreover, with this form of distributed messaging, the number of publishers <NUM> and/or subscribers <NUM> for a given topic <NUM> may dynamically change based on the messaging needs of the distributed system. What this means is that the remote system <NUM> may instantiate multiple instances of action containers of a process <NUM> that generates emails.

In a publisher-subscriber model, a process <NUM> that has been instantiated may be a publisher <NUM>, a subscriber <NUM>, or both. For instance, the process <NUM> is a publisher <NUM> to a first topic <NUM>, 166a and a subscriber <NUM> to a second topic <NUM>, 166b. That means that the process <NUM> may generate one or more messages <NUM> about the first topic 166a and listen to/receive one or more messages <NUM> about a second topic 166b. To illustrate, a process <NUM> contained in an instance of an application container may be a subscriber <NUM> for a first topic 166a that would inform the process <NUM> as to actions that the process <NUM> has been requested to perform and also be a publisher <NUM> for a second topic 166b that functions as a topic to indicate that the requested action has been performed. In the email example, the process <NUM> is an email application capable of generating an email that attaches the visual financial report. The email application is a subscriber <NUM> to a first topic 166a for email requests and functions as a publisher <NUM> to a second topic 166b about communicated emails.

The event servicer <NUM> is a system that is configured to prevent large amounts of data egress when performing actions using the remote system <NUM>. <FIG> illustrates how data egress may occur when using a publisher-subscriber messaging system <NUM>. In this illustration, both process A and process B have been instantiated five times. Each instance of process A has been configured as a publisher <NUM>, 162a-e to a first topic 166a and a subscriber <NUM>, 168f-j of a second topic 166b. Although the topics <NUM> will vary based on the action involved, to maintain the ongoing example, the first topic 166a is a topic <NUM> for email requests and the second topic 166b is for communicated emails. In complimentary fashion, each instance of process B has been configured as a subscriber 168a-e on the first topic 166a and a publisher 162a-e for the second topic 166b. Each instance of process A generates a message request <NUM>, 164a-e as a publisher <NUM> that requests a particular action be performed by process B. Here, each message request <NUM> is unique to the particular instance of process A. For example, process B may be an email application and each message request <NUM> requests process B to generate an email with different parameters (e.g., content, recipient, attachments, etc.). Each message <NUM> is shown to be unique by the different fill patterns within the circle element designated as the message request <NUM>. In this example, the grey-filled message request <NUM>, 164a (or first message request 164a) from the first instance of process A is the request for process B to generate the email with the visual financial report. Each instance of process B, as a subscriber <NUM>, receives a message request <NUM> about the first topic 166a. When an instance of process B receives the message request <NUM>, it performs the respective action requested in the message <NUM>. Once each instance of process B communicates a parameterized email as requested, each instance of process B publishes a response message 164f-j as a publisher 162f-j about the second topic 166b (i.e., that the respective email has been sent). Each instance of process A also subscribes as a subscriber 168f-j to the second topic 166b about email communications such that each instance of process A is able to understand when the requested email has been sent.

As previously discussed, a subscriber <NUM> to a topic <NUM>, without any additional systems, is traditionally unable to tell the content of a message <NUM> on a topic <NUM>. In this respect, <FIG> depicts each instance of process A as pulling all response messages 164f-j from the storage location for the second topic 166b. Here, for the first instance of process A to determine that the email has been generated with the visual financial report (i.e., the first message 164a), the first instance of process A receives all the response messages 164f-j and determines that the response message <NUM> provides confirmation that the email has been generated with the visual financial report. To perform this determination, the first instance of process A receives and then discards or disregards the other response messages 164f,h,-j pulled from the second topic 166b. In this example, egress occurs because only a single message <NUM> was needed for confirmation, but the first subscriber 168f had to pull five messages <NUM> in order to identify the actual message <NUM> of interest (i.e., message <NUM>).

In contrast, <FIG> depicts how the event service <NUM> avoids the issue of data egress. <FIG> is similar to <FIG> except that the response messages 164f-j are filtered (e.g., shown as a filter layer). That is, the subscriber <NUM> of the second topic 166b for each instance of process A that is awaiting the response message <NUM> from process B that its respective action has been performed does not have to pull all of the response messages 164f-j. Rather, the response messages 164f-j are filtered based on a unique message identifier UMI that is included in each original request message 164a-e published by process A. By filtering the response messages 164f-j, each subscriber 168f-j associated with an instance of process A receives messages <NUM> that are pertinent to that particular instance of process A. In this example, with only one response message <NUM> being pertinent to each instance of process A, each subscriber <NUM> of process A receives a single response message <NUM> (e.g., that indicates the action of the request message <NUM> has been completed by process B).

With continued reference to <FIG>, the event servicer <NUM> is configured to instantiate a process <NUM> and to setup the publisher <NUM>/subscriber <NUM> relationships to perform a particular action. To setup the publisher <NUM>/subscriber <NUM> relationships, the event servicer <NUM> is able to identify the topics <NUM> of interest that will be involved for a particular process <NUM>. For example, <FIG> depicts a first process 170a and a second process 170b. The first process 170a is shown as a publisher <NUM> that generates a request message <NUM>, 164R on the first topic 166a while the second process 170b is a subscriber <NUM> of the first topic 166a and receives the request message 164R. The second process 170b then functions as a publisher <NUM> for the second topic 166b by generating a response message <NUM>, 164r in response to the request message 164R. The first process 170a is a subscriber of the second topic 166b to receive the response message 164r that informs the first process 170a of the action associated with the request message 164R.

Referring to <FIG>, in order to setup these publisher/subscriber relationships for a process <NUM>, the event servicer <NUM> performs different operations depending on whether the event service <NUM> is instantiating a process <NUM> or implementing the process <NUM> during runtime. In this respect, the event servicer <NUM> includes an initiator <NUM> and a runtime generator <NUM>. The initiator <NUM> performs operations that occur during instantiation for a process <NUM> that will publish a request message 164R (e.g., that requests some action be performed by the responding process 170b). In this respect, the initiator <NUM> instantiates a requesting process <NUM>. When the initiator <NUM> instantiates the requesting process <NUM>, the initiator <NUM> identifies a topic <NUM> of the messaging system <NUM> that will receive a response message 164r from another process 170b that will respond to the request message 164R of the requesting process 170A. Here, this other process 170b is referred to as a responding process <NUM> since it responds to the request message 164R. The topic <NUM> identified by the initiator <NUM> is referred to as a response topic <NUM>, 166r because it is the topic <NUM> to where the responding process 170b will communicate its response message 164r. In other words, since the request message 164R requests that the responding process 170b performs a particular action, the response topic 166r is a topic <NUM> to which the responding process 170b will publish a response message 164r that indicates the status of the action (e.g., that the action has been completed, failed, or is in some intermediate state). In some examples, the initiator <NUM> identifies the response topic 166r by identifying the responding process 170b that will perform the action of the request message 164R and then determining the topics <NUM> that this particular responding process 170b will publish to as a publisher <NUM>.

Once the initiator <NUM> identifies the response topic 166r during instantiation of the requesting process 170a, the initiator <NUM> generates N number of subscriptions <NUM>, 212a-n (also referred to as a plurality of subscriptions <NUM>) to the identified response topic 166r for this particular instance of the requesting process 170a. Each subscription <NUM> generated by the initiator <NUM> for a particular instance of the requesting process 170a includes a subscription identifier <NUM> (shown as SID). In some examples, the subscription identifier <NUM> refers to a unique identifier that identifies a single subscription <NUM> from among the multiple subscriptions <NUM>. In other words, one subscription <NUM> may not share or have a common subscription identifier <NUM> (e.g., in a particular instance of the requesting process 170a) with another subscription <NUM>.

In some implementations, the initiator <NUM> generates each subscription <NUM> with a filter that waits on a filter value <NUM> (shown as Fv). Here, the filter value <NUM> may also be unique in that no other subscription <NUM> has the same filter value <NUM> as another subscription <NUM>. The filter value <NUM> may be related to the subscription identifier <NUM> or completely separate from the subscription identifier <NUM>. For instance, in <FIG>, each subscription 212a-n is shown with a subscription identifier <NUM> and a filter value <NUM>. Furthermore, one or both of the subscription identifier <NUM> and the filter value <NUM> for a particular subscription <NUM> is also unique among all subscriptions <NUM> of all instances for the requesting process 170a. This means that the subscription identifier <NUM> and/or the filter value <NUM> are not shared with any other instances of the requesting process 170a so that, for example, one or the combination of the subscription identifier <NUM> and the filter value <NUM> are unique to a particular instance of the requesting process 170a. By having these elements be unique, messages <NUM> subscribed to by the requesting process 170a may be filtered to ensure that the messages <NUM>, received by a subscriber <NUM> of a particular instance of the requesting process 170a, are intended for that particular instance of the requesting process 170a. In other words, the subscription identifier <NUM> and/or the filter value <NUM> enable the event servicer <NUM> to prevent data egress during runtime of the requesting process 170a.

In some configurations, the subscription identifier <NUM> and/or the filter value <NUM> corresponding to each subscription <NUM> are stored in a storage element such as a hashmap. For instance, when the storage element is a hashmap, the hashmap includes entries with a key-value pair where the key is the filter and the value is the subscription <NUM>. Here, the filter that corresponds to the key may be the subscription identifier <NUM>, the filter value <NUM>, and/or some combination of both. The size of the storage element (e.g., the hashmap) may correspond to the number of simultaneous requests that an instance of the requesting process 170a can handle. This is because the servicer <NUM> may filter the messages <NUM> received at the response topic 166r by the filter value <NUM> and/or subscription identifier <NUM>. When this is the case and these elements <NUM>, <NUM> are unique to a single subscription <NUM>, the servicer <NUM> can only completely prevent data egress if the filter values being used are not shared.

Referring to <FIG>, the initiator <NUM> illustrates the fact that the requesting process 170a may be instantiated countless times (e.g., shown as instance <NUM>-i) where each instance of the requesting process 170a includes a set <NUM>, <NUM>, of subscriptions <NUM>, 212a-n. For instance, the first instance includes a first set <NUM>, <NUM>s1 of subscriptions 212a-n. The second instance includes a second set <NUM>, <NUM>s2 of subscriptions 212a-n. The ith instance includes an ith set <NUM>, <NUM>si of subscriptions 212a-n. With multiple instances, each instance may have its own storage element for the subscription identifiers <NUM> and/or the filter values <NUM> corresponding to the respective instance's set <NUM> of subscriptions <NUM>. Alternatively, the servicer <NUM> may include a global storage element that stores all of the subscription identifiers <NUM> and/or the filter values <NUM> corresponding to all sets <NUM> of subscriptions <NUM> (i.e., for all instances).

Referring to <FIG> and <FIG>, after the initiator <NUM> performs instantiation for the requesting process 170a, the runtime generator <NUM> of the event servicer <NUM> manages how the subscriptions <NUM> are used during runtime for the requesting process 170a. During runtime for the requesting process 170a, the runtime generator <NUM> is configured to publish a request message 164R to a request topic 166R that is subscribed to by the responding process 170b. In some examples, the request message 164R corresponds to an action that a client <NUM> requests that the action hub <NUM> performs by generating a request <NUM>. When the action hub <NUM> receives the request <NUM>, the action hub <NUM> may provide the request <NUM> to the event servicer <NUM> to enable the event servicer <NUM> to identify one or more actions (e.g., event-based actions) that will fulfill the request <NUM>. For each action identified by the event servicer <NUM>, the event servicer <NUM> may generate a request message 164R that requests that a process <NUM> capable of performing the action associated with the request message 164R performs the action. Here, to request that a process <NUM> (e.g., referred to as the responding process 170b) performs the action, the requesting process 170a publishes the request message 164R to a request topic 166R that the responding process 170b subscribes to as a subscriber 168a. As a subscriber 168a, an instance of the responding process 170b receives the request message 164R and performs the action identified by or associated with the request message 164R. The responding process 170b informs the requesting process 170a that the action been completed (or some status related to the action) by, in return, publishing a response message 164r as a publisher 162b to a response topic 166r.

Since the event servicer <NUM> intends to prevent or to reduce data egress (e.g., with respect to subscription calls), the runtime generator 170a is configured to generate a subscriber 168b for the requesting process 170a that receives a response message 164r after the runtime generator 170a ensures that the response message 164r is truly intended for the particular instance of the requesting process 170a. To generate a subscriber 168b that receives only the response messages 164r intended for the particular instance of the requesting process 170a, the runtime generator <NUM> generates the subscriber 162b using a subscription identifier <NUM> and/or the filter value <NUM> of a respective subscription <NUM> that was instantiated by the initiator <NUM>. In some examples, the runtime generator <NUM> selects (e.g., randomly selects) a subscription <NUM> from the set <NUM> of subscriptions <NUM> for the particular instance of the requesting process 170a and generates the subscriber 162b for the instance of the requesting process 170a with the subscription identifier <NUM> (and/or the filter value <NUM>) from the selected subscription <NUM>. For instance, <FIG> illustrates the runtime generator <NUM> selecting a second subscription 212b from the first instance of the requesting process 170a that the initiator <NUM> previously instantiated. With this approach, instead of generating a subscription <NUM> during runtime where the subscription <NUM> would potentially have a unique identifier for filter purposes that is specific to the request message 164R and its associated action, subscribers <NUM> for the requesting process 170a are generated during runtime and these subscribers <NUM> are generated using identifiers (e.g., the subscription identifier <NUM> and/or the filter value <NUM>) that are agnostic to the specific request message 164R and the specific action of the request message 164R. Moreover, when the specific action of the request message <NUM> is complete and the subscriber's purpose (determining that the specific action has occurred) is done, the cloud computing environment <NUM> does not include an entire obsolete instance of a process <NUM>, but rather only an obsolete subscriber 168b. The instance of the requesting process 170a that generated the obsolete subscriber 168b may continue to exist and to handle other requests by either reusing the identifier(s) <NUM>, <NUM> of the obsolete subscriber 168b or by generating subscribers <NUM> based on other subscriptions <NUM> that the initiator <NUM> instantiated for that instance of the requesting process 170a.

In some configurations, the runtime generator <NUM> associates a unique message identifier UMI with the request message 164R. For example, the runtime generator <NUM>, when it generates the request message 164R (e.g., from the request <NUM>), also creates the unique message identifier UMI that will be included with the request message 164R. In some examples, in addition to associating the UMI with the request message 164R, the runtime generator <NUM> also associates or adds the UMI to the subscriber <NUM> that the runtime generator <NUM> generates to receive the response message 164r. When the subscriber 168b also includes the UMI, the runtime generator <NUM> has another way to ensure that the desired response (i.e., the response message 164r) from the responding process 170b is delivered by the underlying message infrastructure associated with initial request <NUM>. In some ways, the inclusion of the UMI functions as a fail safe. That is, the subscriber 168b is already configured to filter out any messages on the response topic 166r using one or both of the subscription identifier <NUM> or the filter value <NUM>. In this respect, the subscriber 168b should not receive response messages 164r that do not relate to the specific action requested by the particular instance of the requesting process 170a in the request message 164R. Yet as a fail safe, the runtime generator <NUM> may be configured to include the UMI to confirm that the UMI associated with the response message 164r received at the subscriber 168b is the UMI created based on the request <NUM> for the request message 164R. Therefore, the inclusion of the UMI enables the runtime generator <NUM> to generate an acknowledgement message to confirm the response message 164r (e.g., the response message 164r after being filtered) includes the UMI.

In some implementations, the requesting process 170a refers to an edge server. Here, the edge server is responsible for listening to incoming request (e.g., requests <NUM>). The edge server therefore publishes request messages 164R based on a request <NUM> for a responding process 170b, such as a particular instance of an action container. In this scenario both the requesting process 170a and the responding process 170b may be stateless and single threaded processes of the remote system <NUM>. Both of these processes <NUM> may scale by being replicated as multiple instances such that each instance may operate simultaneously. This means that a first request <NUM> may cause a first instance of the requesting process 170a to be requesting actions from a third instance of the responding process 170b while a second request <NUM> causes a sixth instance of the requesting process 170a to be requesting actions from a first instance of the responding process 170b.

<FIG> is a flowchart of an example arrangement of operations for a method <NUM> of implementing an event-based distributed messaging system. Operations <NUM> and <NUM> occur when the method <NUM> instantiates a requesting process 170a that publishes a request <NUM>, 164R for a response <NUM>, 164r from a responding process 170b. At operation <NUM>, the method <NUM> identifies a response topic <NUM>, 166r of a distributed messaging service <NUM> that receives the response <NUM>, 164r for the request <NUM>, 164R from the responding process 170b. The responding process 170b is configured as a publisher <NUM> for the response topic <NUM>, 166r. At operation <NUM>, the method <NUM> generates a plurality of subscriptions <NUM>, 212a-n for the response topic 166r where each subscription <NUM> includes a subscription identifier <NUM>. Operations <NUM>-<NUM> occur during runtime for the requesting process 170a. At operation <NUM>, the method <NUM> publishes a request message <NUM>, 164R to a request topic <NUM>, 166R subscribed to by the responding process 170b. The request message <NUM>, 164R includes a unique message identifier UMI. At operation <NUM>, the method <NUM> generates a subscriber <NUM> using a respective subscription identifier <NUM> of a respective subscription <NUM> selected from the plurality of subscriptions <NUM>, 212a-n. The subscriber <NUM> includes the unique message identifier UMI. At operation <NUM>, the method <NUM> receives, at the subscriber <NUM>, a filtered response message <NUM>, 164r from the responding process 170b in response to the request message <NUM>, 164R published to the response topic <NUM>, 166R. Here, the filtered response message <NUM>, 164r is filtered based on one or more subscription identifiers <NUM> associated with the plurality of subscriptions <NUM>, 212a-n for the requesting process 170a.

The computing device <NUM> includes a processor <NUM> (e.g., data processing hardware), memory <NUM> (e.g., memory hardware), a storage device <NUM>, a high-speed interface/controller <NUM> connecting to the memory <NUM> and high-speed expansion ports <NUM>, and a low speed interface/controller <NUM> connecting to a low speed bus <NUM> and a storage device <NUM>.

For example, it may be implemented as a standard server 400a or multiple times in a group of such servers 400a, as a laptop computer 400b, or as part of a rack server system 400c.

Claim 1:
A computer-implemented method (<NUM>) when executed by data processing hardware (<NUM>) causes the data processing hardware (<NUM>) to perform operations comprising:
when instantiating a requesting process (170a) that publishes a request (<NUM>, 164R) for a response (<NUM>, 164r) from a responding process (170b):
identifying a response topic (<NUM>, 166r) of a distributed messaging service (<NUM>) that receives the response (<NUM>, 164r) for the request (<NUM>, 164R) from the responding process (170b), the responding process (170b) configured as a publisher (<NUM>) for the response topic (<NUM>, 166r); and
generating a plurality of subscriptions (<NUM>, 212a-n) for the response topic (<NUM>, 166r), each subscription (<NUM>) comprising a subscription identifier (<NUM>); and
during runtime for the requesting process (170a):
publishing a request message (<NUM>, 164R) to a request topic (<NUM>, 166R) subscribed to by the responding process (170b), the request message (<NUM>, 164R) comprising a unique message identifier (UMI);
generating a subscriber (<NUM>) using a respective subscription identifier (<NUM>) of a respective subscription (<NUM>) selected from the plurality of subscriptions (<NUM>, 212a-n), the subscriber (<NUM>) comprising the unique message identifier, UMI,; and
receiving, at the subscriber (<NUM>), a filtered response message (<NUM>, 164r) from the responding process (170b) in response to the request message (<NUM>, 164R) published to the response topic (<NUM>, 166r), the filtered response message (<NUM>, 164r) filtered based on one or more subscription identifiers (<NUM>) associated with the plurality of subscriptions (<NUM>, 212a-n) for the requesting process (170a).