Coordinating asynchronous communication among microservices

Techniques are described relating to coordinating asynchronous communication among a plurality of client microservices in a managed services domain of a cloud computing environment. An associated computer-implemented method includes receiving at a single request topic queue of a message broker application programming interface (API) at least one message associated with a topic from at least one publisher microservice among the plurality of client microservices. The method further includes identifying an authorization identification parameter included in each of the at least one message. The method further includes publishing each of the at least one message to a respective bucket within a single response topic queue of the message broker API, the respective bucket corresponding to one of at least one subscriber microservice among the plurality of client microservices associated with the authorization identification parameter included in the message.

BACKGROUND

The various embodiments described herein generally relate to message handling among microservices. More specifically, the various embodiments describe techniques of coordinating asynchronous communication among a plurality of client microservices in a managed services domain of a cloud computing environment.

SUMMARY

The various embodiments described herein provide techniques of coordinating asynchronous communication among a plurality of client microservices. According to an embodiment, an associated computer-implemented method includes receiving at a single request topic queue of a message broker application programming interface (API) at least one message associated with a topic from at least one publisher microservice among the plurality of client microservices. The method further includes identifying an authorization identification parameter included in each of the at least one message. The method further includes publishing each of the at least one message to a respective bucket within a single response topic queue of the message broker API, the respective bucket corresponding to one of at least one subscriber microservice among the plurality of client microservices associated with the authorization identification parameter included in the message.

One or more additional embodiments pertain to a computer program product including a computer readable storage medium having program instructions embodied therewith. According to such additional embodiment(s), the program instructions are executable by a computing device to cause the computing device to perform one or more steps of and/or to implement one or more embodiments associated with the above recited computer-implemented method. One or more further embodiments pertain to a system having at least one processor and a memory storing an application program, which, when executed on the at least one processor, performs one or more steps of and/or implements one or more embodiments associated with the above recited computer-implemented method.

DETAILED DESCRIPTION

The various embodiments described herein are directed to techniques of coordinating asynchronous communication among client microservices in a managed services domain of a cloud computing environment, e.g., a virtualized environment in which one or more computing capabilities are available as a service. In the context of the various embodiments, a client microservice is an independently deployable service or component associated with one or more client applications. A client microservice optionally has an individual technology stack and/or optionally is organized by business capability. Each client microservice enables a respective action type or a respective set of action types associated with a certain workflow and/or a certain task. A cloud server application of a cloud server system configured to coordinate client microservice communication may incorporate a message broker application programming interface (API) having a capability to process messages among the client microservices. A respective message received at the message broker API for publication in accordance with the various embodiments includes an authentication identification parameter (or authentication identification parameters) associated with a subscriber microservice (or subscriber microservices) among the client microservices to which the respective message is destined. The various embodiments enable publication of messages to respective buckets within a response topic queue that are associated with subscriber microservices. In the context of the various embodiments, a bucket is a logical topic queue partition configured to store data, including messages, associated with a respective subscriber microservice. Optionally, a bucket is or includes a container or buffer.

The various embodiments described herein may have advantages over conventional techniques. Specifically, the various embodiments improve computer technology by enabling storage of messages in a topic queue of a message broker API within buckets respectively associated with subscriber microservices. Such bucket-based implementation facilitates targeted message publication to subscriber microservices. Targeted message publication permits a subscriber microservice to prepare for resource requirements associated with any published message. Additionally, such bucket-based implementation facilitates message privacy and/or security among subscriber microservices by enabling message access control based upon bucket access. The various embodiments further enable dynamic creation of a bucket for a new subscriber microservice at runtime, thus facilitating topic queue scalability. The various embodiments further enable use of a single request topic queue and a single response topic queue, or alternatively use of a single request-response topic queue, for a certain topic addressed by a message broker API. Some of the various embodiments may not include all such advantages, and such advantages are not necessarily required of all embodiments.

Particular embodiments describe techniques relating to asynchronous communication coordination in a managed services domain. However, it is to be understood that the techniques described herein may be adapted to a variety of purposes in addition to those specifically described herein. Accordingly, references to specific embodiments are included to be illustrative and not limiting.

The various embodiments described herein may be provided to end users through a cloud computing infrastructure. It is to be understood that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, the various embodiments described herein are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in the cloud, without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

FIG.2illustrates a set of functional abstraction layers provided by cloud computing environment50, according to an embodiment. It should be understood in advance that the components, layers, and functions shown inFIG.2are intended to be illustrative only; embodiments of the invention are not limited thereto. As depicted, various layers and corresponding functions are provided. Specifically, hardware and software layer60includes hardware and software components. Examples of hardware components may include mainframes61, RISC (Reduced Instruction Set Computer) architecture based servers62, servers63, blade servers64, storage devices65, and networks and networking components66. In some embodiments, software components may include network application server software67and database software68. Virtualization layer70provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers71; virtual storage72; virtual networks73, including virtual private networks; virtual applications and operating systems74; and virtual clients75.

In one example, management layer80may provide the functions described below. Resource provisioning81may provide dynamic procurement of computing resources and other resources that are utilized to perform tasks within cloud computing environment50. Metering and pricing82may provide cost tracking as resources are utilized within cloud computing environment50, and billing or invoicing for consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal83may provide access to the cloud computing environment for consumers and system administrators. Service level management84may provide cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment85may provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with a SLA.

Workloads layer90provides examples of functionality for which cloud computing environment50may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation91; software development and lifecycle management92; virtual classroom education delivery93; data analytics processing94; transaction processing95; and microservice message handling96. Microservice message handling96may enable coordination of asynchronous communication among client microservices in accordance with the various embodiments described herein.

FIG.3illustrates a managed services domain300within cloud computing environment50. As shown, managed services domain300includes a cloud server system310. In an embodiment, cloud server system310includes a cloud server application320, which may be capable of enabling and/or facilitating message handling in accordance with the various embodiments described herein. Cloud server application320includes a message broker API325. Furthermore, as shown, managed services domain300includes a database system330, a directory server system340, and a plurality of application server clusters3501to350n. Message broker API325is configured to process and publish messages received from client microservices3601to360n. Moreover, in an embodiment, cloud server application320and optionally other component(s) of cloud server system310are configured to communicate with database system330, directory server system340, application server clusters3501to350n, and/or client microservices3601to360n.

Database system330includes one or more database servers, which may store and/or manage various data aspects related to message handling as facilitated by cloud server application320. In an embodiment, database system330stores relationships among the plurality of application server clusters3501to350n. In an additional embodiment, database system330stores relationships and/or other data aspects associated with client microservices3601to360n. In a further embodiment, database system330is managed via a database management system (DBMS). In a further embodiment, database system330includes one or multiple databases, some or all of which may be relational databases manageable by a relational database management system (RDBMS). In a further embodiment, database system330includes one or more ontology trees or other ontological structures. Directory server system340facilitates authentication of client microservices3601to360nand/or other clients associated with managed services domain300. In an embodiment, directory server system340facilitates client authentication with respect to one or more of application server clusters3501to350n. For purposes of authentication with respect to one or more of a plurality of applications in managed services domain300, e.g., cloud server application320, a client among client microservices3601to360nor other client may provide relevant environment details and credentials relevant to such application(s). Application server clusters3501to350nstore aspects of various applications as well as provide managed server services to client microservices3601to360nand/or other clients. In a further embodiment, some or all application servers within application server clusters3501to350nare configured to communicate with one another.

FIG.4illustrates a method400of coordinating asynchronous communication. In an embodiment, one or more steps associated with the method400are carried out in an environment in which computing capabilities are provided as a service (e.g., cloud computing environment50). According to such embodiment, one or more steps associated with the method400are carried out in a managed services domain within a cloud computing environment (e.g., managed services domain300). The cloud computing environment optionally is a hybrid cloud environment. In an additional embodiment, one or more steps associated with the method400are carried out in one or more other environments, such as a client-server network environment or a peer-to-peer network environment. A cloud server application in a managed services domain (e.g., cloud server application320of cloud server system310in managed services domain300) facilitates processing according to the method400and related methods described herein. The message handling techniques facilitated or otherwise carried out via the cloud server application in the managed services domain may be associated with microservice message handling capabilities within a workloads layer among functional abstraction layers provided by the cloud computing environment (e.g., microservice message handling96within workloads layer90of cloud computing infrastructure50). In accordance with the method400, the cloud server application coordinates asynchronous communication among a plurality of client microservices in the managed services domain (e.g., client microservices3601to360n).

In the context of the method400and related methods described herein, the cloud server application provides, or is capable of providing, a client (or legal representative(s) of the client) as well as any other authorized entity associated with asynchronous communication advance notice of any personal data collection. The server application further provides any affected entity an option to opt in or opt out of any such personal data collection at any time. Optionally, the server application further transmits at least one notification to any affected entity each time any such personal data collection occurs and/or at designated time intervals.

In an embodiment, the method400begins at step405, where the cloud server application receives at a single request topic queue of a message broker API (e.g., message broker API325) at least one message associated with a topic from at least one publisher microservice among the plurality of client microservices. The message broker API is associated with the cloud server application and is configured to handle asynchronous messaging aspects in accordance with the various embodiments. Topics associated with the various embodiments are open ended and optionally are applicable in the context of any message-based communication. Topic queues within the message broker API are associated with respective topics and are implementation dependent. The message broker API is a general framework for message processing that optionally handles a respective topic or a topical class or alternatively handles multiple topics or topical classes. In an embodiment, the message broker API is configured to handle a plurality of topics, including the topic with which the at least one message received at step405is associated. In a further embodiment, the cloud server application dynamically allocates memory for topic queue creation within a message broker API at runtime based upon microservice messaging demands. In a further embodiment, the cloud server application facilitates creation and/or maintenance of a respective request topic queue within the message broker API for each of a plurality of topics, including creation and/or maintenance of the single request topic queue for the topic with which the at least one message received at step405is associated. According to such further embodiment, the single request topic queue is dedicated to the topic with which the at least one message is associated. In the context of the various embodiments, a publisher microservice is a client microservice sending for publication at least one message with regard to a topic. In the context of the method400, the at least one publisher microservice sends the at least one message to the message broker API for publication. In a further embodiment, according to step405the cloud server application receives at the single request topic queue each of the at least one message, regardless of any condition associated with the message.

In an embodiment, each of the at least one message received at step405includes a message key parameter, a message value, and an authorization identification parameter. In an additional embodiment, the message key parameter facilitates message aggregation. According to such additional embodiment, the cloud server application utilizes the message key parameter to group messages and/or to handle partitioning of topics. With regard to topic partitioning, messages with a same message key optionally are organized into a respective topic partition. In a further embodiment, the cloud server application determines message routing, e.g., routing of one or more messages among the at least one message received at step405, based upon the message key parameter. In a further embodiment, the message value included in a respective message among the at least one message includes or otherwise indicates a message payload. The message payload includes information to be transmitted via the relevant message, e.g., data and/or request(s) intended for a message recipient.

The authorization identification parameter included in a respective message among the at least one message optionally is represented by a character, numerical, or string data type, e.g., a “bucket_auth_id” variable value in character, integer, or string format. The authorization identification parameter indicates an intended destination microservice. If a destination microservice associated with a respective message among the at least one message is a subscriber microservice among the plurality of client microservices, as further described herein the cloud server application publishes the message to the subscriber microservice associated with the authorization identification parameter included in the respective message. In an embodiment, one or more of the at least one message received at step405includes an authorization identification parameter in a respective message header. In an additional embodiment, one or more of the at least one message received at step405includes an authorization identification parameter within the message body, optionally partitioned from other message content. As described below, optionally at least one message among the at least one message received at step405includes multiple authorization identification parameters.

At step410, the cloud server application identifies an authorization identification parameter included in each of the at least one message. In an embodiment, the cloud server application identifies the authorization identification parameter in a message among the at least one message by processing a message header including the authorization identification parameter. In a further embodiment, the cloud server application identifies the authorization identification parameter in a message among the at least one message by parsing the message to separate the authorization identification from other portions of the message. In one or more embodiments, at least one respective message among the at least one message includes multiple authorization identification parameters. According to such one or more embodiments, the cloud server application identifies each of the multiple authorization identification parameters included in the at least one respective message, e.g., by processing a message header of one or more of the at least one respective message including the multiple authorization identification parameters and/or by parsing one or more of the at least one respective message to separate the multiple authorization identification parameters from other message portions.

At step415, the cloud server application publishes each of the at least one message to a respective bucket within a single response topic queue of the message broker API. The respective bucket to which the cloud server application publishes each message among the at least one message corresponds to one of at least one subscriber microservice among the plurality of client microservices associated with the authorization identification parameter included in the message. Accordingly, the respective bucket corresponds to a subscriber microservice that is associated with the authorization identification parameter included in the message. A bucket is logical partition of the single response topic queue. One or more buckets associated with the single response topic queue are respective logical partitions of such queue. In certain contexts, particularly with respect to message processing, the cloud server application handles each bucket as a separately functional data structure, e.g., a separately functional queue. In an embodiment, each bucket within the single response topic queue corresponds to a single subscriber microservice among the plurality of client microservices. According to such embodiment, the cloud server application assigns each bucket a correspondence relationship to a single subscriber microservice such that there is a one-to-one correspondence between a respective bucket and a respective subscriber microservice. In an alternative embodiment, at least one bucket within the single response topic queue corresponds to multiple subscriber microservices. According to such alternative embodiment, the respective bucket to which the cloud server application publishes each message among the at least one message at step415corresponds to one or more subscriber microservices associated with the authorization identification parameter included in the message. According to such alternative embodiment, multiple subscriber microservices optionally are associated with a single authorization identification parameter. In a further embodiment, the cloud server application facilitates creation and/or maintenance of a respective response topic queue within the message broker API for each of a plurality of topics, including creation and/or maintenance of the single response topic queue for the topic with which each of the at least one message published according to step415is associated. According to such further embodiment, the single response topic queue is dedicated to the topic with which the at least one message is associated.

In the context of the various embodiments, a subscriber microservice is a client microservice subscribing to a topic. In the context of the method400, the at least one subscriber microservice is subscribed to the topic with which the at least one message is associated. The single response topic queue is configured to store messages associated with the topic with which the at least one message is associated in a respective bucket based upon authorization identification parameter. As further described herein with respect toFIG.6, a respective client microservice among the plurality of client microservices subscribes to the topic with which the at least one message is associated by sending a subscription request to the cloud server application, the subscription request including at least one subscriber identification attribute associated with the respective client microservice. As further described herein, consequent to sending the subscription request, the cloud server application creates a bucket within the single response topic queue corresponding to the respective client microservice. According to step415, the cloud server application publishes each of the at least one message by placing each message into a respective bucket within the single response topic queue based upon the authorization identification parameter included in the message. Since each bucket within the single response topic queue corresponds to a subscriber microservice among the plurality of client microservices, and since each subscriber microservice is associated with an authorization identification parameter, according to step415the cloud server application publishes each of the at least one message to a respective bucket corresponding to a subscriber microservice that is associated with the authorization identification parameter included in the message.

In an embodiment, responsive to determining that a respective message among the at least one message includes an authorization identification parameter associated with a respective client microservice that does not correspond to any bucket within the single response topic queue, i.e., a non-subscribing client microservice, the cloud server application optionally refrains from publishing the respective message. For instance, in the context of the method400, assuming that a publisher microservice MS2transmits to the message broker API a certain message destined for a microservice MS7, the cloud server application refrains from publishing the certain message if microservice MS7does not correspond to any bucket within the single response topic queue, since in this scenario microservice MS7is not subscribed to the topic with which the message is associated. In a further embodiment, responsive to determining that a respective message among the at least one message includes an authorization identification parameter associated with a respective client microservice that does not correspond to any bucket within the single response topic queue, the cloud server application stores the respective message for future potential publication, e.g., in a holdover data structure. The holdover data structure optionally is a holdover queue separate from the single response topic queue or alternatively is a holdover bucket or other partition within the single response topic queue. According to such further embodiment, upon topic subscription of the respective client microservice associated with the authorization identification parameter included in the respective message, the cloud server application optionally publishes the respective message stored in the holdover data structure to the single response topic queue according to step415, e.g., optionally transfers the respective message from the holdover data structure to a newly created bucket within the single response topic queue corresponding to the respective client microservice.

In the context of the various embodiments, the single request topic queue and the single response topic queue facilitate topical organization of messages according to bucket-based authorization. To enable bucket-based authorization processing, messages include the authorization identification parameter in addition to the message key parameter and the message value. According to one or more embodiments in which at least one respective message among at least one message published includes multiple authorization identification parameters, the cloud server application publishes the at least one respective message to multiple buckets within the single response topic queue, the multiple buckets corresponding to respective subscriber microservices associated with the multiple authorization identification parameters included in the at least one respective message. Accordingly, consequent to such bucket-based publication, the respective subscriber microservices associated with the multiple authorization identification parameters included in the at least one respective message may access the at least one respective message via the multiple buckets. In the context of the various embodiments, publishing a respective message among the at least one message may be referred to as pushing the respective message.

In an embodiment, the cloud server application enables at least one bucket safeguard to ensure privacy and/or security of messages published to each respective bucket within the single response topic queue. According to such embodiment, the cloud server application enables message access control based upon bucket access, such that messages published to the respective bucket are accessible only to a subscriber microservice corresponding to the respective bucket. According to such embodiment, the cloud server application restricts access to messages published to a respective bucket to a subscriber microservice corresponding to the respective bucket, thus restricting or preventing sharing of messages published to the respective bucket among other subscriber microservices not in correspondence with the respective bucket. By publishing according to such embodiment, the cloud server application may preserve security benchmarks among the plurality of client microservices.

Upon bucket publication of a respective message among the at least one message including an authorization identification parameter, consequent to topic subscription a respective subscriber microservice associated with the authorization identification parameter is automatically notified of the respective message. In an embodiment, the cloud server application is configured to automatically notify a respective subscriber microservice among the at least one subscriber microservice upon publication of a message to a respective bucket corresponding to the respective subscriber microservice. In a related embodiment, the cloud server application sends, optionally via the message broker API, a publication notification message to a subscriber microservice upon publishing a respective message to a respective bucket corresponding to the subscriber microservice. According to such related embodiment, the cloud server application enables both targeted publication of a respective message and targeted notification regarding the publication based upon the authorization identification parameter included in the respective message. Targeted publication notification enables the subscriber microservice to which the cloud server application publishes a respective message to be prepared with resource requirements associated with the respective message and further avoids unnecessary publication notification to client microservices unassociated with the respective message. In an additional embodiment, a respective subscriber microservice among the at least one subscriber microservice is configured to repetitively check for messages published to a respective bucket within the single response topic queue corresponding to the respective subscriber microservice. According to such additional embodiment, the at least one subscriber microservice optionally interfaces with the single response topic queue at periodic intervals and/or at designated points in time, e.g., in accordance with a messaging protocol. Publication to a respective bucket according to step415enables a respective subscriber microservice to avoid searching or parsing messages irrelevant to any data associated with the respective subscriber service and irrelevant to any service rendered via the respective subscriber microservice. A method of publishing each of the at least one message to a respective bucket within the single response topic queue in accordance with step415is described with respect toFIG.5.

In an embodiment, in the context of the method400and related methods described herein, one or more of the at least one publisher microservice are among the at least one subscriber microservice. In an analogous embodiment, in the context of the method400and related methods, one or more of the at least one subscriber microservice are among the at least one publisher microservice. In a further embodiment, one or more client microservices publish and subscribe to a same topic, e.g., the topic with which the at least one message is associated in the context of the method400and related methods. According to such further embodiment, one or more client microservices both publish to the single request topic queue and subscribe to the single response topic queue.

In one or more embodiments, the single request topic queue of the message broker API as described in the context of the method400and related methods is dedicated to facilitating receipt of the at least one message from the at least one publisher microservice according to step405, and the single response topic queue of the message broker API is dedicated to facilitating publication of each of the at least one message to the at least one subscriber microservice according to step415. According to such one or more embodiments, each of the at least one publisher microservice among the plurality of client microservices sends to the dedicated single request topic queue message(s) for publication, and each of the at least one subscriber microservice among the plurality of client microservices subscribes to the dedicated single response topic queue. In one or more alternative embodiments, the single request topic queue of the message broker API and the single response topic queue of the message broker API as described in the context of the method400are combined into a single request-response topic queue. According to such one or more alternative embodiments, optionally one or more client microservices among the plurality of client microservices both publish and subscribe to the single request-response topic queue. Optionally, the single request-response topic queue includes all or some functionality of the single request topic queue, and further includes all or some functionality of the single response topic queue, as described in the context of the method400and related methods.

By configuring the single request topic queue and the single response topic queue for the topic with which the at least one message is associated according to the method400, the cloud server application prevents inefficient proliferation of topic queues associated with the topic and further prevents unintended sharing of messages across topics. Topic queue configuration in accordance with the various embodiments facilitates scaling of the message broker API to handle multiple subscriber microservices among the plurality of client microservices and messages associated therewith. Furthermore, by configuring buckets within the single response topic queue for the topic with which the at least one message is associated according to the method400, the cloud server application enables targeted message publication to respective subscriber microservices and facilitates preservation of message privacy and/or security.

In sum, coordinating asynchronous communication among a plurality of client microservices according to the method400includes receiving at a single request topic queue of a message broker API at least one message associated with a topic from at least one publisher microservice among the plurality of client microservices, identifying an authorization identification parameter included in each of the at least one message, and publishing each of the at least one message to a respective bucket within a single response topic queue of the message broker API, the respective bucket corresponding to one of at least one subscriber microservice among the plurality of client microservices associated with the authorization identification parameter included in the message.

FIG.5illustrates a method500of publishing each of the at least one message to a respective bucket within the single response topic queue of the message broker API. The method500provides one or more embodiments with respect to step415of the method400. The method500begins at step505, where the cloud server application transfers, via a message handling microservice associated with the message broker API, the message from the single request topic queue to the single response topic queue. In the context of the various embodiments, a message handling microservice is a generic microservice configured to coordinate message handling, including message transfer, between topic queues. In an embodiment, the message handling microservice is a constituent component of the message broker API. In an alternative embodiment, the message handling microservice is communicatively coupled to the message broker API. In an additional embodiment, the message handling microservice is dedicated to message transfer from the single request topic queue to the single response topic queue. In a further embodiment, the message handling microservice sends a transfer request to the single request topic queue, obtains the message information for transfer to the single response topic queue including the authorization identification parameter(s), and receives an acknowledgment response to the transfer request from the single response topic queue upon transfer. According to such further embodiment, the message handling microservice sends the transfer request to the single request topic queue and waits for the acknowledgement response to the transfer request from the single response topic queue via at least one asynchronous programming language function call. In a further embodiment, the message handling microservice is configured to repetitively check for messages received at the single request topic queue. According to such further embodiment, the message handling microservice optionally interfaces with the single request topic queue at periodic intervals and/or at designated points in time, e.g., in accordance with a messaging protocol. According to one or more alternative embodiments in which the single request topic queue of the message broker API and the single response topic queue of the message broker API are combined into a single request-response topic queue, the cloud server application skips step505and begins the method500at step510, since the combination of the single request topic queue and the single response topic queue renders the transfer step unnecessary for publication.

At step510, the cloud server application places the message into a respective bucket within the single response topic queue based upon the authorization identification parameter included in the message. According to step510, the cloud server application pushes the message to the single response topic queue. The cloud server application pushes the message via the message handling microservice of the message broker API, unless the single request topic queue and the single response topic queue are combined according to one or more alternative embodiments. Upon arrival at the single response topic queue, the message is automatically routed to a respective bucket based upon the authorization identification parameter. Bucket-based publication enables a new design pattern paradigm in the context of event based communication. Bucket-based communication according to the methods described herein facilitates targeted publication to a topic queue, specifically the single response topic queue. In a related embodiment, the cloud server application places the message into a respective bucket within the single response topic queue by storing the message in a queue partition corresponding to the respective bucket. Such queue partition optionally is a physical partition of the single response topic queue or alternatively is a separate data structure associated with the respective bucket. In the event that the message includes multiple authorization identification parameters, at step510the cloud server application places the message into multiple respective buckets within the single response topic queue based upon the multiple authorization identification parameters included in the message.

According to one or more alternative embodiments in which the single request topic queue and the single response topic queue are combined into a single request-response topic queue, the cloud server application publishes each of the at least one message to a respective bucket within the single response topic queue in the context of step415of the method400and in the context of the method500by publishing to a respective bucket within the single request-response topic queue. Thus, according to such one or more alternative embodiments, at step510the cloud server application places the message into a respective bucket within the single request-response topic queue based upon the authorization identification parameter included in the message. According to such one or more alternative embodiments, each of the at least one publisher microservice among the plurality of client microservices publishes a respective message to the single request-response topic queue, and each of the at least one subscriber microservice among the plurality of client microservices subscribes to the single request-response topic queue. In a related embodiment, the cloud server application places the message into a respective bucket within the single request-response topic queue by storing the message in a queue partition corresponding to the respective bucket. Such queue partition optionally is a physical partition of the single request-response topic queue or alternatively is a separate data structure associated with the respective bucket.

In sum, publishing each of the at least one message according to the method500includes transferring, via a message handling microservice associated with the message broker API, the message from the single request topic queue to the single response topic queue and placing the message into a respective bucket within the single response topic queue based upon the authorization identification parameter included in the message.

FIG.6illustrates a method600of configuring microservice subscription. According to the method600, the cloud server application configures the single response topic queue to which each of the at least one message is published according to the methods400and500. The method600begins at step605, where the cloud server application receives from a requesting microservice among the plurality of client microservices a request to subscribe to the topic with which the at least one message is associated. The request received at step605includes at least one subscriber identification attribute. At step610, the cloud server application creates an authorization identification parameter associated with the requesting microservice based upon the at least one subscriber identification attribute. At step615, the cloud server application creates a bucket corresponding to the requesting microservice within the single response topic queue. According to step615, the cloud server application creates a link between the authorization identification parameter associated with the requesting microservice and the bucket. Based upon such link, the cloud server application creates a correspondence relationship between the bucket and the requesting microservice. In an embodiment, the cloud server application is configured to handle new subscribers at runtime. According to such embodiment, the cloud server application is configured to create a bucket for the requesting microservice associated with the single response topic queue at runtime, thus dynamically scaling the single response topic queue in response to subscriber additions. In the context of one or more alternative embodiments in which the single request topic queue and the single response topic queue are combined into a single request-response topic queue, the cloud server application creates a bucket for the requesting microservice within the single request-response topic queue. At step620, the cloud server application designates the requesting microservice as a subscriber microservice among the at least one subscriber microservice. In a related embodiment, the cloud server application sends a subscription confirmation message to the requesting microservice including the authorization identification parameter and relevant bucket information. In a further related embodiment, the cloud server application optionally adds the requesting microservice to a data structure including the at least subscriber microservice and/or labels the requesting microservice as a subscriber microservice in data records tracking the at least one subscriber microservice. In the context of the various embodiments, microservice topic subscription is an implementation of a publish-subscribe messaging pattern.

In sum, configuring microservice subscription according to the method600includes receiving from a requesting microservice among the plurality of client microservices a request to subscribe to the topic, the request including at least one subscriber identification attribute, creating an authorization identification parameter associated with the requesting microservice based upon the at least one subscriber identification attribute, creating a bucket corresponding to the requesting microservice within the single response topic queue, and designating the requesting microservice as a subscriber microservice among the at least one subscriber microservice.

In an embodiment, the cloud server application, via the message broker API described in the context of the method400and related methods, handles message publication and/or subscription with respect to one or more individual client microservices among the plurality of client microservices. In a further embodiment, the cloud server application, via the message broker API described in the context of the method400and related methods, handles messages among the plurality of client microservices that facilitate completion of a set of tasks associated with a workflow. In the context of the various embodiments, a workflow incudes series of tasks, e.g., a chain or sequence of tasks. A workflow is associated with a group of messages sent for purposes of completing the series of tasks. For instance, a workflow in accordance with the various embodiments may be a workflow to determine client eligibility with respect to certain services or benefits, e.g., an insurance client eligibility workflow. A single topic queue, e.g., a single request-response topic queue in accordance with the previously described one or more alternative embodiments, is configured to handle multiple tasks or other aspects associated with a single workflow. Optionally, one client microservice among the plurality of client microservices completes at least one task associated with a workflow and then publishes via the message broker API one or more workflow-related messages to at least one other client microservice among the plurality of client microservices. For instance, a first client microservice among the plurality of client microservices may complete at least one task associated with a workflow and then may publish via the message broker API one or more workflow-related messages to a second client microservice among the plurality of client microservices, the second client microservice may complete at least one additional task associated with the workflow based upon the publication received from the first client microservice and then may publish via the message broker API one or more additional workflow-related messages to a third client microservice among the plurality of client microservices, and so forth.

In an embodiment, the cloud server application, via the message broker API described in the context of the method400and related methods, accommodates at least one dedicated condition handling microservice among the plurality of client microservices configured to distribute messages to other client microservices among the plurality of client microservices based upon one or more conditions associated with a workflow. According to such embodiment, each of the other client microservices is configured to handle a designated set of one or more conditions associated with the workflow. According to such embodiment, the at least one dedicated condition handling microservice among the plurality of client microservices addresses one or more workflow conditions by publishing via the message broker API respective messages to one or more other client microservices based upon the one or more workflow conditions. Optionally, a dedicated condition handling microservice publishes a message to one or more other client microservices based upon satisfaction of one or more designated sets of conditions. For instance, in the context of handling messages based upon conditions of an insurance client eligibility workflow, a first dedicated condition handling microservice among the plurality of client microservices may publish a message to a second microservice among the plurality of client microservices based upon satisfaction of a first set of conditions, e.g., responsive to determining that client age is 25 to 50 and that client salary is less than $100,000, and the first dedicated condition handling microservice may publish a message to a third microservice among the plurality of client microservices based upon satisfaction of a second set of conditions, e.g., responsive to determining that client age is greater than 50 and that client salary is greater than or equal to $100,000, and so forth.

FIG.7illustrates an implementation of message broker API325, according to one or more embodiments. As shown, message broker API325according to the implementation depicted inFIG.7includes a request topic queue710, a message handling microservice720, and a response topic queue730. Response topic queue730includes buckets7401to740ncorresponding to respective subscriber microservices, e.g., among client microservices3601to360n. Request topic queue710is an example implementation of the single request topic queue discussed in the context of the method400and related methods. Response topic queue730is an example implementation of the single response topic queue discussed in the context of the method400and related methods.

FIG.8illustrates an example scenario800involving the implementation of message broker API325as illustrated inFIG.7. As shown inFIG.8, client microservice3601(MS1) and client microservice3602(MS2) both publish to a topic, as indicated by the respective arrows from MS1and MS2to request topic queue710, and subscribe to the topic, as indicated by the arrow from bucket7401within response topic queue730to MS1and as indicated by the arrow from bucket7402within response topic queue730to MS2. Message handling microservice720transfers messages to be published by client microservice3601and client microservice3602from request topic queue710to response topic queue730. One or more transferred messages to be published to MS1are placed in bucket7401within response topic queue730, at which point the one or more transferred messages are available for subscriber microservice MS1. One or more transferred messages to be published to MS2are placed in bucket7402within response topic queue730, at which point the one or more transferred messages are available for subscriber microservice MS2.

As indicated by example scenario800depicted inFIG.8, the implementation of message broker API325illustrates message handling with respect to respective individual client microservices MS1and MS2in accordance with the various embodiments described herein. While client microservices MS1and MS2are depicted as both publisher microservices and subscriber microservices, a client microservice associated with message broker API325optionally is only a publisher microservice and not a subscriber microservice, or conversely a client microservice associated with message broker API325optionally is only a subscriber microservice and not a publisher microservice.

FIG.9illustrates a further implementation of message broker API325, according to one or more embodiments. As shown, message broker API325according to the further implementation depicted inFIG.9includes a request-response topic queue910. Request-response topic queue910includes buckets9201to920ncorresponding to respective subscriber microservices, e.g., among client microservices3601to360n.FIG.9illustrates message broker API325in accordance with one or more alternative embodiments in which the single request topic queue of the message broker API and the single response topic queue of the message broker API as described in the method400and related methods are combined into a single request-response topic queue. Request-response topic queue910is an example implementation of the single request-response topic queue discussed in the context of the one or more alternative embodiments.

FIG.10illustrates an example scenario1000involving the further implementation of message broker API325as illustrated inFIG.9. As shown inFIG.10, client microservice3601(MS1), client microservice3602(MS2), client microservice3603(MS3), and client microservice3604(MS4) each publish and subscribe to a topic. Message publication to the topic by the respective client microservices MS1, MS2, MS3, and MS4are depicted by arrows from the respective client microservices MS1, MS2, MS3, and MS4to request-response topic queue910. Message subscription to the topic by client microservice MS1is depicted by the arrow from bucket9201within request-response topic queue910to MS1. Message subscription to the topic by client microservice MS2is depicted by the arrow from bucket9202within request-response topic queue910to MS2. Message subscription to the topic by client microservice MS3is depicted by the arrow from bucket9203within request-response topic queue910to MS3. Message subscription to the topic by client microservice MS4is depicted by the arrow from bucket9204within request-response topic queue910to MS4.

As indicated by the example scenario1000depicted inFIG.10, the further implementation of message broker API325illustrates message handling with respect to client microservices MS1, MS2, MS3, and MS4that optionally are part of a workflow of client microservices, e.g., an insurance client eligibility workflow. In the context of such particular instance, an authorization identification parameter included in a message associated with the client eligibility workflow optionally corresponds to a microservice configured to handle the message based upon one or more conditions, and accordingly the cloud server application publishes such message to the bucket corresponding to such microservice based upon the authorization identification parameter. As illustrated in the further implementation of message broker API325inFIG.9and the example scenario1000ofFIG.10, there is no message handling microservice between a request topic queue and a response topic queue, since functionality of respective request and response topic queues are combined into request-response topic queue910. Thus, in accordance with the further implementation of message broker API325as illustrated inFIG.9, the cloud server application handles the entirety of a client microservice workflow via request-response topic queue910. According to an embodiment in which there is least one dedicated condition handling microservice, in example scenario1000depicted inFIG.10, MS1optionally is a dedicated condition handling microservice publishing one or more respective messages to other client microservices MS2, MS3, and/or MS4based upon workflow conditions. According to such embodiment, dedicated condition handling microservice MS1may publish a message to microservice MS2based upon satisfaction of a first set of conditions, dedicated condition handling microservice MS1may publish a message to microservice MS3based upon satisfaction of a second set of conditions, and dedicated condition handling microservice MS1may publish a message to microservice MS4based upon satisfaction of a third set of conditions.

The descriptions of the various embodiments have been presented for purposes of illustration but are not intended to be exhaustive or limited to the embodiments disclosed. All kinds of modifications made to the described embodiments and equivalent arrangements should fall within the protected scope of the various embodiments. Hence, the scope should be explained most widely according to the claims that follow in connection with the detailed description and should cover all possibly equivalent variations and equivalent arrangements. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles of the various embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the various embodiments.