Patent Description:
The use of data streaming services has become increasingly prevalent in recent years, as more and more organisations have come to rely on real-time data to drive their business operations. These services typically involve the continuous ingestion of large amounts of data, which is then processed and used to generate insights or drive actions.

However, in an enterprise level application where large teams work independently, the choice of data streaming services (which are also known as "messaging systems" or "messaging platforms"), such as Amazon Managed Kafka and Amazon Kinesis, could differ from one team to another on the basis of use cases, expertise, scalability, etc. For an overall application integration, these data streaming services need to have some mode of interaction established which takes away the complexity around data formats and communication protocols and enable messages to be read reliably.

To illustrate this with an example, consider two systems: system A with Amazon Web Services (AWS) Managed Kafka as its choice of data streaming service, and system B with Amazon Kinesis as its choice of data streaming service. For system B to consume events originating from system A, system B would have to include specific capabilities that are purposed for reading data from the data streaming service implemented by system A - these may conflict with the agreed technical preferences of system B. Moreover, system A may not be able to publish events to system B as it is not its responsibility.

As a result, there is a need for solution that can more effectively facilitate communication between data streaming services. Other prior-art disclosures of data streaming devices can be found in the publication of<NPL>, and in the patent publication <CIT>.

In one aspect of the present disclosure, there is provided a message routing system. The message routing system comprises: a message routing module, a routing configuration module, a first binder module, a second binder module. The routing configuration module is configured to provide a routing configuration for each of one or more content messages, each routing configuration comprising a source of the respective content message and one or more targets for the respective content message, each of the source and the one or more targets being characterised by a channel and an address. The first binder module is configured to connect a first data streaming application to the message routing module using one or more channels, and to enable a content message to be routed to and/or from the first data streaming application. The second binder module is configured to connect a second data streaming application to the message routing module using one or more channels, and to enable a content message to be routed to and/or from the second data streaming application. The first data streaming application is associated with a first cloud-based account and the second data streaming application is associated with a second cloud-based account. The message routing module configured to: receive a content message from a data streaming application and a corresponding routing configuration for the content message from the routing configuration module, and route the content message according to the corresponding routing configuration using a stream bridge interface.

In this way, the message routing system enables data streaming applications to interact with each other in a dynamic manner without requiring specific adapters to be built for the data streaming applications. Advantageously, the message routing system improves the interoperability of data streaming applications and makes it easier for organisations to integrate cross-account event interaction between systems. Also, the use of routing configurations allows content messages to be routed between data streaming applications in a configurable and flexible way.

In some embodiments, an address characterising a source or a target may designate a content message stream at a corresponding data streaming application.

In this way, the address contained in a routing configuration can specify a particular content stream at a respective data streaming application from which a content message is to be routed or to which a content message is to be routed.

In some embodiments, the message routing module may be further configured to: determine that the content message has been delivered; and upon determining that the content message has been delivered, send an acknowledgement to the respective data streaming application specified as the source in the corresponding routing configuration, so as to trigger data offset to be committed with respect to the delivered content message at the respective data streaming application.

In this way, the message routing system can minimise data loss by ensuring data offset is only committed upon successful delivery of the content message.

In some embodiments, the first data streaming application may be selected from a list including: Amazon Managed Streaming for AWS Managed Kafka, Amazon Kinesis, Rabbit MQ, Amazon Simple Notification Service, Amazon Simple Queue Service, and Apache RocketMQ, and the second data streaming application may be another data streaming application selected from the list.

In some embodiments, the message routing system may be deployed on a consumer domain.

In this way, a consumer on the consumer domain is provided with the capability to read content messages from a producer system.

In some embodiments, the message routing system may further comprise a secrets manager module configured to rotate one or more secrets associated with at least one of the first and second data streaming applications based on a predetermined configuration.

In this way, the message routing system can reduce the risk of unauthorised access to the data streaming applications and ensure that data streaming applications are using the most current credentials.

In some embodiments, at least one of the first and second binder modules may comprise a health endpoint configured to: acquire one or more health status parameters of the respective data streaming application, wherein the one or more health status parameters comprises a secrets rotation parameter indicating whether a secret associated with the respective data streaming application is rotated; and restart the respective data streaming application if at least one of one or more health status parameters does not meet a predetermined criterion.

In this way, the message routing system can ensure that respective data streaming applications are functioning properly and that issues (e.g. relating to secrets management) that may affect the performance or stability of the data streaming applications are minimised.

In some embodiments, the message routing module may be configured to receive the content message by pulling the content message from the respective data streaming application.

In this way, the message routing system can ensure that the content messages to be routed from a respective data streaming application are properly retrieved from said data streaming application.

In some embodiments, the routing configuration for a content message may comprise a source of the respective content message and a plurality of targets for the respective content message.

In this way, the message routing system provides the capability of allowing a content message to be routed to multiple targets (e.g. multiple content message streams).

In some embodiments, the message routing system may further comprise a metrics monitoring module configured to determine at least one of a number of content messages received from one of the first data streaming application and the second data streaming application that have been successfully delivered and a number of content messages received from one of the first data streaming application and the second data streaming application that failed to be delivered.

In this way, the message routing system can provide useful metrics that enable the performance and the behaviour of the message routing system (and/or data streaming applications) to be tracked and monitored.

In another aspect of the present disclosure, there is provided a computer-implemented method for operating a message routing system. The message routing system comprises a message routing module, a routing configuration module, a first binder module configured to connect a first data streaming application to the message routing module using one or more channels, the first binder module being configured to enable a content message to be routed to and/or from the first data streaming application, and a second binder module configured to connect a second data streaming application to the message routing module using one or more channels, the second binder module being configured to enable a content message to be routed to and/or from the first data streaming application. The method comprises: providing, by the routing configuration module, a routing configuration for each of one or more content messages, each routing configuration comprising a source of the respective content message and one or more targets for the respective content message, and wherein each of the source and the one or more targets is characterised by a channel and an address; receiving, at the message routing module, a content message from one of a first data streaming application and a second data streaming application, and a corresponding routing configuration for the content message from the routing configuration module; and routing, by the message routing module, the content message according to the corresponding routing configuration using a stream bridge interface. The first data streaming application is associated with a first cloud-based account and the second data streaming application is associated with a second cloud-based account.

The method enables data streaming applications to interact with each other in a dynamic manner without requiring specific adapters to be built for the data streaming applications. Advantageously, the method improves the interoperability of data streaming applications and makes it easier for organisations to integrate cross-account event interaction between systems. Also, the use of routing configurations in the method allows content messages to be routed between data streaming applications in a configurable and flexible way.

In some embodiments, the method may further comprise: determining, by the message routing module, that the content message has been delivered; and upon determining that the content message has been delivered, sending, by the message routing module, an acknowledgement to the respective data streaming application specified as the source in the corresponding routing configuration, so as to trigger data offset to be committed with respect to the delivered content message at the respective data streaming application.

In some embodiments, at least one of the first and second binder modules may comprise a health endpoint, and in these embodiments the method may further comprise: acquiring, by a health endpoint of a binder module, one or more health status parameters of the respective data streaming application, wherein the one or more health status parameters comprises a secrets rotation parameter indicating whether a secret associated with the respective data streaming application is rotated; and restarting the respective data streaming application if at least one of one or more health status parameters does not meet a predetermined criterion.

In some embodiments, the message routing system may further comprise a secrets manager module, and in these embodiments the method may further comprise rotating, by the secrets manager module, one or more secrets associated with at least one of the first and second data streaming applications based on a predetermined configuration.

In some embodiments, receiving the content message at the message routing module may comprise pulling the content message from the respective data streaming application.

In some embodiments, the message routing system may further comprise a metrics monitoring module, and in these embodiments the method may further comprise determining, by the metrics monitoring module, at least one of a number of content messages received from one of the first data streaming application and the second data streaming application that have been successfully delivered and a number of content messages received from one of the first data streaming application and the second data streaming application that failed to be delivered.

In another aspect of the present disclosure, there is provided a cloud computing environment system comprising the message routing system as described herein.

In another aspect of the present disclosure, there is provided computer hardware configured to implement the message routing system as described herein, the method as described herein, or the cloud computing environment system as described herein.

The present disclosure is described with reference to the accompanying figures, in which:.

The present invention is described in detail below by way of example only.

The proposed message routing system is designed to address the need to enable data streaming services (herein referred to as "data streaming applications") to interact with each other in an event-driven fashion by providing a flexible mechanism for routing content messages between systems and/or domains without requiring additional adapters. This message routing system replaces the need to build point-to-point architecture as it can be implemented as a component at the integration layer outside the core of the system domain, where business logic is implemented, and achieve separation of concerns between the core processing and the interaction. Furthermore, the message routing system may be available as a service catalogue product.

The proposed message routing system relies on the use of routing configurations for content messages which follow a format to dictate how content messages should be routed, thus providing an enhanced level of configurable dynamic routing and eliminating the need for developers to developer specific adapters for producing and consuming events. Overall, the proposed message routing system can significantly improve the interoperability of data streaming applications, making it easier for organisations to integrate relevant systems for any cross-account event interaction.

<FIG> is a block diagram of a message routing system according to the present disclosure. As shown in the diagram, the message routing system <NUM> comprises a message routing module <NUM>, a routing configuration module <NUM>, a first binder module <NUM>, a second binder module <NUM>, a stream bridge interface <NUM>, a secrets manager module <NUM>, and a metrics monitoring module <NUM>.

Also, as shown in <FIG>, external to the message routing system <NUM>, there is provided a first data streaming application DSA1 and a second data streaming application DSA2. The first data streaming application DSA1 is associated with a first cloud-based account, and the second data streaming application DSA2 is associated with a second cloud-based account. The first and second cloud-based accounts may be hosted on a third-party cloud environment such as Amazon Web Services (AWS). In some embodiments, the first and second cloud-based accounts may be different accounts.

The first data streaming application DSA1 may be selected from a list including: Amazon Managed Streaming for AWS Managed Kafka, Amazon Kinesis, Rabbit MQ, Amazon Simple Notification Service, Amazon Simple Queue Service, and Apache RocketMQ. The second data streaming application DSA2 may be another data streaming application selected from the same list. For example, the first data streaming application DSA1 may be AWS Managed Kafka, and the second data streaming application DSA2 may be Amazon Kinesis. Since the underlying framework for the message routing system <NUM> (as explained in more detail in below) supports data streaming applications including Amazon Simple Notification Service, Amazon Simple Queue Service, and Apache Rabbit MQ, the message routing system <NUM> can be extended not listed herein by implementing specific binder modules.

In the present embodiment, the message routing system <NUM> relies on Spring Cloud Stream which is a framework for building scalable event-driven services connected with shared messaging systems (or "data streaming applications"). Spring Cloud Stream is built on top of Spring Integration, which is a framework that provides an extension to the Spring Framework that enables the integration of an application with external systems by providing a set of components that can be used to connect different systems together and allows for the exchange of data between those systems. Spring Integration supports the Enterprise Integration Patterns, which are a set of patterns that describe how to design and implement the integration of systems. Spring Cloud Stream relies on the use of channels - as explained in further detail below, binder modules of the message routing system use channels (i.e. data pipes) to connect data streaming applications to the message routing module <NUM> of the message routing system <NUM>. As also will be explained in further detail below, a channel can be designated in a routing configuration of a content message so that the content message can be routed via the designated channel accordingly.

The binder abstraction enables a Spring Cloud Stream application to be flexible in how it connects to any middleware. In the present embodiment, a binder module is a component that provides services to connect with a data streaming application and can provide inbound and outbound adapters to connect to message streams at the data streaming application. Messages are received from inbound adapters and sent using the outbound adapters. Multiple binder modules can be provided for multiple data streaming applications, and each binder module generates different channels for communication between producers and consumer of events.

In the present embodiment, the first binder module <NUM> is configured to connect the first data streaming application DSA1 to the message routing module <NUM> using one or more channels, and to enable a content message to be routed to and/or from the first data streaming application DSA1. If the first data streaming application DSA1 is AWS Managed Kafka, then the first binder module would be a Kafka binder. If the first data streaming application is Amazon Kinesis, then the first binder module would be a Kinesis binder. Similarly, the second binder module <NUM> is configured to connect the second data streaming application DSA2 to the message routing module <NUM> using one or more channels, and to enable a content message to be routed to and/or from the second data streaming application DSA2.

For the first and second binder modules <NUM>, <NUM>, inbound consumer channels may have names or identifiers such as "kafka-in-<NUM>" (for AWS Managed Kafka) and "kinesis-in-<NUM>" (for Amazon Kinesis). Similarly, outbound producer channels may have names or identifiers such as "kafka-out-<NUM>"(for AWS Managed Kafka) and "kinesis-out-<NUM>" (for Amazon Kinesis). These name or identifiers may be used in routing configurations to designate the corresponding channels.

The routing configuration module <NUM> is configured to provide a routing configuration for each of one or more content messages. Each routing configuration comprises a source of the respective content message and one or more targets for the respective content message. Each of the source and the one or more targets is characterised by a channel and an address. In some embodiments, the routing configuration for a content message may comprise a source of the respective content message and a plurality of targets for the respective content message. This means that the content message is to be routed to multiple content message streams at the receiving data streaming application.

Furthermore, an address characterising a source or a target may designate a content message stream at a corresponding data streaming application. For example, if the first data streaming application DSA1 is AWS Managed Kafka and the content message is from the first data streaming application, an address characterising the source in a routing configuration corresponding this content message may designate a particular Kafka topic at the first data streaming application DSA1. As another example, if the second data streaming application DSA2 is Amazon Kinesis and the content message is to be routed to the second data streaming application DSA2, an address characterising the target in a routing configuration corresponding to this content message may designate a particular Amazon Kinesis stream at the second data streaming application DSA2.

An example of a routing configuration (or at least a portion of it) for a content message that is to be routed from AWS Managed Kafka to both Amazon Kinesis and AWS Managed Kafka is provided below:
<IMG>
<IMG>.

In this example, the routing configuration comprises one source and two targets. The source is characterised by the channel "kafka-in-<NUM>" (designating a specific inbound channel at Kafka) and the address "kafka-topic-<NUM>" (designating a specific Kafka topic). The first target is characterised by the channel "kinesis-out-<NUM>" (designating a specific outbound channel at Amazon Kinesis) and the address "kinesis-target-stream" (designating a specific Kinesis stream by its name). The second target is characterised by the channel "kafka-out-<NUM>" (designating a specific outbound channel at Kafka) and the address "kafka-topic-<NUM>" (designating a specific Kafka topic).

Another example of a routing configuration (or a portion of it) for a content message that is to be routed from Amazon Kinesis to Amazon Kinesis is provided below:
<IMG>.

In this example, the routing configuration comprises one source and one target. The source is characterised by the channel "kinesis-in-<NUM>" (designating a specific inbound channel at Amazon Kinesis) and the address "kinesis-source-stream" (designating a specific Kinesis stream by name). The target is characterised by the channel "kinesis-out-<NUM>" (designating a specific outbound channel at Amazon Kinesis) and the address "kinesis-target-stream" (designating a specific Kinesis stream by name).

It will be appreciated although in the examples of routing configurations provided above the sources and the targets are each characterised by an "address", in alternative embodiments, routing configurations may use other terms, such as "destination", in lieu of "address" to designate the content message stream at a corresponding data stream application.

The message routing module <NUM> configured to receive a content message from a data streaming application (i.e. the first data streaming application DSA1 or the second data streaming application DSA2) and a corresponding routing configuration for the content message from the routing configuration module <NUM>. In some embodiments, the message routing module <NUM> may be configured to receive the content message by pulling the content message from the respective data streaming application. The message routing module <NUM> is further configured to route the content message according to the corresponding routing configuration using the stream bridge interface <NUM>. The stream bridge interface <NUM> is a component that allow content messages to be routed from one data streaming application to another by enabling content messages to be directly sent to output channels of binder modules.

The message routing module <NUM> may be further configured to determine that the content message has been delivered, and upon determining that the content message has been delivered, to send an acknowledgement to the respective data streaming application specified as the source in the corresponding routing configuration, so as to trigger data offset to be committed with respect to the delivered content message at the respective data streaming application. This data offset may be committed with respect to a corresponding partition at the data streaming application. The content messages may be read using the TRIM_HORIZON policy, which means that data streaming is performed starting from the oldest data record in the respective data sequence. Therefore, by triggering data offset commit only upon receiving an acknowledgement that the content message has been delivered, the message routing module <NUM> can guarantee delivery of content messages and ensure that there is no data loss when events (represented by content messages) from one cloud-based account flows into another cloud-based account. In some embodiments, in case of delivery failure, the content message may remain in the message queue. Also, the message routing module <NUM> may be configured to perform a configurable number of delivery retries (i.e. of routing the content message).

The secrets manager module <NUM> is configured to rotate one or more secrets associated with at least one of the first and second data streaming applications DSA1, DSA2 based on a predetermined configuration. Although <FIG> shows the secrets manager module <NUM> as a component of the message routing system <NUM>, it is possible that in alternative embodiments the message routing system <NUM> may not comprise a secrets manager module. In these alternative embodiments, a secrets manager module may be implemented as a component external to the message routing system <NUM>.

In some embodiments, at least one of the first and second binder modules <NUM>, <NUM> may comprise a health endpoint. The health endpoint may be configured to acquire one or more health status parameters of the respective data streaming application, the one or more health status parameters comprising a secrets rotation parameter indicating whether a secret associated with the respective data streaming application is rotated. The health endpoint may be further configured to restart the respective data streaming application if at least one of one or more health status parameters does not meet a predetermined criterion. The secrets rotation parameter may be acquired from the secrets manager module <NUM>, or in the case where a secrets manager module is implemented as a component external to the message routing system, from said external secrets manager module.

The metrics monitoring module <NUM> is configured to determine at least one of a number of content messages received from one of the first data streaming application DSA1 and the second data streaming application DSA2 that have been successfully delivered, and a number of content messages received from one of the first data streaming application DSA1 and the second data streaming application DSA2 that failed to be delivered. In some embodiments, the metrics monitoring module <NUM> may be further configured to determine at the number of content messages that is received by at least one of the first and second data streaming applications.

Although <FIG> shows the metrics monitoring module <NUM> as a component of the message routing system <NUM>, it is possible that in alternative embodiments the message routing system <NUM> may not comprise a metrics monitoring module <NUM>. In these alternative embodiments, a metrics monitoring module may be implemented as a component external to the message routing system <NUM>.

In some embodiments, the message routing system <NUM> may be deployed on a consumer domain. This provides the consumer with the capability to read from the producer system, which typically it is not capable of doing.

It will be appreciated that in some embodiments the message routing system <NUM> may comprise additional components that are not illustrated in <FIG>. For example, the message routing system <NUM> may further comprise a login module configure to authenticate and authorise clients that connect to a data streaming application. This login module is explained in further detail with reference to <FIG>.

<FIG> is a flow diagram of a method for operating a message routing system, for example message routing system <NUM>, according to the present disclosure. For ease of illustration, the steps of method <NUM> will be described herein with reference to the various components of the message routing system <NUM> as shown in <FIG>.

The computer-implemented method <NUM> begins with step <NUM> at which a routing configuration for each of one or more content messages is provided by the routing configuration module <NUM> of the message routing system <NUM>. Each routing configuration comprises a source of the respective content message and one or more targets for the respective content message, and each of the source and the one or more targets is characterised by a channel and an address. An address characterising a source or a target may designate a content message stream at a corresponding data streaming application.

As mentioned above, in some embodiments a routing configuration may comprise more than one targets for a content message, thus enabling a content message to be routed to multiple destination content message streams.

Then, at step <NUM>, a content message is received at the message routing module <NUM> from one of the first data streaming application <NUM> and the second data streaming application <NUM>. In some embodiments, the content message may be pulled by the message routing module <NUM> from the respective data streaming application. A corresponding routing configuration for the content message is also received from the routing configuration module <NUM> at step <NUM>.

Subsequently, at step <NUM> the content message is routed by the message routing module <NUM> according to the corresponding routing configuration using the stream bridge interface <NUM>.

Although not illustrated in <FIG>, the method <NUM> may further comprise an optional step at which the message routing module <NUM> determines that the content message has been delivered, and a further optional step at which an acknowledgement is sent by the message routing module <NUM> to the respective data streaming application specified as the source in the corresponding routing configuration upon determining that the content message has been delivered, so as to trigger data offset to be committed with respect to the delivered content message at the respective data streaming application. Moreover, in some embodiments, the method may further comprise performing, by the message routing module <NUM>, a configurable number of delivery retries in case of a delivery failure of a content message.

As mentioned above with respect to <FIG>, in some embodiments at least one of the first and second binder modules <NUM>, <NUM> of the message routing system <NUM> comprises a health endpoint. In these embodiments, the method <NUM> may further comprise an optional step at which one or more health status parameters of the respective data streaming application are acquired by a health endpoint of a binder module, and a further optional step at which the respective data streaming application is restarted if at least one of one or more health status parameters does not meet a predetermined criterion. In these embodiments, the one or more health status parameters may comprise a secrets rotation parameter which indicates whether a secret associated with the respective data streaming application is rotated.

As mentioned above with respect to <FIG>, in some embodiments the message routing system <NUM> may further comprise a metrics monitoring module <NUM>. In these embodiments, the method <NUM> may further comprise determining, by the metrics monitoring module <NUM>, at least one of: a number of content messages received from one of the first data streaming application and the second data streaming application that have been successfully delivered and a number of content messages received from one of the first data streaming application and the second data streaming application that failed to be delivered. Furthermore, in some embodiments, the method may further comprise determining, by the metrics monitoring module <NUM>, the number of content messages that is received by at least one of the first and second data streaming applications.

It will be appreciated that the method described with reference to <FIG> has been shown as individual steps carried out in a specific order. However, the skilled person will appreciate that these steps may be combined or carried out in a different order whilst still achieving the desired result. Also, the skilled person will appreciate that the steps that are described as optional may be omitted whilst still achieving the desired result.

<FIG> is an exemplary computer architecture diagram of a message routing system according to the present disclosure. The message routing system <NUM> of <FIG> represents a specific example of the message routing system <NUM> of <FIG>, where the first data streaming application is AWS Managed Kafka, and the second data streaming application is Amazon Kinesis. The architecture diagram of <FIG> illustrates in more detail the possible connections and interrelationships between some of the components of a message routing system according to embodiments of the present disclosure.

In the present embodiment, the message routing system <NUM> comprises a message routing module <NUM> (which can be referred to as a "message router"), a routing configuration module <NUM> (which can be referred to as a "routing service"), a first binder module <NUM> corresponding to AWS Managed Kafka, a second binder module <NUM> corresponding to Amazon Kinesis, a login module <NUM>, a stream bridge interface <NUM>, a secrets manager module <NUM>, and a system manager module <NUM>. External to the message routing system <NUM>, there is provided the first data streaming application, i.e. AWS Managed Kafka, and the second data streaming application, i.e. Amazon Kinesis. There is also provided externally an external secret manager module <NUM> and a parameter store <NUM>.

As shown in <FIG>, the first binder module <NUM> is connected to the first data streaming application <NUM> and to the message routing module <NUM>, thus enabling communication between these two components. The first binder module <NUM> comprises a first inbound adapter 331A and a first outbound adapter 331B, the first inbound adapter 331A being configured to connect the first data streaming application <NUM> to a first inbound channel <NUM>. Furthermore, the first inbound channel <NUM> is configured to enable content messages that have been received from the first data streaming application <NUM> via the first inbound adapter 331A to be routed towards a first message endpoint stream listener <NUM> (which is configured to listen for and process content messages) and the router channel <NUM> before reaching the message routing module <NUM>. In a similar fashion, the first outbound adapter 331B is configured to connect the first data streaming application <NUM> to the first outbound channel <NUM>, the first outbound channel <NUM> being configured to enable content messages from the message routing module <NUM> that have passed the stream bridge interface <NUM> to be routed to the first data streaming application <NUM> via the first outbound adapter 331B.

The second binder module <NUM> is connected to the second data streaming application <NUM> and to the message routing module <NUM>, thus enabling communication between these two components. The second binder module <NUM> comprises a second inbound adapter 341A and a second outbound adapter 341B, the second inbound adapter 341A being configured to connect the second data streaming application <NUM> to a second inbound channel <NUM>. Furthermore, the second inbound channel <NUM> is configured to enable content messages that have been received from the second data streaming application <NUM> via the second inbound adapter 341A to be routed towards a second message endpoint stream listener <NUM> (which is configured to listen for and process content messages) before reaching the message routing module <NUM>. Similarly, the second outbound adapter 341B is configured to connect the second data streaming application <NUM> to the second outbound channel <NUM>, the second outbound channel <NUM> being configured to enable content messages from the message routing module <NUM> that have passed the stream bridge interface <NUM> to be routed to the second data streaming application <NUM> via the second outbound adapter 341B.

As mentioned above, the message routing module <NUM> receives content messages from the first and second data streaming applications <NUM>, <NUM> via the first and second inbound channels <NUM>, and <NUM>. The message routing module <NUM> also receives routing configurations corresponding to these content messages from the routing configuration module <NUM>. Therefore, the message routing module can route these content messages according to corresponding routing configurations, using the stream bridge interface <NUM>.

In this example, the routing configuration module <NUM> is connected to a system manager module <NUM>. The system manager module <NUM> may be configured to monitor and record/publish routing configurations provided by the routing configuration module 320and/or to provide notifications related to changes in routing configurations provided by the routing configuration module <NUM>. The system manager module <NUM> may be, for example, an Amazon Web Services (AWS) System Manager (SSM) Service. The system manager module <NUM> is further connected to a parameter store <NUM>, which may be configured to store routing configurations (and data associated with the routing configurations). The parameter store <NUM> may be, for example, an AWS SSM Parameter Store. The routing configuration module <NUM> is configured to retrieve routing configuration(s) from the parameter store <NUM> using the system manager module <NUM>.

Moreover, in this example, there is provided a login module <NUM> connected to the first binder module <NUM>. The login module <NUM> is configured to authenticate and authorise clients that connect to the first data streaming application <NUM> (which is AWS Managed Kafka, in this case). In some embodiments, the login module <NUM> may include a Simple Authentication Security Layer (SASL), which is a framework that provides mechanisms for authentication and allows applications to securely exchange data. One of these mechanisms may be Salted Challenge Response Authentication Mechanism (SCRAM), which is a challenge-response mechanism which requires a client to provide a response to a challenge to prove its identity. SASL and SCRAM may use usernames and passwords. These credentials may be created during installation. In some embodiments, one or more passwords for the first data streaming application <NUM> may be generated and stored in the secrets manager module <NUM>. The login module <NUM> is further connected to a secrets manager module <NUM>, which in turn is connected to an external secrets manager module <NUM>. In this embodiment, the secrets manager module <NUM> and the external secrets manager module <NUM> may be collectively configured to rotate one or more secrets associated with the first data streaming application <NUM> based on a predetermined configuration. The secrets may include sensitive data and/or credentials such as usernames and passwords.

The arrangement shown in <FIG> provides an advantage over existing cross-account communication techniques between AWS Managed Kafka and Amazon Kinesis (e.g. Kinesis Connector by Confluent) since it does not require deployment of the connector/message routing system on the producer side. This advantage is particularly relevant in Event Driven Architecture and Domain-Driven Design (DDD), in which the work of the producer is considered complete when it has published the event in its messaging queue.

<FIG> is a schematic illustrating an example of deployment of a message routing system according to the present disclosure. As shown in <FIG>, there is provided a producer system <NUM> and a consumer system <NUM>, both systems being deployed on a third-party cloud environment, which in this example is an Amazon Web Services (AWS) Cloud.

The producer system <NUM> includes a first region <NUM>, which corresponds to a physical location where AWS has one or more data centres. The first region <NUM> further includes a first availability zone <NUM> which corresponds to a physically isolated location within the first region <NUM>. AWS Managed Kafka <NUM> is hosted within the first availability zone <NUM> for streaming data and processing events.

The consumer system <NUM> includes a second region <NUM>, which corresponds to a physical location where AWS has one or more data centres. The second region may be the same region as the first region <NUM> or it may be a different region. The second region <NUM> further includes a second availability zone <NUM> which corresponds to a physically isolated location with the second region <NUM>. The second availability zone <NUM> may be the same as the first availability zone <NUM> or it may be a different availability zone. Within the second availability zone <NUM>, Amazon Kinesis <NUM> is hosted within a core domain <NUM> of the first availability zone <NUM> along with an events listener module <NUM> (which may be an Amazon Lambda service). Furthermore, a message routing module <NUM> is deployed. The message routing system <NUM> in this example may be an embodiment of the message routing system <NUM> as described with reference to <FIG>, and is thus capable of performing all the functionalities of the message routing system <NUM>. More specifically, at least in this example, the message routing system <NUM> is configured to receive ("listens") content messages from AWS Managed Kafka <NUM> hosted in the producer system <NUM> and route ("produces") these content messages towards Amazon Kinesis <NUM> hosted in the consumer system <NUM>. These content messages may in turn trigger code execution at the events listener module <NUM> in response to the received content messages (which may be referred to as "events" in this context).

Although <FIG> only shows the first availability zone <NUM> and the second availability zone <NUM>, it will be appreciated that depending on the resiliency requirements of the consumer system <NUM>, additional availability zones may be provided so as to implement the deployment of the message routing system <NUM> in each availability zone.

Similar to the arrangement shown in <FIG>, the producer system <NUM> in <FIG> includes a first region <NUM>, which corresponds to a physical location where AWS has one or more data centres. The first region <NUM> further includes a first availability zone <NUM> which corresponds to a physically isolated location within the first region <NUM>. A first Amazon Kinesis <NUM> is hosted within the first availability zone <NUM> for streaming data and processing events.

The consumer system <NUM> includes a second region <NUM>, which may be the same region as the first region <NUM> or it may be a different region. The second region <NUM> further includes a second availability zone <NUM> which corresponds to a physically isolated location with the second region <NUM>. The second availability zone <NUM> may be the same as the first availability zone <NUM> or it may be a different availability zone. Within the second availability zone <NUM>, a second Amazon Kinesis <NUM> is hosted within a core domain <NUM> of the first availability zone <NUM> along with an events listener module <NUM> (which may be an Amazon Lambda service). Furthermore, a message routing module <NUM> is deployed. The message routing system <NUM> in this example may be an embodiment of the message routing system <NUM> as described with reference to <FIG>, and is thus capable of performing all the functionalities of the message routing system <NUM>. More specifically, at least in this example, the message routing system <NUM> is configured to receive ("listens") content messages from the first Amazon Kinesis <NUM> hosted in the producer system <NUM> and route ("produces") these content messages towards Amazon Kinesis <NUM> hosted in the consumer system <NUM>. These content messages may in turn trigger code execution at the events listener module <NUM> in response to the received content messages (which may be referred to as "events" in this context).

<FIG> is a schematic illustrating another example of deployment of a message routing system according to the present disclosure. As shown in <FIG>, there is provided a producer system AWS account <NUM> and a consumer system AWS account <NUM>. The producer system AWS account <NUM> comprises a first virtual private cloud (VPC) <NUM> on which AWS Managed Kafka <NUM> is hosted. Furthermore, there is also provided an AWS secrets manager <NUM> at the producer system AWS account <NUM>.

The consumer system AWS account <NUM> comprises a second VPC <NUM> on which a message routing system <NUM> and an events listener module <NUM> are hosted. Also, at the consumer system AWS account <NUM>, there is provided Amazon Kinesis <NUM>, an identity and access (IAM) role <NUM>, and a parameter store <NUM>. The message routing system <NUM> in this example may be an embodiment of the message routing system <NUM> as described with reference to <FIG>, and is thus capable of performing all the functionalities of the message routing system <NUM>.

In more detail, the message routing system <NUM> is configured to communicate content messages from AWS Managed Kafka <NUM> hosted in the producer system AWS account <NUM> and route these content messages towards Amazon Kinesis <NUM> hosted in the consumer system AWS account <NUM>. The message routing system <NUM> is also configured to communicate content messages from Amazon Kinesis <NUM> hosted in the PPE domain AWS account <NUM> and route these content messages towards AWS Managed Kafka <NUM> hosted in the producer system AWS account <NUM>. The routing of content messages is represented by a double-headed arrow between an icon within AWS Managed Kafka <NUM> (designating a specific Kafka topic) and the message routing system <NUM> and an arrow between the message routing system <NUM> and Amazon Kinesis <NUM>.

Each content message to be routed has a corresponding routing configuration that is provided by the parameter store <NUM>, and a message routing module (not shown in <FIG>) of the message routing system <NUM> can route the respective content message according to the source and the target specified in the corresponding routing configuration provided by the parameter store <NUM>. Content messages received at Amazon Kinesis <NUM> can trigger code execution at the events listener module <NUM> in response to the events represented by the content messages.

At the producer system AWS account <NUM>, the AWS secrets manager <NUM> can store a secret (e.g. credentials) associated with AWS Managed Kafka <NUM> and to provide said secret to the IAM role <NUM> at the consumer system AWS account <NUM>. The IAM role <NUM> is configured to receive secrets from the AWS secrets manager <NUM> and to control access to the message routing system <NUM> on the basis of the received secrets. In some embodiments, the AWS secrets manager <NUM> may support the use of SCRAM for authenticating users/clients.

<FIG> is a schematic illustrating another example of deployment of a message routing system according to the present disclosure. The deployment arrangement of <FIG> is similar to that illustrated in <FIG>, with the main difference being that the arrangement of <FIG> involves the deployment of a message routing system between Amazon Kinesis at the consumer domain and Amazon Kinesis at the PPE domain, while <FIG> involves the deployment of a message routing system between AWS Managed Kafka and Amazon Kinesis.

As shown in <FIG>, there is provided a producer system AWS account <NUM> and a consumer system AWS account <NUM>. The producer system AWS account <NUM> comprises a first VPC <NUM> on which a first Amazon Kinesis <NUM> is hosted. The consumer system AWS account <NUM> comprises a second VPC <NUM> on which a message routing system <NUM> and an events listener module <NUM> are hosted. Also, at the consumer system AWS account <NUM>, there is provided a second Amazon Kinesis <NUM>, a parameter store <NUM>, and an IAM role <NUM>.

The message routing system <NUM> in this example may be an embodiment of the message routing system <NUM> as described with reference to <FIG>, and is thus capable of performing all the functionalities of the message routing system <NUM>. In more detail, the message routing system <NUM> is configured to communicate content messages from the first Amazon Kinesis <NUM> hosted in the producer system AWS account <NUM> and route these content messages towards the second Amazon Kinesis <NUM> hosted in the consumer system AWS account <NUM>. The message routing system <NUM> is also configured to communicate content messages from the second Amazon Kinesis <NUM> hosted in the consumer system AWS account <NUM> and route these content messages towards the first Amazon Kinesis <NUM> hosted in the producer system AWS account <NUM>. The routing of content messages is represented by a double-headed arrow between the first Amazon Kinesis <NUM> and the message routing system <NUM> and an arrow between the message routing system <NUM> and the second Amazon Kinesis <NUM>. The IAM role <NUM> at the consumer system AWS account <NUM> is configured to control access to the message routing system <NUM> by granting permission based on a defined set of permissions policies.

Each content message to be routed has a corresponding routing configuration that is provided by the parameter store <NUM>, and a message routing module (not shown in <FIG>) of the message routing system <NUM> can route the respective content message according to the source and the target specified in the corresponding routing configuration provided the parameter store <NUM>. Content messages received at the second Amazon Kinesis <NUM> can trigger code execution at the events listener module <NUM> in response to the events represented by the content messages.

<FIG> are schematics illustrating various aspects of a cloud computing environment system that may comprise the message routing system as described herein, and computer hardware that is configured to implement the cloud computing environment system, the message routing system as described herein, of the methods described herein.

<FIG> is a schematic illustrating an exemplary system for implementing a method of the invention. As shown in <FIG>, cloud environment <NUM> is communicatively coupled via communication network <NUM> to secure provider <NUM>, one or more users <NUM>, and one or more external providers <NUM>. In some embodiments, communication network <NUM> may be implemented or facilitated using one or more local or wide-area communications networks, such as the Internet, WiFi networks, WiMax networks, and the like. Generally, the Internet is used. Preferably, communication network <NUM> may utilise encryption (e.g., Secure Sockets Layer) to secure data being transferred over the communication network <NUM> to the cloud environment <NUM>.

Cloud environment <NUM> is owned and maintained by a third party, i.e. a party that is not the secure provider <NUM>, not one of the one or more users <NUM>, and not one of the external providers <NUM>. Accordingly, cloud environment <NUM> may be referred to as "a third-party cloud environment". Examples of third-party cloud environments include Amazon Web Services (AWS), Google Cloud Platform, and IMB Cloud. By connecting to a multitude of users <NUM>, cloud environment <NUM> is able to benefit from economies of scale, thereby making processing and storing large quantities of data in cloud environment <NUM> efficient.

Typically, cloud environment <NUM> hosts computer executable code <NUM> (not shown) which is executed in the cloud environment <NUM> in response to a request from user <NUM>. Execution of the computer executable code <NUM> causes data to be processed, and the output data produced by executing the computer executable code <NUM> is available for user <NUM> to access. In this way, the computer resources required for data processing are outsourced from the user to the cloud environment <NUM>. This is advantageous because it means that user <NUM> does not have to provision and maintain their own physical computer hardware. Moreover, user <NUM> can send the request from anywhere, as long as they have connection to cloud environment <NUM> via communication network <NUM>. Since the communication network <NUM> is typically the Internet, which is ubiquitous, the accessibility of cloud environment <NUM> to user <NUM> is extremely high. This is convenient as user <NUM> does not have to be physically present at a particular location in order to access cloud environment <NUM>. User <NUM> of the cloud environment <NUM> may additionally or alternatively develop computer executable code <NUM> for execution in the cloud environment <NUM>. User <NUM> can access computer executable code <NUM> in cloud environment <NUM> through a web browser or any other appropriate client application residing on a client computer.

When executed, computer executable code <NUM> may process data or use data. This data is made available to the cloud environment <NUM> by including particular services in the computer executable code <NUM> such as access to REST (Representational State Transfer) APIs (Application Programming Interface) or similar communication protocols. REST APIs work by making HTTP requests to GET, PUT, POST and DELETE data. Thus, when the computer executable code <NUM> makes a request for data, it may do so by making a HTTP GET request to the data source. Such services (and therefore data) may be provided either internally within the cloud environment <NUM>, or externally by one or more external providers <NUM>.

Secure provider <NUM> is a special type of user <NUM> which is not only able to interact with cloud environment <NUM> in the same way as user <NUM> (i.e. send requests to cause computer executable code <NUM> to be executed in the cloud environment <NUM>, and develop computer executable code <NUM> to be executed in the cloud environment <NUM>), but is also able to provide services (and therefore data) to the cloud environment <NUM>. Accordingly, the secure provider <NUM> may be thought of as a hybrid user/external provider. Secure provider <NUM> has additional security provisions over user <NUM> and external providers <NUM> because data provided by the secure provider <NUM> may be protected data and/or the computer executable code developed by the secure provider <NUM> may be protected.

<FIG> shows an exemplary third-party cloud environment <NUM> for implementing a method of the invention. As seen in <FIG>, cloud environment <NUM> comprises cloud environment hardware <NUM> that can be invoked to instantiate data processing, data storage, or other computer resources using cloud computing hardware <NUM> for a limited or defined duration. Cloud environment hardware <NUM> may comprise one or more servers <NUM><NUM> to <NUM>n, and a storage array network <NUM>, as well as any other suitable hardware. Cloud environment hardware <NUM> may be configured to provide a virtualisation environment <NUM> that supports the execution of a plurality of virtual machines <NUM> (not shown) across the one or more servers <NUM><NUM> to <NUM>n. As described in relation to <FIG>, the plurality of virtual machines <NUM> provide various services and functions for cloud environment <NUM>.

Virtualisation environment <NUM> of <FIG> may include orchestration component <NUM> that monitors the cloud environment hardware <NUM> resource consumption levels and the requirements of cloud environment <NUM> (e.g., by monitoring communications routed through addressing and discovery layer <NUM>), and provides additional cloud environment hardware <NUM> to cloud environment <NUM> as needed. For example, if cloud environment <NUM> requires additional virtual machines <NUM> to host new computer executable code <NUM>, orchestration component <NUM> can initiate and manage the instantiation of the virtual machines <NUM> on the one or more servers <NUM><NUM> to <NUM>n to support such needs. In one example implementation, virtualisation environment <NUM> may be implemented by running Amazon Elastic Compute Cloud (Amazon EC2) on servers <NUM><NUM> to <NUM>n. It should be recognised that any other virtualization technologies may alternatively be utilised.

Cloud environment <NUM> supports an execution environment <NUM> that comprises a plurality of virtual machines <NUM> (or containers <NUM>, as is discussed in relation to <FIG>) instantiated to host deployed computer executable code <NUM>. For example, deployment by user <NUM> or by secure provider <NUM> of computer executable code <NUM> to the cloud environment <NUM> results in the hosting of computer executable code <NUM> in virtual machine <NUM><NUM> and/or container <NUM><NUM>, of execution environment <NUM>.

Computer executable code <NUM> can access internal services provided by cloud environment <NUM> as well as external services from one or more external providers <NUM> and/or from secure provider <NUM>. Services may include, for example, accessing a REST API, a custom database, a relational database service (e.g., MySQL, etc.), monitoring service, background task scheduler, logging service, messaging service, memory object caching service and the like. A service provisioner <NUM> serves as a communications intermediary between these available services (e.g., internal services and external services) and other components of cloud environment <NUM> (e.g., cloud controller <NUM>, router <NUM>, containers <NUM>) and assists with provisioning available services to computer executable code <NUM> during the deployment process.

Service provisioner <NUM> may maintain a stub for each service available in cloud computing environment <NUM>. Each stub itself maintains service provisioning data for its corresponding service, such as a description of the service type, service characteristics, login credentials for the service (e.g., root username, password, etc.), a network address and port number of the service, and the like. Each stub component is configured to communicate with its corresponding service using an API or similar communications protocol.

Referring back to <FIG>, addressing and discovery layer <NUM> provides a common interface through which components of cloud computing environment <NUM>, such as service provisioner <NUM>, cloud controller <NUM>, router <NUM> and containers <NUM> in the execution environment <NUM> can communicate. For example, service provisioner <NUM> may communicate through addressing and discovery layer <NUM> to broadcast the availability of services and to propagate service provisioning data for such services during deployment of computer executable code <NUM> in cloud environment <NUM>.

Cloud controller <NUM> is configured to orchestrate the deployment process for computer executable code <NUM> that is submitted to cloud environment <NUM> by the user <NUM> or the secure provider <NUM>. In particular, cloud controller <NUM> receives computer executable code <NUM> submitted to cloud computing environment <NUM> from user <NUM> or secure provider <NUM> and, as further detailed below, interacts with other components of cloud environment <NUM> to call services required by the computer executable code <NUM> and package the computer executable code <NUM> for transmission to available containers <NUM>. An example cloud controller <NUM> service is Amazon Elastic Container service (ECS).

Typically, once cloud controller <NUM> successfully orchestrates the computer executable code <NUM> in container <NUM>, a secure provider <NUM> and/or a user <NUM> can access the computer executable code through a web browser or any other appropriate client application residing on a computer of user <NUM> or service provider <NUM>. Router <NUM> receives the web browser's access request (e.g., a uniform resource locator or URL) and routes the request to container <NUM> which hosts the computer executable code <NUM>.

It should be recognized that the embodiment of <FIG> is merely exemplary and that alternative cloud environment architectures may be implemented consistent with the teachings herein. For example, while <FIG> implements cloud computing environment <NUM> on cloud environment hardware <NUM>, it should be recognized that cloud environment <NUM> may be implemented by a third-party in an alternative manner and on top of any type of hardware.

<FIG> is a schematic of an exemplary server <NUM> for implementing a method of the invention. In particular, <FIG> depicts server <NUM> comprising server hardware <NUM> and virtual machine execution environment <NUM> having containers <NUM> with computer executable code <NUM>. The server hardware <NUM> may include local storage <NUM>, such as a hard drive, network adapter <NUM>, system memory <NUM>, processor <NUM> and other I/O devices such as, for example, a mouse and keyboard (not shown).

A virtualisation software layer, also referred to as hypervisor <NUM>, is installed on top of server hardware <NUM>. Hypervisor <NUM> supports virtual machine execution environment <NUM> within which containers <NUM> may be concurrently instantiated and executed. In particular, each container <NUM> provides computer executable code <NUM>, deployment agent <NUM>, runtime environment <NUM> and guest operating system <NUM> packaged into a single object. This enables container <NUM> to execute computer executable code <NUM> in a manner which is isolated from the physical hardware (e.g. server hardware <NUM>, cloud environment hardware <NUM>), allowing for consistent deployment regardless of the underlying physical hardware.

As shown in <FIG>, virtual machine execution environment <NUM> of server <NUM> supports a plurality of containers <NUM><NUM> to <NUM>n. Docker is an example of a virtual machine execution environment <NUM> which supports containers <NUM>. For each container <NUM><NUM> to <NUM>, hypervisor <NUM> manages a corresponding virtual machine <NUM><NUM> to <NUM>, that includes emulated hardware such as virtual hard drive <NUM>, virtual network adaptor <NUM>, virtual RAM <NUM>, and virtual central processing unit (CPU) <NUM>. For example, virtual machine <NUM> may function as an equivalent of a standard x86 hardware architecture such that any x86 supported operating system may be installed as a guest operating system <NUM> to execute computer executable code <NUM> for container <NUM>. Container <NUM> may be provided by virtualisation environment <NUM>, as previously discussed for <FIG>.

Hypervisor <NUM> is responsible for transforming I/O requests from guest operating system <NUM> to virtual machines <NUM>, into corresponding requests to server hardware <NUM>. In <FIG>, guest operating system <NUM> of container <NUM> supports the execution of deployment agent <NUM>, which is a process or daemon that communicates (e.g., via addressing and discovery layer <NUM>) with cloud controller <NUM> to receive and unpack computer executable code <NUM> and its deployment package. Deployment agent <NUM> also communicates with router <NUM> to provide network routing information for computer executable code <NUM> that have been deployed in container <NUM>. Guest operating system <NUM> further supports the execution of runtime environment <NUM> within which computer executable code <NUM> is executed.

It should be recognized that the various layers and modules described with reference to <FIG> are merely exemplary, and that other layers and modules may be used with the same functionality without departing from the scope of the invention. It should further be recognized that other virtualised computer architectures may be used, such as hosted virtual machines.

It will be appreciated that embodiments described herein may be implemented using a variety of different computing systems. In particular, although the figures and the discussion thereof provide an exemplary message routing system and method for operating thereof, these are presented merely to provide a useful reference in discussion various aspects of the invention. It will be appreciated that the boundaries between logic blocks in a block diagram are merely illustrative and that alternative embodiments may merge logic blocks or elements, or may impose an alternative decomposition of functionality upon various logic blocks or elements.

It will be appreciated the above-mentioned functionalities may be implemented as one or more corresponding software modules or components. Method steps implemented in flow diagrams herein, or as described above, may each be implemented by corresponding respective modules; multiple method steps implemented in flow diagrams contained herein, or as described above, may together be implemented by a single module.

It is to be understood that some features of the exemplary embodiments that are described as optional may or may not be part of the claimed invention and features of the disclosed embodiments may be combined. Unless specifically set forth herein, the terms "a", "an", and "the" are not limited to one element but instead should be read as meaning "at least one".

It is to be understood that at least some of the figures and descriptions of the invention have been simplified to focus on elements that are relevant for a clear understanding of the invention, while eliminating, for purpose of clarity, other elements that those of ordinary skill in the art will appreciate may also comprise a portion of the invention. However, because such elements are well known in the art, and because they do not necessarily facilitate a better understanding of the invention, a description of such elements is not provided herein. Furthermore, to the extent that the method does not rely on the particular order of steps set forth herein, the particular order of the steps should not be construed as limitation on the claims.

Claim 1:
A message routing system (<NUM>) comprising:
a message routing module (<NUM>);
a routing configuration module (<NUM>) configured to provide a routing configuration for each of one or more content messages, wherein each routing configuration comprises a source of the respective content message and one or more targets for the respective content message, and wherein each of the source and the one or more targets is characterised by a channel and an address;
a first binder module (<NUM>) configured to connect a first data streaming application (DSA1) to the message routing module using one or more channels, wherein the first binder module is configured to enable a content message to be routed to and/or from the first data streaming application;
a second binder module (<NUM>) configured to connect a second data streaming application (DSA2) to the message routing module using one or more channels, wherein the second binder module is configured to enable a content message to be routed to and/or from the second data streaming application,
wherein the first data streaming application is associated with a first cloud-based account and the second data streaming application is associated with a second cloud-based account;
wherein the message routing module configured to:
receive a content message from a data streaming application and a corresponding routing configuration for the content message from the routing configuration module; and
route the content message according to the corresponding routing configuration using a stream bridge interface (<NUM>).