Asynchronous Event-Based Distributed Messaging Service

Abstract

A method for implementing an event-based distributed messaging service includes identifying a response topic (166, 166r) of the distributed messaging service (160) when instantiating a request process (170a) that issues a request (164, 164R) for a response (164, 164r) from a response process (170b), and generating subscriptions (212) for the response topic, each subscription including a subscription identifier (214). During runtime for the request process, the method publishes a request message (164, 164R) to the request topic (166, 166R) subscribed to by the response process, the request message including a unique message identifier (UMI), and generates a subscriber (168) using the respective subscription identifier of each subscription selected from the subscriptions, the subscriber including the unique message identifier.

Description

Technical Field

[0001] Technical Field The present disclosure relates to an asynchronous event-based distributed messaging service.

Background Art

[0002] Background Distributed systems, such as cloud computing environments, have come to be widely used to provide numerous software services. As these software services grow and enterprises integrate multiple services into workflows, coordination between these services can become increasingly important. That is, for clients to rely on compatibility between services, robust communication between the processes of these services is required. Further, clients prefer robust coordination between processes to operate in a cost-effective manner from both computing and financial costs. This translates to the fact that when a messaging system coordinates the operation between processes, it is necessary to avoid operations that cause wasted waiting time in the communication between these processes.

Summary of the Invention

[0003] Summary One aspect of the present disclosure provides a method executed by a computer implementing an event-based distributed messaging service. The method executed by the computer, when executed by data processing hardware, causes the data processing hardware to perform operations. When instantiating a request process that issues a request for a response from a response process, the operations include identifying a response topic of a distributed messaging service that receives a response for the request from the response process, where the response process is configured as a publisher for the response topic. Also, when instantiating a request process that issues a request for a response from a response process, the operations include generating a plurality of subscriptions for the response topic, each subscription including a subscription identifier. During runtime for the request process, the operations further include issuing a request message to a request topic subscribed to by the response process, the request message including a unique message identifier and further including the step of generating subscribers using the respective subscription identifiers of each of the plurality of subscriptions selected from the plurality of subscriptions, the subscribers including the unique message identifier. Further, during runtime for the request process, the operations also include receiving, at the subscribers, filtered response messages from the response process in response to the request message issued to the response topic. Here, the filtered response messages are filtered based on one or more subscription identifiers associated with the plurality of subscriptions for the request process. [[ID=!]]

[0004] Other aspects of the present disclosure provide a system for implementing an event-based distributed messaging service. The system includes data processing hardware and memory hardware that communicates 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 request process that issues a request for a response from a response process, the operations include identifying a response topic of the distributed messaging service for receiving a response to the request from the response process, where the response process is configured as a publisher for the response topic. Also, when instantiating a request process that issues a request for a response from a response process, the operations include generating a plurality of subscriptions for the response topic, each subscription including a subscription identifier. During runtime for the request process, the operations further include issuing a request message to a request topic subscribed to by the response process, the request message including a unique message identifier. The operations further include generating a subscriber using each subscription identifier of each subscription selected from the plurality of subscriptions, the subscriber including a unique message identifier. Further, during runtime for the request process, the operations also include receiving, at the subscriber, a response message filtered from the response process in response to the request message issued to the response topic, where the filtered response message is filtered based on one or more subscription identifiers associated with the plurality of subscriptions for the request process.

[0005] Embodiments of the method or system executed by a computer of the present disclosure can include one or more of the following optional features. In some embodiments, the operation also includes randomly selecting each subscription from a plurality of subscriptions during runtime for a request process. In some examples, the operation during runtime for a request process further includes generating a request message for a request topic. The subscription identifier may be unique among multiple instances of the request process. The subscription identifier can include a unique filter value, and the response message to be filtered is filtered based on the unique filter value of each subscription used to generate the subscriber. In some examples, each subscriber for each topic of the distributed message system functions as a multicast subscription that searches all messages communicated on each topic.

[0006] In some configurations, when instantiating a request process that issues a request for a response from a response process, the operation also includes storing each subscription identifier of a plurality of subscriptions for a response topic in a hash map. In these configurations, during runtime for the request process, the operation includes randomly selecting each subscription identifier from the hash map that stores each subscription identifier of a plurality of subscriptions for a response topic.

[0007] In some embodiments, during runtime for the request process, the operation also includes the step of filtering one or more messages by the publisher of the request topic. Here, the filtering is performed by determining whether one or more messages by the publisher of the request topic include a unique message identifier. If each of the one or more messages by the publisher of the request topic does not include a unique message identifier, the operation includes the step of preventing each message from being received by the subscriber. In these embodiments, the one or more messages by the publisher of the request topic include filtered response messages. If the filtered response message includes a unique message identifier, the operation during runtime for the request process further includes the step of generating an acknowledgement response message.

[0008] Optionally, in response to receiving a first request to perform a computing task, the request process may be instantiated. If the request process is instantiated in response to receiving a first request to perform a computing task, the operation during runtime for the request process further includes the step of generating a first response to the first request to perform a computing task when receiving a filtered response message from the response process in response to a request message issued to the request topic.

[0009] Details of one or more embodiments of the present disclosure are set forth in the accompanying drawings and the following description. Other aspects, features, and advantages will be apparent from the description and drawings, as well as from the claims.

Brief Description of the Drawings

[0010]

Figure 1A

Figure 1B

Figure 1C

Figure 2A

Figure 2B

Figure 2C

Figure 3

Figure 4

DETAILED DESCRIPTION OF THE INVENTION

[0011] Like reference numerals in the various drawings indicate like elements. DETAILED DESCRIPTION As more companies and individuals use distributed computing systems (i.e., cloud-based computing systems), these distributed computing systems may use certain client-side mechanisms to perform tasks in various processes related to one or more services provided by the distributed system. For example, a client (i.e., a company and / or individual user) can use an analysis platform (i.e., a data analysis service) to perform data analysis on client data. An action hub that functions as a type of client-side mechanism is part of the analysis platform and can enable the client to perform actions on the data being analyzed by the analysis platform. Here, by having a client-side mechanism such as an action hub integrated with the analysis platform (e.g., a data analysis system, etc.), the client no longer needs to use one system to adjust tasks and another separate system to perform data analysis.

[0012] Furthermore, it is common for a client to integrate components of one software service with the functionality of another software service. Continuing with the example of the analytics platform, a client of the action hub in the analytics platform may want to send an email to the client's users. In this example, the client can use the analytics platform to generate a visual financial report for the client based on the client's data, and the client may want to communicate that visual financial report to multiple users of the client (such as employees of the company that is the client). To create an email of this visual financial report, the client schedules an action using the action hub, and the action is to communicate the financial report as an email to the intended recipients. The action hub generates a request to retrieve the visual financial report, and when the financial report is retrieved, the action hub executes the triggered action to send the financial report to the intended recipients. Here, the action of sending the visual financial report is triggered by an event that receives the visual financial report in response to the retrieval request, so the sending action is a triggered action or an event-based action. That is, an event-based action refers to an action that occurs in response to a specific event or series of events.

[0013] One of the problems that occur in client-side mechanisms such as action hubs is that the tasks coordinated through the action hub can become important or critical workloads for the client. In other words, the client may be an enterprise that operates depending on actions coordinated from the action hub. For example, a financial client or the client's team may depend on financial data management or financial data storage combined with data analysis in its financial data. For example, the client's financial team depends on emails containing visual financial reports to evaluate financial investments. If there is some kind of disruption to the action hub due to the workload across all clients or some other reason, this disruption may damage the relationship with the client, and the client may end up controlling or hosting its own version of the action hub as a fail-safe.

[0014] Disruptions can occur for various reasons, but one of the problems that can lead to disruptions is the way events are coordinated to perform a specific task. To coordinate a specific series of events that enable a task to occur, client-side mechanisms such as action hubs use a distributed messaging system. A distributed messaging system enables messages regarding a specific topic to be issued and enables subscribers to that topic to receive messages issued regarding that topic. A topic generally refers to a named resource that is configured by the distributed messaging system for the relationship between publication and subscription. In this sense, client-side mechanisms such as action hubs operate in conjunction with the distributed messaging system to request the execution of a specific action and communicate when that specific action has been executed.

[0015] In terms of explaining in an email a visual financial report, the action hub uses a distributed messaging system to generate a request message for the search of visual financial reports in the topic of searching for visual financial reports. Subscribers to that topic may be applications or services that can generate or search for visual financial reports. The subscriber can then function as a publisher to generate a message containing the visual financial report and issue that message to the topic of the searched visual financial report. Next, the action hub can use the distributed messaging system to generate a request message for sending the report as an email to the topic regarding the generation of the email. Subscribers to the topic regarding the generation of the email receive the request message with the visual financial report and can use an email service or email application to send the visual financial report to the intended recipient. When the action of sending the email is executed, the subscriber operates as a publisher and issues a response message to the topic of the communicated email indicating that the email with the report has been sent. Subscribers to the topic of the communicated email receive the response message. At this stage, the action hub can indicate that the action of sending the visual financial report to the designated recipient by email is complete and that no further action can be taken regarding that task.

[0016] This messaging sequence may appear to be successful with respect to the client's actions, but problems may arise in scaling this process. For example, in a publisher-subscriber messaging system, a subscriber generally not only receives relevant messages related to the client's actions, but rather the subscriber is configured to subscribe to a topic and receive all messages in that particular topic. In a publisher-subscriber system, a distributed messaging system can push messages to a subscriber when a message is received on a particular topic that the subscriber has subscribed to, or the subscriber can alternatively pull (i.e., retrieve) messages from the topic that the subscriber has subscribed to. Unfortunately, in either scenario, the subscriber receives messages regarding the topic, but often cannot understand the context of the messages before receiving them (other than the general context that the message is related to the topic). In a large-scale system where multiple publishers (e.g., thousands of publishers) generate various messages related to countless actions, it becomes cumbersome for the subscriber to identify a particular message, and a large amount of data outflow occurs. For example, in the case of report emails, the last subscriber to the topic of the communicated email is waiting for the publisher associated with the action container to indicate that an email containing a visual financial report has been sent. However, the topic of the communicated email may receive thousands of messages related to the email communication, and the last subscriber remains trying to identify whether any of these thousands of messages is particularly relevant to the email with the visual financial report.

[0017] One approach to identifying whether any of these thousands of messages are related to an email of a visual financial report is to pull all the messages received by the last subscriber regarding that topic and sift through 1,000 messages until the last subscriber identifies one message of interest. This process results in a large amount of data outflow. This is because in a distributed messaging system, in the case of 1,000 messages, the system needs to send 999 additional messages to the subscriber. This incurs additional computing costs and may trigger incorrect events during the process. Also, for the company itself, since cloud service providers generally bill clients for data outflow charges, this process is costly for each party.

[0018] Expanding this example further, there may be multiple subscribers regarding a topic, and each subscriber may be trying to identify a message to confirm the completion of an action. Therefore, instead of one subscriber having 999 additional messages, the outflow increases across all subscribers. That is, if there are 100 subscribers, since each of the 100 subscribers is interested in one message, these 100 subscribers will receive a total of 99,900 additional messages. Furthermore, distributed computing infrastructure providers generally have rate limits that limit the rate of requests for a particular call. That is, a cloud provider may have a rate limit of 200 requests per second per call, and thus, the subscriber will have to wait 5 seconds in response to the call to generate 1,000 requests for 1,000 messages regarding the topic. In the case of rate limits, clients may be forced to experience high latency, especially for actions involving multiple events (such as multiple subscription calls).

[0019] One approach to solving these outflow problems is to generate a filter or a unique request identifier each time a specific action request occurs. This means that a request to generate an email of a visual financial report creates an instance using a unique request identifier for that specific action. This instance generates a subscription to the topic necessary for the action to be executed, and that subscription includes the unique request identifier as a means of filtering response messages to prevent a large amount of outflow. This approach can reduce outflow, but it also generates unique instances that the system cannot use for other tasks. In other words, using a unique request identifier makes the instance completely unique to the request and its structure cannot be reused for other requests. Unfortunately, the client's finance team may generate an email of a visual financial report every week. This is because the report may be dynamic, and the instance generated by the system using the unique request identifier for one week cannot be used again the next week. In other words, this unique request identifier approach may result in frequent instantiation by the system.

[0020] To address these egress issues while also considering instantiation, the approach described here modifies the process instantiation method such that filters are included in the process instantiation, but the filters are not specific to a particular action request. Rather, during the instantiation of a process, the system generates N subscriptions to topics for the process, where each subscription contains a unique value (e.g., a unique filter value). Instead of associating these unique values with a particular request during creation (i.e., process instantiation) to generate a targeted subscription, the system generates subscribers based on these subscriptions when an action request is received. That is, during runtime after the instantiation of the process with N subscriptions, the system receives a process request and creates a subscriber that uses the unique value associated with a particular previously instantiated subscription. In this sense, the unique value functions as a filter for a particular request, but the creation of this filter does not limit the subscription to that particular request. This means that in the case of the first request, the system may create a subscriber based on the instantiated subscriptions using the unique values of the instantiated subscriptions, but when a second request occurs in the future, another subscriber may be generated that uses the same unique values of the subscriptions instantiated with respect to that filter. Thus, when the first request is completed, the subscriber unique to the first request may be discarded, but the values that function as its filter values may be used for subsequent requests on the process. Further, by instantiating N subscriptions, the process can be scaled to handle N simultaneous requests. For example, each simultaneous request can form a subscriber using one of the unique values of the N subscriptions.

[0021] FIG. 1A is an example of a cloud computing environment 100. The environment 100 includes one or more clients 10 that communicate with a remote system 130 via a network 120. The clients 10 communicate with the remote system 130 to access and execute on various computing platforms. In other words, a remote system 130, such as a cloud computing environment, can provide software (SaaS) platforms as various services where the customers of the cloud environment 130 are the clients 10. In this regard, the clients 10 can range from a business or enterprise to an individual user of the cloud environment 130.

[0022] The client 10 can generally refer to any user of the remote system 130. The client 10 communicates with the remote system 130 using a client device 110 that can correspond to any computing device associated with the client 10. Some examples of the client device 110 include, but are not limited to, mobile devices (e.g., mobile phones, tablets, laptops, e - book readers, etc.), computers, wearable devices (e.g., smartwatches), music players, cast devices, smart home appliances (e.g., smart TVs) and Internet of Things (IoT) devices, remote controls, smart speakers, etc. The remote system 130 can include remote resources such as remote data - processing hardware 132 (e.g., a remote server or CPU) and / or remote memory hardware 134 (e.g., a remote database or other storage hardware). The client device 110 can utilize the remote resources to perform various functions related to the processes of the services of the remote system 130. These processes can be hosted by the remote system 130 or integrated with the local resources of the client device 110.

[0023] Client 10 interacts with action system 140 (also referred to as action hub 140, for example) (e.g., via client device 110) to cause action hub 140 to execute a specific action submitted as action request 150 by client 10. Here, an action can refer to any computing task that utilizes some of the functions of various services associated with remote system 130. In many cases, client 110 can generate action request 150 such that it has client data to be processed or analyzed by a specific service of remote system 130 that is integrated or used by another service. For example, client 110 requests an action 150 to send an email containing a financial report regarding client data generated by an analysis service of remote system 130 using an email service.

[0024] When the action associated with action request 150 is completed or about to be completed, action hub 140 can generate a response 180 to notify client 10 (e.g., client device 110) of the status of the action from action request 150. If response 180 indicates that the action has been completed (e.g., response message 164 indicates that process 170 has executed the action), action hub 140 can communicate the actual message or some other form of communication to client 10 to indicate the completion of the action. In some examples, action hub 140 displays the completion of the action as the status regarding the action in the client-side interface. In some configurations, request 150 and / or response 180 are messages that use Hypertext Transfer Protocol Secure (HTTPS) or Hypertext Transfer Protocol (HTTP).

[0025] As shown in FIG. 1A, the action hub 140 can be associated with or include a messaging system 160 and an event service 200. The action hub 140 is shown as a dotted box around the messaging system 160 and the event service 200. This is because these components may be part of the action hub 140 itself, may be separate from the action hub 140, or may communicate with the action hub 140. Here, the messaging system 160 may refer to a distributed messaging system that operates by coordinating asynchronous events. Here, asynchronous refers to the fact that events do not need to occur simultaneously. Generally, the same applies to asynchronous messaging. Messages can be exchanged, for example, between two processes (e.g., a first process 170, 170a and a second process 170, 170b) without the need for an ongoing conversation (i.e., direct contact) between the processes 170.

[0026] Request 150 is to send an email with a visual financial report. If the visual financial report has already been obtained, the event to satisfy the request is to communicate the request to some service that can send the email and request a response indicating that the action has been completed. Here, a service that can execute an action is generally called an action container. The action container refers to an instance of a process 170 that can execute the specified action. In a distributed system, the action container may be included (i.e., separated) in the distributed system so that the actions executed in the action container do not unduly affect other services or workloads in the distributed system. Therefore, the use of action containers is often preferred. In this sense, the action container can include instances of a specific service or application so that the remote system 130 can adjust the number of instances to adapt to the current or expected workload on the resources of the remote system 130.

[0027] When using an action container to execute some or all of a particular action, the action hub 140 generally cannot know whether the requested action 150 has been executed unless there is some feedback that the action has been processed. That is, the process 170 within the action container can execute the specified action, but the action hub 140 does not recognize the performance of the process without further information. In this regard, the process 170 also utilizes the messaging system 160 to communicate that the action has been completed.

[0028] In some examples, to function asynchronously, the messaging system 160 operates in a publisher-subscriber configuration. The publisher-subscriber configuration is such that a particular process 170 functions as a publisher 162 that issues messages 164 regarding a particular topic 166, while a subscriber 168 of that topic 166 has a subscription to the topic 166 that causes the subscriber 168 to be notified when a message 164 is generated regarding the topic 166. For example, the messaging system 160 configures topics 166, where each topic 166 includes storage space in which messages 164 are stored regarding that particular topic 166. When a subscriber 168 receives an indication that there is a message 164 for a topic 166 to which the subscriber 168 is subscribed, the subscriber 168 can retrieve (e.g., pull) the message 164 from the corresponding storage location. In some embodiments, the messaging system 160 is configured to push messages 164 regarding one or more topics 166 to subscribers 168 of those topics 166, such that when a message 164 regarding a topic 166 is received, the messaging system 160 communicates that message 164 to all subscribers 168 having a subscription to that topic 166. The publisher-subscriber relationship can be one-to-many, meaning that one publisher 162 issues messages 164 regarding a topic 166 to which multiple subscribers 168 are subscribed, many-to-one, meaning that multiple publishers 162 issue messages 164 regarding a topic 166 to one subscriber 168, or a variation thereof. Further, in this form of distributed messaging, the number of publishers 162 and / or subscribers 168 regarding a given topic 166 can vary dynamically based on the messaging needs of the distributed system. What this means is that the remote system 130 can instantiate multiple instances of the action container of the process 170 that generates the electronic mail.

[0029] In the publisher-subscriber model, the instantiated process 170 can be the publisher 162, the subscriber 168, or both. For example, the process 170 can be the publisher 162 for the first topics 166, 166a and the subscriber 168 for the second topics 166, 166b. This means that the process 170 can generate one or more messages 164 regarding the first topic 166a and listen for / receive one or more messages 164 regarding the second topic 166b. By way of illustration, the process 170 included in an instance of the application container can be the subscriber 168 in the first topic 166a that notifies the process 170 about the actions that the process 170 is required to perform, and can also be the publisher 162 in the second topic 166b that functions as a topic indicating that the requested action has been executed. In the example of an email, the process 170 is an email application that can generate an email attaching a visual financial report. The email application functions as the subscriber 168 for the first topic 166a regarding the email request and as the publisher 162 for the second topic 166b regarding the communicated email.

[0030] The event service 200 is a system configured to prevent a large amount of data from flowing out when using the remote system 130 to execute actions. FIG. 1B shows how data outflow occurs when using the publisher-subscriber messaging system 160. In this figure, both process A and process B are instantiated 5 times. Each instance of process A is configured as a publisher 162, 162a - e for the first topic 166a and a subscriber 168, 168f - j for the second topic 166b. The topic 166 changes based on the actions involved, but to maintain the current example, the first topic 166a is the topic 166 related to the email request, and the second topic 166b is related to the communicated email. Additionally, each instance of process B is configured as a subscriber 168a - e for the first topic 166a and a publisher 162a - e for the second topic 166b. Each instance of process A generates message requests 164, 164a - e as a publisher 162 that requests a specific action to be performed by process B. Here, each message request 164 is unique to a specific instance of process A. For example, process B may be an email application, and each message request 164 requests process B to generate an email with different parameters (e.g., content, recipient, attachment, etc.). Each message 164 is shown to be unique by different filling patterns within the circular element designated as the message request 164. In this example, the gray-filled message requests 164, 164a (or the first message request 164a) from the first instance of process A are requests to generate an email with a visual financial report for process B. Each instance of process B receives the message request 164 for the first topic 166a as a subscriber 168. When an instance of process B receives the message request 164, the instance executes each action requested by the message 164.When each instance of Process B communicates a parameterized email in response to a request, each instance of Process B issues response messages 164f - j as the issuer 162f - j regarding the second topic 166b (i.e., regarding the sending of each respective email). Each instance of Process A also subscribes as a subscriber 168f - j to the second topic 166b regarding the email communication so as to be able to understand when the requested email was sent.

[0031] As described above, without any additional system, it is traditionally impossible for the subscriber 168 of topic 166 to convey the content of the message 164 regarding topic 166. In this regard, Figure 1B shows each instance of Process A pulling all the response messages 164f - j from the storage location for the second topic 166b. Here, for the first instance of Process A to determine that an email was generated along with a visual financial report (i.e., the first message 164a), the first instance of Process A receives all the response messages 164f - j and decides that the response message 164g gives confirmation that the email was generated along with a visual financial report. To execute this decision, after receiving the other response messages 164f, h, - j pulled from the second topic 166b, the first instance of Process A discards or ignores them. In this example, since only a single message 164 was needed for confirmation, there is an outflow, but the first subscriber 168f needed to pull 5 messages 164 to identify the actual message 164 of interest (i.e., message 164g).

[0032] In contrast, FIG. 1C shows how the event service 200 avoids the problem of data leakage. FIG. 1C is similar to FIG. 1B, except that the response messages 164f - j are filtered (e.g., shown as a filter layer). That is, each subscriber 168 of the second topic 166b in each instance of process A waiting for the response message 164 from process B indicating that each action has been executed does not need to pull all of the response messages 164f - j. Rather, the response messages 164f - j are filtered based on the unique message identifier UMI included in each original request message 164a - e issued by process A. By filtering the response messages 164f - j, each subscriber 168f - j associated with an instance of process A receives the message 164 related to that specific instance of process A. In this example, since there is only one response message 164 related to each instance of process A, each subscriber 168 of process A receives a single response message 168 (e.g., this indicates that the action of the request message 164 has been completed by process B).

[0033] Continuing to refer to FIG. 1A, the event service 200 is configured to instantiate process 170 and set up the relationship of the issuer 162 / subscriber 168 to execute a specific action. To set up the relationship of the issuer 162 / subscriber 168, the event service 200 can identify the target topic 166 related to a specific process 170. For example, FIG. 1A shows a first process 170a and a second process 170b. The first process 170a is shown as an issuer 162 that generates request messages 164, 164R regarding a first topic 166a, and the second process 170b is a subscriber 168 of the first topic 166a and receives the request message 164R. Next, the second process 170b functions as an issuer 162 for a second topic 166b by generating response messages 164, 164r in response to the request message 164R. The first process 170a is a subscriber of the second topic 166b that receives a response message 164r notifying the first process 170a of an action related to the request message 164R.

[0034] Referring to FIGS. 2A-2C, to establish these issuer / subscriber relationships for process 170, event service 200 performs different operations depending on whether event service 200 is instantiating process 170 or implementing process 170 during runtime. In this regard, event service 200 includes initiator 210 and runtime generator 220. Initiator 210 performs operations that occur during instantiation in process 170 that issues request message 164R (e.g., requests that some action be performed by response process 170b). In this regard, initiator 210 instantiates request process 170. When initiator 210 instantiates request process 170, initiator 210 identifies topic 166 of messaging system 150, and messaging system 150 receives response message 164r from another process 170b that responds to request message 164R of request process 170A. Here, this other process 170b is referred to as response process 170 since it responds to request message 164R. Topic 166 identified by initiator 210 is the topic 166 on which response process 170b communicates its response message 164r, and thus is referred to as response topics 164, 166r. In other words, request message 164R requests that response process 170b perform a particular action, and response topic 166r is the topic 166 on which response process 170b issues response message 164r indicating the status of the action (e.g., whether the action has been completed, failed, or is in an intermediate state). In some examples, initiator 210 identifies response process 170b that performs the action of request message 164R, and then identifies response topic 166r by determining the topic 166 to which this particular response process 170b issues as issuer 162.

[0035] When the initiator 210 identifies the response topic 166r during the instantiation of the request process 170a, the initiator 210 generates N subscriptions 212, 212a-n (also referred to as multiple subscriptions 212) for the identified response topic 166r in this particular instance of the request process 170a. Each subscription 212 generated by the initiator 210 with respect to a particular instance of the request process 170a includes a subscription identifier 214 (shown as SID). In some examples, the subscription identifier 214 refers to a unique identifier that identifies a single subscription 212 from among the multiple subscriptions 212. In other words, one subscription 212 may or may not share a common subscription identifier 214 with another subscription 212 (e.g., in a particular instance of the request process 170a).

[0036] In some embodiments, the initiator 210 generates each subscription 212 with a filter that waits for a filter value 216 (shown as Fv). Here, the filter value 216 may be unique in that there is no subscription 212 having the same filter value 216 as other subscriptions 212. The filter value 216 may be associated with the subscription identifier 214 or may be completely separate from the subscription identifier 214. For example, in FIG. 2B, each subscription 212a - n is shown with a subscription identifier 214 and a filter value 216. Further, one or both of the subscription identifier 214 and the filter value 216 in a particular subscription 212 are also unique among all subscriptions 212 of all instances in the request process 170a. This means that the subscription identifier 214 and / or the filter value 216 are not shared with any other instance of the request process 170a, whereby, for example, one or a combination of the subscription identifier 214 and the filter value 216 is unique to a particular instance of the request process 170a. By making these elements unique, the request process 170a can filter the messages 164 subscribed to, ensuring that the messages 164 received by the subscriber 168 of a particular instance of the request process 170a are targeted at that particular instance of the request process 170a. In other words, the subscription identifier 214 and / or the filter value 216 allow the event service 200 to prevent data leakage during the runtime of the request process 170a.

[0037] In some configurations, the subscription identifier 214 and / or filter value 216 corresponding to each subscription 212 are stored in a storage element such as a hash map. For example, if the storage element is a hash map, the hash map includes entries with key-value pairs where the key is a filter and the value is a subscription 212. Here, the filter corresponding to the key may be some combination of the subscription identifier 214, the filter value 216, and / or both. The size of the storage element (e.g., hash map) may correspond to the number of concurrent requests that an instance of the request process 170a can handle. This is because the service server 200 can filter the message 164 received in the response topic 166r by the filter value 216 and / or subscription identifier 214. If this is the case and these elements 214, 216 are unique to a single subscription 212, the service server 200 can completely prevent data leakage only if the filter value being used is not shared.

[0038] Referring to FIG. 2B, the initiator 210 indicates the fact that the request process 170a can be instantiated infinitely (e.g., shown as instances 1 to i), in which case each instance of the request process 170a includes a set 212, 212 of subscriptions 212, 212a~n. s For example, the first instance includes a first set 212, 212 of subscriptions 212a~n. s1 The second instance includes a second set 212, 212 of subscriptions 212a~n. s2 The i-th instance includes the i-th set 212, 212 of subscriptions 212a~n. siIt includes. If there are multiple instances, each instance may have its own storage element in the subscription identifier 214 and / or the filter value 216 corresponding to each set 212s of the subscriptions 212. Alternatively, the service server 200 may include a global storage element that stores all of the subscription identifiers 214 and / or all of the filter values 216 corresponding to all sets 212s of the subscriptions 212 (i.e., for all instances).

[0039] Referring to FIGS. 2A and 2C, after the initiator 210 performs instantiation in the request process 170a, the runtime generator 220 of the event service 200 manages how the subscription 212 is used during the runtime for the request process 170a. During the runtime for the request process 170a, the runtime generator 220 is configured to issue a request message 164R for the request topic 166R subscribed by the response process 170b. In some examples, the request message 164R corresponds to an action that the client 10 requests the action hub 140 to perform by generating a request 150. When the action hub 140 receives the request 150, the action hub 140 can provide the request 150 to the event service 200 so that the event service 200 can identify one or more actions (e.g., event-based actions) that can satisfy the request 150. For each action identified by the event service 200, the event service 200 can generate a request message 164R that requests a process 170 associated with the action that can execute the action associated with the request message 164R to execute that action. Here, in order to request the process 170 (e.g., called the response process 170b) to execute an action, the request process 170a issues a request message 164R for the request topic 166R to which the response process 170b subscribes as a subscriber 168a. As the subscriber 168a, an instance of the response process 170b receives the request message 164R and executes the action identified by or associated with the request message 164R. The response process 170b notifies the request process 170a that the action has been completed (or some status related to the action) corresponding to issuing a response message 164r as the issuer 162b to the response topic 166r.

[0040] Since the event service 200 is intended to prevent or reduce data leakage (e.g., with respect to subscription calls), the runtime generator 170a is configured to generate a subscriber 168b in the request process 170a that receives the response message 164r after the runtime generator 170a ensures that the response message 164r truly intends a specific instance of the request process 170a. To generate a subscriber 168b that only receives response messages 164r intended for a specific instance of the request process 170a, the runtime generator 220 uses the subscription identifier 214 and / or filter value 216 of each subscription 212 instantiated by the initiator 210 to generate the subscriber 162b. In some examples, the runtime generator 220 selects a subscription 212 from a set 212s of subscriptions 212 in a specific instance of the request process 170a (e.g., selects randomly), and generates a subscriber 162b in the instance of the request process 170a based on the subscription identifier 214 (and / or filter value 216) from the selected subscription 212. For example, FIG. 2C shows a runtime generator 220 that selects a second subscription 212b from a first instance of the request process 170a that the initiator 210 has already instantiated. By this approach, instead of generating subscriptions 212 during runtime where the subscriptions 212 potentially have unique identifiers for specific filtering purposes for the request message 164R and its related actions, subscribers 168 in the request process 170a are generated during runtime, and these subscribers 168 are generated using identifiers (e.g., subscription identifier 214 and / or filter value 216) that are not tied to a specific request message 164R and a specific action of the request message 164R.Furthermore, when a particular action of the request message 164 is completed and the purpose of the subscriber (to determine that a particular action has occurred) is achieved, the cloud computing environment 130 does not include the entire instance of the process 170 to be terminated. Rather, it only includes one terminated subscriber 168b. The instance of the request process 170a that generated the terminated subscriber 168b continues to exist and processes other requests by reusing the identifier(s) 214, 216 of the terminated subscriber 168b or by generating a subscriber 168 based on another subscription 212 that the initiator 210 instantiated with respect to that instance of the request process 170a.

[0041] In some configurations, the runtime generator 220 associates a unique message identifier UMI with the request message 164R. For example, when generating the request message 164R (e.g., from the request 150), the runtime generator 220 also creates the unique message identifier UMI included in the request message 164R. In some examples, in addition to associating the UMI with the request message 164R, the runtime generator 220 also associates or adds the UMI to the subscriber 168 generated by the runtime generator 220 to receive the response message 164r. If the subscriber 168b also includes the UMI, the runtime generator 220 has another way to ensure that the desired response (i.e., the response message 164r) from the response process 170b is delivered by the underlying message infrastructure associated with the initial request 150. In one way, including the UMI functions as a fail-safe. That is, the subscriber 168b is already configured to filter any message in the response topic 166r using one or both of the subscription identifier 214 or the filter value 216. In this regard, the subscriber 168b should not receive a response message 164r that is not related to the specific action requested by a particular instance of the request process 170a within the request message 164R. Further, as a fail-safe, the runtime generator 220 can 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 150 in the request message 164R. Thus, by including the UMI, the runtime generator 220 can generate a confirmation response message to confirm that the response message 164r (e.g., the filtered response message 164r) includes the UMI.

[0042] In some embodiments, the request process 170a refers to an edge server. Here, the edge server is involved in listening for incoming requests (e.g., request 150). Thus, the edge server issues a request message 164R based on request 150 in the response process 170b, such as a particular instance of the action container. In this scenario, both the request process 170a and the response process 170b can be stateless and single-threaded processes of the remote system 130. Both of these processes 170 can be scaled by being replicated as multiple instances so that each instance can operate simultaneously. This means that a first instance of the request process 170a requests an action from a third instance of the response process 170b by a first request 150, while a sixth instance of the request process 170a requests an action from a first instance of the response process 170b by a second request 150.

[0043] FIG. 3 is a flowchart of a configuration example of the operation of a method 300 for implementing an event-based distributed messaging system. Operations 302 and 304 are performed when the method 300 instantiates a request process 170a that issues requests 164, 164R for responses 164, 164r from a response process 170b. In operation 302, the method 300 identifies response topics 166, 166r of a distributed messaging service 160 that receives responses 164, 164r for requests 164, 164R from the response process 170b. The response process 170b is configured as an issuer 162 in the response topics 166, 166r. In operation 304, the method 300 generates a plurality of subscriptions 212, 212a - n for the response topic 166r, and each subscription 212 includes a subscription identifier 214. Operations 306 - 310 are performed during runtime in the request process 170a. In operation 306, the method 300 issues request messages 164, 164R for request topics 166, 166R subscribed to by the response process 170b. The request messages 164, 164R include a unique message identifier UMI. In operation 308, the method 300 generates a subscriber 168 using each subscription identifier 214 of each subscription 212 selected from the plurality of subscriptions 212, 212a - n. The subscriber 168 includes a unique message identifier UMI. In operation 310, the method 300 receives filtered response messages 164, 164r from the response process 170b at the subscriber 168 in response to the request messages 164, 164R issued for the response topics 166, 166R. Here, the filtered response messages 164, 164r are filtered based on one or more subscription identifiers 214 associated with the plurality of subscriptions 212, 212a - n in the request process 170a.

[0044] FIG. 4 is a schematic diagram of an example of a computing device 400 that may be used to implement the systems and methods described in this document. Computing device 400 is intended to represent various forms of digital computers, such as a laptop, desktop, workstation, portable information terminal, server, blade server, mainframe, and other appropriate computers. The components shown here, their connections and relationships, and their functions are for illustrative purposes only and are not intended to limit the embodiments of the invention described and / or claimed in this document.

[0045] Computing device 400 includes a processor 410 (e.g., data processing hardware), a memory 420 (e.g., memory hardware), a storage device 430, a high-speed interface / controller 440 connected to memory 420 and high-speed expansion port 450, and a low-speed interface / controller 460 connected to low-speed bus 470 and storage device 430. Each of the components 410, 420, 430, 440, 450, and 460 is interconnected using various buses and may be implemented on a common motherboard or in other manners as required. Processor 410 can process instructions for execution within computing device 400, including instructions stored in memory 420 or storage device 430 for displaying graphical information for a graphical user interface (GUI) on an external input / output device such as display 480 coupled to high-speed interface 440. In other embodiments, multiple processors and / or multiple buses may be used, along with multiple memories and types of memory, as required. Also, multiple computing devices 400 may be connected, in which case each device may provide a portion of the required operations (e.g., as a server bank, a group of blade servers, or a multiprocessor system).

[0046] Memory 420 stores information non - transiently within computing device 400. Memory 420 may be a computer - readable medium, (a plurality of) volatile memory units, or (a plurality of) non - volatile memory units. The non - transient memory 420 may be a physical device used to store temporarily or persistently a program (e.g., a sequence of instructions) or data (e.g., program state information) for use by computing device 400. Examples of non - volatile memory include, but are not limited to, flash memory and read - only memory (ROM) / programmable read - only memory (PROM) / erasable programmable read - only memory (EPROM) / electrically erasable programmable read - only memory (EEPROM) (typically used for firmware such as a boot program). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase - change memory (PCM), and disks and tapes.

[0047] Storage device 430 can provide mass storage to computing device 400. In some embodiments, storage device 430 is a computer - readable medium. In various different embodiments, storage device 430 may be a floppy (registered trademark) disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid - state memory device, or an array of devices including a storage area network or other configured devices. In further embodiments, a computer program product is specifically incorporated into an information carrier. The computer program product includes instructions that, when executed, perform one or more methods as described above, for example. The information carrier is a computer - readable or machine - readable medium such as memory 420, storage device 430, or memory on processor 410.

[0048] The high-speed controller 440 manages operations that consume a large amount of bandwidth for the computing device 400, while the low-speed controller 460 manages operations that consume little bandwidth. Such an assignment of responsibilities is merely an example. In some embodiments, the high-speed controller 440 is coupled to a high-speed expansion port 450 that can accept the memory 420, the display 480 (e.g., via a graphics processor or accelerator), and various expansion cards (not shown). In some embodiments, the low-speed controller 460 is coupled to the storage device 430 and the low-speed expansion port 490. The low-speed expansion port 490, which may include various communication ports (e.g., USB, Bluetooth®, Ethernet®, wireless Ethernet, etc.), can be coupled to one or more input / output devices such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., via a network adapter.

[0049] As shown, the computing device 400 can be implemented in several different forms. For example, the computing device can be implemented as a standard server 400a, or multiple times within a group of such servers 400a, as a laptop computer 400b, or as part of a rack server system 400c.

[0050] The various embodiments of the systems and techniques described herein can be realized in digital electronic circuits and / or optical circuits, integrated circuits, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include embodiments implemented in one or more computer programs that are executable and / or interpretable in a programmable system including at least one programmable processor coupled to receive and transmit data and instructions to and from a memory system, at least one input device, and at least one output device.

[0051] These computer programs (also known as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., magnetic disks, optical disks, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives the machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0052] The processes and logical flows described herein can be performed by one or more programmable processors that execute one or more computer programs to function by operating on input data to produce output. The processes and logical flows can also be performed by special-purpose logic circuits, such as, for example, FPGAs (Field Programmable Gate Arrays) and ASICs (Application Specific Integrated Circuits). Examples of processors suitable for the execution of computer programs include both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. In general, a processor receives instructions and data from a read-only memory, a random access memory, or both. Essential elements of a computer are a processor that executes instructions and one or more memory devices that store instructions and data. In general, a computer also includes, or is operatively coupled to receive data from, or transfer data to, or both, one or more mass storage devices for storing data, such as, for example, magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Examples of computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices, magnetic disks, such as internal hard disks and removable disks, magneto-optical disks, CDROM, and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special-purpose logic circuits.

[0053] To provide interaction with a user, one or more aspects of the present disclosure can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touch screen, and optionally a keyboard and a pointing device, such as a mouse or trackball, by which the user can input to the computer. Other types of devices can also be used to provide interaction with the user. For example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and the input from the user can be received in any form, including acoustic, voice, or tactile input. Further, the computer can interact with the user by transmitting and receiving documents to and from the devices used by the user, for example, by transmitting a web page to a web browser on the user's client device in response to a request received from a web browser.

[0054] Some embodiments have been described. Nevertheless, it can be understood that various modifications can be made without departing from the spirit and scope of the present disclosure. Accordingly, other embodiments are also within the scope of the claims.

Claims

1. A method for causing the data processing hardware to execute an operation when executed by the data processing hardware, comprising: When instantiating a request process that issues a request for a response from a response process, The operation includes identifying a response topic of a distributed messaging service that receives the response for the request from the response process, and the response process is configured as a publisher for the response topic; Generating a plurality of subscriptions for the response topic, each subscription including a subscription identifier; During runtime for the request process, Issuing a request message to a request topic subscribed to by the response process, the request message including a unique message identifier; Generating a subscriber using each subscription identifier of each of the plurality of subscriptions selected from the plurality of subscriptions, the subscriber including the unique message identifier; Receiving, at the subscriber, a filtered response message from the response process in response to the request message issued to the response topic, the filtered response message being filtered based on one or more subscription identifiers associated with the plurality of subscriptions for the request process.

2. The method according to claim 1, wherein the operation further includes randomly selecting each of the plurality of subscriptions from the plurality of subscriptions during runtime for the request process.

3. The operation includes: Storing each subscription identifier of the plurality of subscriptions for the response topic in a hash map when instantiating the request process that issues the request for a response from the response process; and Randomly selecting each of the subscription identifiers from the hash map storing each subscription identifier of the plurality of subscriptions for the response topic during runtime for the request process; The method according to claim 1 or claim 2, further comprising.

4. The method according to any one of claims 1 to 3, wherein the operation further comprises generating, during a runtime for the request process, the request message for the request topic.

5. The operation includes determining whether one or more messages by an issuer of the request topic include the unique message identifier, and when each of the one or more messages by the issuer of the request topic does not include the unique message identifier, preventing each of the messages from being received by the subscriber, The method according to any one of claims 1 to 4, wherein the operation further comprises filtering, during a runtime for the request process, the one or more messages by an issuer of the request topic.

6. The one or more messages by an issuer of the request topic include the filtered response message, The operation further comprises generating, during a runtime for the request process, an acknowledgement response message when the filtered response message includes the unique message identifier, The method according to claim 5.

7. The request process is instantiated in response to receiving a first request for executing a computing task, The operation during a runtime for the request process further comprises generating a first response to the first request for executing the computing task when receiving the filtered response message from the response process in response to the request message issued for the request topic. The method according to any one of claims 1 to 6.

8. The method according to any one of claims 1 to 7, wherein the subscription identifier is unique among a plurality of instances of the request process.

9. The subscription identifier includes a unique filter value, The filtered response message is filtered based on the unique filter value of each subscription used to generate the subscriber, The method according to any one of claims 1 to 8.

10. The method according to any one of claims 1 to 9, wherein each subscriber of each topic of the distributed messaging service functions as a multicast subscription that searches for all messages communicated on the respective topic.

11. A system comprising data processing hardware and memory hardware communicating with the data processing hardware, wherein the memory hardware stores instructions that cause the data processing hardware to perform operations when executed by the data processing hardware, when instantiating a request process that issues a request for a response from a response process, the operations include identifying a response topic of a distributed messaging service that receives the response for the request from the response process, the response process being configured as a publisher for the response topic, generating a plurality of subscriptions for the response topic, each subscription including a subscription identifier, during runtime for the request process, issuing a request message to a request topic subscribed to by the response process, the request message including a unique message identifier, generating subscribers using the subscription identifier of each of the respective subscriptions selected from the plurality of subscriptions, the subscribers including the unique message identifier, receiving, at the subscriber, a filtered response message from the response process in response to the request message issued to the response topic, the filtered response message being filtered based on one or more subscription identifiers associated with the plurality of subscriptions for the request process, system.

12. The system according to claim 11, wherein the operations further include randomly selecting the respective subscriptions from the plurality of subscriptions during runtime for the request process.

13. The operations are When instantiating the request process that issues the request for the response from the response process, storing each subscription identifier of the plurality of subscriptions for the response topic in a hash map; During the runtime for the request process, randomly selecting each subscription identifier from the hash map that stores each subscription identifier of the plurality of subscriptions for the response topic; The system according to claim 11 or claim 12, further comprising.

14. The system according to any one of claims 11 to 13, wherein the operation further comprises generating the request message for the request topic during the runtime for the request process.

15. The operation is By determining whether one or more messages by the issuer of the request topic include the unique message identifier, and When each message of the one or more messages by the issuer of the request topic does not include the unique message identifier, by preventing each message from being received by the subscriber, The system according to any one of claims 11 to 14, further comprising filtering the one or more messages by the issuer of the request topic during the runtime for the request process.

16. The one or more messages by the issuer of the request topic include the response message to be filtered, The operation further comprises generating an acknowledgement response message when the response message to be filtered includes the unique message identifier during the runtime for the request process. The system according to claim 15.

17. The request process is instantiated in response to receiving a first request for executing a computing task, The operation during the runtime for the request process further comprises generating a first response to the first request for executing the computing task when receiving the filtered response message from the response process in response to the request message issued for the request topic. The system according to any one of claims 11 to 16.

18. The system according to any one of claims 11 to 17, wherein the subscription identifier is unique among a plurality of instances of the request process.

19. The subscription identifier includes a unique filter value, and the filtered response message is filtered based on the unique filter value of each of the subscriptions used to generate the subscriber. The system according to any one of claims 11 to 18.

20. The system according to any one of claims 11 to 19, wherein each subscriber of each topic of the distributed messaging service functions as a multicast subscription that searches for all messages communicated on each of the topics.

21. A program that, when executed by data processing hardware, causes the data processing hardware to execute the method according to any one of claims 1 to 10.

Images