System and method for a reactive messaging client for use in a microservices environment

Abstract

A system and method are provided for enabling the use of reactive messaging clients in a microservices environment. A microservices (e.g., Helidon) environment 100 provides a development framework that enables software developers to create and use microservices. According to an embodiment, the system includes a reactive messaging API 230 for use in long-running activities or other types of transactions related to microservices. The reactive messaging API enables the system to further support various reactive messaging features in a microservices environment, such as transaction processing, asynchronous messaging, and the use of reactive streams or messaging channels.

Description

[Technical Field]

[0001] Copyright Notice A portion of the disclosure of this patent document contains material that is subject to copyright protection. As the patent document or patent disclosure is publicly disclosed in the U.S. Patent and Trademark Office patent files and records, the copyright owner has no objection to the copying thereof by anyone, but otherwise reserves all copyright rights whatsoever without exception.

[0002] Priority claims This application claims the benefit of priority to U.S. Provisional Application No. 63 / 009,954, filed April 14, 2020, and entitled "SYSTEM AND METHOD FOR REACTIVE MESSAGING CLIENT FOR USEWITH A MICROSERVICES ENVIRONMENT," which is incorporated herein by reference.

[0003] Technical Field TECHNICAL FIELD Embodiments described herein relate generally to cloud computing and other computing environments, software development, and microservices architectures, and are directed in particular to systems and methods for enabling the use of reactive messaging clients in microservices environments. [Background technology]

[0004] background Microservices architectures are becoming popular for developing software applications that are delivered as cloud services in cloud computing environments, where a single software application can be presented as a collection of loosely coupled services that can be developed separately and communicate with each other over a network. Summary of the Invention [Means for solving the problem]

[0005] overview According to embodiments, this specification describes a system and method for enabling the use of reactive messaging clients in a microservices environment. Microservices (e.g., Helidon) environments provide a development framework that enables software developers to create and use microservices. According to embodiments, the system may include a reactive messaging API for use with long-running activities or other types of transactions related to microservices, which enables the system to further support various reactive messaging features in the microservices environment, such as transaction processing, asynchronous messaging, reactive streams, or the use of messaging channels. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 illustrates an exemplary microservices environment that provides a development framework, such as Helidon, according to an embodiment. [Figure 2] FIG. 1 illustrates an exemplary HelidonSE microservices environment, according to an embodiment. [Figure 3] FIG. 1 illustrates an exemplary HelidonMP microservices environment, according to an embodiment. [Figure 4] FIG. 1 illustrates an exemplary microservices environment that enables one or more cloud, database, or other integrations, according to an embodiment. [Figure 5] FIG. 1 illustrates the use of a database client in a microservices environment, according to an embodiment. [Figure 6] FIG. 1 illustrates the use of a remote procedure call framework, such as a gRPC framework, in a microservices environment, according to an embodiment. [Figure 7] FIG. 10 further illustrates the use of a database client in a microservices environment, according to an embodiment. [Figure 8] FIG. 1 illustrates the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment. [Figure 9] FIG. 10 further illustrates the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment. [Figure 10] FIG. 10 further illustrates the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment. [Figure 11] FIG. 10 further illustrates the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment. [Figure 12] FIG. 10 further illustrates the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment. [Figure 13] FIG. 10 further illustrates the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment. [Figure 14] FIG. 1 illustrates a process for using reactive messaging in a microservices-oriented environment, according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0007] Detailed Description As mentioned above, microservices architectures are becoming popular for developing software applications that are delivered as cloud services in cloud computing environments, where a single software application can be presented as a collection of loosely coupled services that can be developed separately and communicate with each other over a network, similar to a service-oriented architecture.

[0008] Software development frameworks such as Helidon support the development of microservices. For example, Helidon provides the Standard Edition (SE) programming model and the MicroProfile (MP) programming model or environment, which each provide a collection of software libraries that can be used to provide software developers with a foundation for creating microservices, including functionality such as configuration, security, and web server functionality.

[0009] Technical advantages offered by such an environment include reducing the need for software developers to program to a specific set of tools or deployment model, allowing microservices to run without the need for an application server, and microservice libraries interoperate with other software development, deployment, and monitoring tools such as Docker, Kubernetes, Prometheus, or OpenTracing.

[0010] Microservices environment (Helidon) FIG. 1 illustrates an exemplary microservices environment providing a development framework, such as Helidon, according to an embodiment.

[0011] As shown in FIG. 1, according to an embodiment, a microservices environment (microservices library) 100 may be provided as one or more software libraries, such as, for example, a HelidonSE or HelidonMP programming model or environment.

[0012] According to embodiments, as further described herein with respect to various other embodiments, the components and processes shown in Figure 1 may be provided as software or program code executable by a computer system or other type of processing device. For example, according to embodiments, the components and processes described herein may be provided by a cloud computing system or other suitably programmed computer system.

[0013] According to an embodiment, the HelidonSE environment 110 may include various libraries, APIs, or other components, such as, for example, a reactive web server 111 that provides an asynchronous, reactive API for creating web applications; a configuration API 112 that provides a Java API (application program interface) for reading and processing key / value configuration properties into configuration objects that can then be used by applications to retrieve the configuration data; and a security component 113 that provides authentication, authorization, and outbound security, and may also include metrics 114, health checks 115, and tracing 116, or other components.

[0014] According to an embodiment, the HelidonMP environment 120 may include various libraries, APIs, or other components, such as, for example, components such as JAX-RS 122, CDI 124, JSON-P 126, metrics 128, health checks 130, fault tolerance 132, MicroProfile configuration 134, and JWT authentication 136. The web server may be provided by a non-blocking client / server / web framework 118, such as Netty. The microservices environment may also enable interaction with cloud, database, or other systems or services 140.

[0015] HelidonSE (Standard Edition) FIG. 2 illustrates an exemplary HelidonSE microservices environment, according to an embodiment.

[0016] As shown in Figure 2, according to an embodiment, the HelidonSE environment supports a functional programming style that directly leverages web server, security, and configuration components; provides transparency and control to software developers; and supports Java features such as reactive streams and asynchronous functional programming. The HelidonSE environment provides a framework within which software developers can build lightweight reactive microservices.

[0017] HelidonMP(MP) FIG. 3 illustrates an exemplary HelidonMP microservices environment, according to an embodiment.

[0018] As shown in FIG. 3, according to an embodiment, the HelidonMP environment is It supports a more declarative programming style by using the MicroProfile family of APIs built on top of libraries, and uses MicroProfile definitions (for example, as specified by the Eclipse MicroProfile project) to support application portability across multiple MicroProfile runtimes.

[0019] Integration with cloud, database, or other systems / services FIG. 4 illustrates an exemplary microservices environment that enables one or more cloud, database, or other integrations, according to an embodiment.

[0020] As shown in FIG. 4, according to an embodiment, a microservices environment can enable a client (computer) device 150 having device hardware 152 and client application 154 to interact with, for example, one or more clouds 160, servers 170, 172, 174, databases 180, or other cloud or on-premise systems or services.

[0021] For example, according to embodiments, when used in an enterprise application environment, microservices may be utilized to interact with, communicate, transform, or output data from various enterprise application software products, such as, for example, an Oracle Fusion application environment, or to communicate with enterprise server applications, databases, or other environments, such as, for example, an Oracle Database environment or an Oracle Coherence environment.

[0022] Database clients for use in a microservices environment According to an embodiment, a non-blocking reactive web server implementation can be developed using a microservices environment such as HelidonSE. In such an environment, the reactive nature of the implementation allows a smaller number of threads to handle a larger load. However, if the web server or client application needs to communicate with a database, for example, using JDBC, which operates in a blocking manner, the reactive web server or client application may need to lock threads, which can cause performance issues for the reactive application.

[0023] According to an embodiment, a microservices environment, such as HelidonSE, may include a database client and database client API that provide a unified, reactive API for communicating, accessing, and retrieving data, and for working with databases in general, in a non-blocking manner. The database client can work with database drivers and include a thread pool to control thread blocking. Meanwhile, the database client API itself can be used in a non-blocking manner by software developers to incorporate, for example, the use of a blocking JDBC driver into a reactive client application. Because the database client performs database operations only when requested, the database client reduces backpressure while supporting features such as metrics, tracing, health, and security.

[0024] FIG. 5 is a diagram illustrating the use of a database client in a microservices environment, according to an embodiment.

[0025] As shown in FIG. 5, according to an embodiment, the database client 200 may be configured to support a variety of database drivers (e.g., a JDBC driver 204, or a MongoDB driver 206). The API can operate with an ActiveStream Java driver 206) to enable the client application 202 to access one or more database environments, for example, an Oracle JDBC database or a MongoDB database, as well as SQL and NoSQL databases, such that CRUD operations are supported by the API regardless of the database used in the backend.

[0026] According to an embodiment, by moving the native query code into a configuration file, the database client allows a client application to utilize different databases by changing settings associated with the database client. For example, the database client can be configured with:

[0027]

number

[0028] According to an embodiment, a database client API may provide methods for executing statements with parameters and for retrieving the results of statement execution. In an SQL statement, ordered or named parameters can be added using ? or <name>can be shown respectively.

[0029]

number

[0030] According to an embodiment, after the parameters of a statement are set, the statement can be executed by calling the execute() method, which results in a CompletionStage <r>where R is the statement execution result. The following example shows a JDBC query with ordered parameters that does not work in a transaction:

[0031]

number

[0032] Meanwhile, the following example shows a JDBC query with named parameters that operates in a transaction:

[0033]

number

[0034] According to an embodiment, a microservices (e.g., Helidon) environment may incorporate an RPC (Remote Procedure Call) framework or component, such as gRPC. It can support the use of components that allow client and server applications to communicate within a microservices environment to build connected systems.

[0035] FIG. 6 illustrates the use of a remote procedure call framework, such as a gRPC framework, in a microservices environment, according to an embodiment.

[0036] As shown in FIG. 6, according to an embodiment, the gRPC framework provides an environment or API 208 that enables services to connect with each other, supporting advanced features such as load balancing, tracing, health checks, and authentication.

[0037] In overview, the gRPC framework uses protocol buffers as an IDL (Interface Description Language) and message interchange format, enabling the definition of services and methods that can be invoked remotely. A computer server runs a gRPC server (GrpcServer) and serves client calls through a local object (stub) on the client. This allows client applications to directly invoke methods on the server application as if it were a local object. Clients and servers can communicate with each other in a variety of different environments and in a variety of supported languages, such as Java, Ruby, Android, Swift, or other types of languages.

[0038] According to an embodiment, on the server side, the server implements the methods declared by the service and provides a gRPC server to handle client calls, including decoding incoming requests, executing service methods, and encoding service responses. On the client side, the client uses a local object (stub) that implements the same methods as the service. The client can then invoke these methods on the local object, wrapping the parameters for the call in the appropriate protocol buffer message type. These parameters are then provided to the server as a request via gRPC.

[0039] FIG. 7 is a diagram further illustrating the use of a database client in a microservices environment, according to an embodiment.

[0040] As shown in FIG. 7, according to an embodiment, the microservices environment (microservices library) enables access by client applications, such as database clients as described above, to communicate with the microservices or interact with cloud, database, or other systems or services in order to access data, process transactions, or perform other operations related to these systems or services.

[0041] Reactive Messaging Client According to an embodiment, the system may include a reactive messaging API for use in long-running activities or other types of transactions related to microservices, which enables the system to further support various reactive messaging features in a microservices environment, such as, for example, transaction processing, asynchronous messaging, reactive streams, or the use of messaging channels.

[0042] FIG. 8 illustrates the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment.

[0043] As shown in FIG. 8, according to an embodiment, the system includes a reactive engine 210 that provides a reactive messaging client API (reactive messaging API 230) and operators that can be used with reactive streams to enable client and server applications to communicate within a microservices environment.

[0044] According to an embodiment, the system includes one or more messaging connectors (connectors) 212 adapted to provide publishers and subscribers for channels used for reactive messaging with services and / or server applications. For example, as described further below, connectors may be provided to support using reactive messaging clients with Kafka, JMS, Oracle AQ, and AQ (Oracle Advanced Queuing). AQ is an Oracle Provides message queuing services for use by a messaging, database, or server environment.

[0045] FIG. 9 is a diagram further illustrating the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment.

[0046] As shown in FIG. 9, according to an embodiment, a microservices environment, for example, a HelidonMP environment, may include a reactive messaging API 230 that is used by (reactive messaging) client applications 220 to access or communicate with microservices or interact with cloud, database, or other systems or services for the purpose of processing transactions related to those systems or services.

[0047] According to an embodiment, in a transactional environment, communication with a microservice is generally message-based or event-based. For example, a first invoked method or service may be associated with a second invoked method or service as part of a transaction, and then with, for example, a third or subsequent invoked method or service.

[0048] According to embodiments, by allowing a client application to behave reactively, the application can determine, for example, how many messages it should receive at a particular time or how many threads it will need to process those messages, which acts to reduce backpressure on the client application.

[0049] FIG. 10 is a diagram further illustrating the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment.

[0050] Additionally, as shown in FIG. 10, embodiments enable the development of reactive messaging APIs for use in other microservice environments, such as HelidonSE environments.

[0051] According to various embodiments, reactive messaging can support connectors for use with Kafka, JMS, or a variety of other environments, such as cloud environments such as OCI (Oracle's Cloud Infrastructure).

[0052] FIG. 11 is a diagram further illustrating the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment.

[0053] According to an embodiment, traditional transactional application environments may utilize two-phase commit and XA protocols with synchronous communication, resource locking, and recovery via rollback. However, such approaches generally do not scale well in microservice environments due to the latency of pending locks.

[0054] 11, according to an embodiment, the system supports the use of microservices architectural patterns to implement transactions, such as AQ or other features of a DB (database) environment 240, that can utilize asynchronous communication and local resources and support recovery with compensating operations. Such an approach is well suited to support long-running activities and transactions in a microservices environment.

[0055] According to an embodiment, a reactive messaging client can be developed as an implementation of the MicroProfile definition, for example as specified by the Eclipse MicroProfile project.

[0056] According to an embodiment, the system supports the use of long-running activities such as those described above, for example, through Eclipse's MicroProfile's Long Running Activities (LRA) API, which enables loosely coupled services to coordinate long-running activities.

[0057] According to an embodiment, just as the Java Transaction API supports the use of two-phase commit and XA in traditional transactional application environments, the system can similarly support the operation of the LRA API with microservices architectural patterns such as the Saga pattern.

[0058] In general terms, according to an embodiment, the Saga pattern can be used to enable business transactions to span multiple services, such as an e-commerce application that operates according to multiple billing or other transactional services. In such an environment, the data required for a particular transaction may be controlled by different services or stored in different databases, thereby avoiding the use of typical two-phase commit processing. The Saga pattern allows transactions to be executed as a series of local transactions, where each local transaction updates a database and publishes a message or event that triggers the next local transaction in the Saga. If a local transaction fails, the system executes a compensating transaction to undo the changes made by the previous local transaction.

[0059] As further shown in FIG. 11, according to an embodiment, the Saga pattern operates such that persistent state / events 250 associated with transactions and services are persisted or stored 244 locally in a database, such as, for example, an AQ database environment that supports the use of Saga identifiers (SagaIDs).

[0060] FIG. 12 is a diagram further illustrating the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment.

[0061] As shown in FIG. 12, according to an embodiment, multiple microservices (A, B, C) can participate in a long-running activity associated with a transaction such that when it is time to commit the transaction, each of the microservices will commit. .

[0062] According to an embodiment, if for some reason the system determines that a transaction must be rolled back by performing a compensation operation, rather than having each service perform its own compensation log in the event of a failure in one service, for example, the appropriate compensation can be performed in the database itself using information stored in the database associated with the service, including the SagaID. The database environment itself can determine from the SagaID which appropriate compensation needs to be performed in order to reconcile the transaction.

[0063] FIG. 13 is a diagram further illustrating the use of a reactive messaging client in a microservices-oriented environment, according to an embodiment.

[0064] As shown in FIG. 13, according to an embodiment, the reactive messaging API can also be used in an AQ environment that supports microservices, or in other microservice environments, such as a HelidonSE environment.

[0065] FIG. 14 illustrates a process for using reactive messaging in a microservices-oriented environment, according to an embodiment.

[0066] As shown in FIG. 14, in an embodiment, in step 262, a microservices environment (microservices library) is provided in a computer having one or more processors and memory, which provides a development framework that enables software developers to create and use microservices.

[0067] In step 264, in association with the microservices environment, a reactive engine is provided that provides reactive messaging APIs and operators that can be used with reactive streams to enable client and server applications to communicate within the microservices environment.

[0068] Step 266 provides one or more messaging connectors adapted to provide publishers and subscribers for channels used for reactive messaging with services and / or server applications.

[0069] In step 268, the system enables communication between the client and the service and / or between the client and the server application via a reactive messaging API and one or more connectors.

[0070] Reactive Messaging Engine (Reactive Engine) As described above, according to an embodiment, the system includes a reactive engine that provides reactive messaging APIs and operators that can be used with reactive streams to enable client and server applications to communicate within a microservices environment.

[0071] For example, according to an embodiment, the reactive engine provides a set of operators that can be used with java.util.concurrent.Flow-based reactive streams. In such an embodiment, stream processing operator chains can be constructed using io.helidon.common.reactive.Multi if the stream has multiple values, or io.helidon.common.reactive.Single if the stream has a single value. Therefore, an example of the use of a multi-stream processing operator chain is given below.

[0072]

number

[0073] An example of the use of a single stream processing operator chain according to an embodiment is given below.

[0074]

number

[0075] Table 1 shows examples of reactive operators that the system supports, according to embodiments. The examples provided in the table are illustrative, and other types of reactive operators may be supported, according to various embodiments.

[0076] [Table 1]

[0077] [Table 2]

[0078] [Table 3] Table 1

[0079] Operator Chain According to an embodiment, if a part of an operator chain needs to be prepared in advance, the compose operator and the to operator may be selected. An example of combining operator chains according to an embodiment is shown below.

[0080]

number

[0081] According to an embodiment, to enable a software project to use the reactivity engine, the following dependencies may be declared in the project:

[0082]

number

[0083] Reactive Streams Operators According to an embodiment, the system provides an implementation of the MicroProfile Reactive Streams Operators Specification, which was developed by the Eclipse Foundation. The MicroProfile Reactive Streams Operators Specification defines a standardized approach to manipulating data using reactive streams, operators for use in stages, and the use of builders to prepare graphs of stages from which streams can be constructed. According to an embodiment, an example of the use of a closed graph is shown below.

[0084]

number

[0085] Table 2 shows examples of supported operators for use with stages according to embodiments. These examples provided herein are illustrative. Other types of reactive operators may also be supported according to various embodiments.

[0086] [Table 4]

[0087] [Table 5] Table 2

[0088] graph According to an embodiment, a graph is a pre-built stream builder with stages that can be aggregated to form a closed graph with via and to methods. An example of integrating multiple graphs and executing a stream according to an embodiment is shown below.

[0089]

number

[0090] According to the embodiment, MicroProfile reactions in software projects To enable the use of Reactive Streams (defined in the MicroProfile Reactive Streams Operators Specification), the following dependency can be declared in a project:

[0091]

number

[0092] HelidonSE Reactive Messaging As described above, according to embodiments, a microservices environment (microservices library) can be provided as one or more software libraries, such as, for example, the HelidonSE programming model or the HelidonSE programming environment.

[0093] Asynchronous messaging is a common form of communication in microservices environments. While reactive streams can be constructed directly by combining operators and connecting them to reactive APIs, in embodiments, the system provides additional tools to address various use cases.

[0094] For example, connecting a stream to an external service often requires a lot of boilerplate code for handling configuration, backpressure propagation, acknowledgments, etc. According to an embodiment, to accommodate such tasks, the system provides a means for multiple connectors, multiple emitters, and multiple directors. When provided as a reactive messaging API, the system allows connectors and emitters to be connected and configured with reactive streams through channels.

[0095] According to embodiments, embodiments of the system for HelidonSE reactive messaging support the same configuration format for multiple connectors as MicroProfile connectors. For example, HelidonSE reactive messaging allows multiple HelidonMP connectors to be used, with some limitations (e.g., there is no CDI in HelidonSE).

[0096] channel According to an embodiment, a channel is a named pair of a publisher and a subscriber. Multiple channels can be connected by multiple processors. Publishers or subscribers can be registered with a channel through the reactive messaging API, or the registration can be implicitly configured to use a registered connector to create such publishers or subscribers. An example of a simple channel configuration according to an embodiment is shown below:

[0097]

number

[0098] Processor According to an embodiment, the processor operates as a general reactive processor in that it acts as a subscriber to send components upstream and as a publisher to send components downstream. In terms of reactive messaging, the processor can connect two channels into one reactive stream. An example of the use of the processor according to an embodiment is shown below.

[0099]

number

[0100] message According to an embodiment of the system that supports HelidonSE reactive messaging, the system uses the same concept of message wrapping as MicroProfile messaging, but differs in that SE reactive messaging provides little implicit or automatic acknowledgments. Variant types of methods Messaging.Builder#listener and Messaging.Builder#processor that have consumer or function parameters. is different, as it conveniently unwraps the payload. Such implicit unwrapping does not allow manual acknowledgment, so an implicit ack must be performed before the callback is executed.

[0101] Messaging Connectors As described above, according to an embodiment, the system comprises one or more messaging connectors adapted to provide publishers and subscribers of channels used for reactive messaging with services and / or server applications.

[0102] For example, according to an embodiment, the system includes connectors that provide a means for connecting channels to external sources. To make creating and using connectors as easy and versatile as possible, embodiments of the system that support HelidonSE reactive messaging use the same API for connectors as MicroProfile reactive messaging. This allows connectors to be used with both Helidon variants (with the limitation that the connector must be able to work without CDI, as noted above). Such connectors include a Kafka connector, a JMS connector, and / or an AQ connector. Examples of these connectors are discussed further below.

[0103] According to an embodiment, to enable the use of reactive messaging in a software project, the following dependencies may be declared in the project:

[0104]

number

[0105] According to an embodiment, a messaging connector (connector) for reactive messaging may be provided as a factory that produces publishers and subscribers for channels used in reactive messaging. A messaging connector may be provided as an implementation of an IncomingConnectorFactory, an OutgoingConnectorFactory, or both. According to an embodiment, an example connector, example-connector, is shown below:

[0106]

number

[0107] An example of a configuration for mapping channels to connectors according to an embodiment is shown below.

[0108]

number

[0109] An example of producing a message to a connector according to an embodiment is shown below.

[0110]

number

[0111] An example of consuming (receiving) a message from a connector according to an embodiment is shown below.

[0112]

number

[0113] setting According to an embodiment of the system that supports HelidonSE reactive messaging, messaging connectors can be configured explicitly through an API or implicitly through MicroProfile reactive messaging configuration expressions. When configuration is provided to a connector by a messaging implementation, there are two required attributes:

[0114] channel-name is the name of the channel that has this connector configured as a publisher or subscriber, e.g., for explicit configuration it is set as Channel.create('name-of-channel'), and for implicit configuration it is set as mp.messaging.incoming.name-of-channel.connector:connector-name.

[0115] The connector name of the connector @Connector is ("connector-name").

[0116] An example of a configuration for accessing a connector according to an embodiment is shown below.

[0117]

number

[0118] According to an embodiment, the configuration context is merged from the channel context and the connector context.

[0119] Explicit configuration According to an embodiment, a channel's publisher can be explicitly configured with Channel.Builder#publisherConfig(Config config), and a channel's subscriber can be explicitly configured with Channel.Builder#subscriberConfig(Config config). Helidon merges the provided configuration with all required attributes and any implicit configuration it finds. The resulting configuration is then sent to the connector. Below is an example of consuming messages from an explicitly configured Kafka connector according to an embodiment:

[0120]

number

[0121] According to an embodiment, the above example shows how the system can be used to prepare a channel to connect a Kafka connector with a specific publisher configuration → listener; provide a configuration channel → connector mapping that is automatic when using KafkaConnector.configBuilder(); and prepare a Kafka connector that can be used by any channel.

[0122] Implicit Configuration According to an embodiment, following the MicroProfile reactive messaging notation, implicit configuration without hard coding can be provided. An example of a configuration that maps a channel with custom properties to a connector according to an embodiment is shown below.

[0123]

number

[0124] According to an embodiment, the above example shows how the system can be used to provide channel-to-connector mappings, provide channel configuration properties, and provide connector configuration properties.

[0125] An example of consuming a message from a connector according to an embodiment is shown below.

[0126]

number

[0127] Reusability in MP messaging According to an embodiment, the reactive messaging API is the same as that of MicroProfile reactive messaging connectors, so to make a connector work in both environments, you only need to annotate the connector with @ApplicationScoped. Such connectors can be treated as beans in HelidonMP.

[0128] **** Reactive Kafka Connector According to an embodiment of a system that supports HelidonSE reactive messaging, the system can be used to connect streams to a Kafka environment with reactive messaging as follows:

[0129]

number

[0130] Explicit Configuration (Configuration Builder) Below is an example of how a system can be explicitly configured to consume messages from a Kafka environment, according to an embodiment.

[0131]

number

[0132] According to an embodiment, the above example shows how the system can be used to prepare a channel to connect a Kafka connector with a specific publisher configuration → listener; the channel → connector mapping is automatic when using KafkaConnector.configBuilder(); and a Kafka connector that can be used by any channel.

[0133] Below is an example of how a system can be explicitly configured to produce messages to a Kafka environment, according to an embodiment.

[0134]

number

[0135] According to an embodiment, the above example shows how the system can be used to prepare a channel for connecting a Kafka connector with a specific publisher configuration → listener; the channel → connector mapping is automatic when using KafkaConnector.configBuilder(); and a Kafka connector that can be used by any channel.

[0136] Implicit (Helidon) configuration Below is an example of how a system can be implicitly configured to work with Kafka, according to an embodiment.

[0137]

number

[0138] Below is an example of how a system can be implicitly configured to consume messages from a Kafka environment, according to an embodiment.

[0139]

number

[0140] According to an embodiment, the above example shows how the system can be used to provide a Kafka connector that can be used by any channel.

[0141] Below is an example of how a system can be implicitly configured to produce messages to a Kafka environment according to an embodiment.

[0142]

number

[0143] According to an embodiment, the above example shows how the system can be used to provide a Kafka connector that can be used by any channel.

[0144] **** Reactive JMS Connector According to an embodiment of the system that supports HelidonSE reactive messaging, the system can be used to connect streams to a JMS environment with reactive messaging.

[0145]

number

[0146] Explicit Configuration (Configuration Builder) Below is an example of how a system can be explicitly configured to consume messages from a JMS environment, according to an embodiment.

[0147]

number

[0148] According to an embodiment, the above example shows how the system can be used to prepare a channel for connecting a JMS Connector with a specific publisher configuration → listener; the channel → connector mapping is automatic when using JmsConnector.configBuilder(); and to prepare a JMS Connector that can be used by any channel.

[0149] Below is an example of how a system can be explicitly configured to produce messages into a JMS environment according to an embodiment.

[0150]

number

[0151] According to an embodiment, the above example shows how the system can be used to prepare a channel for connecting a JMS Connector with a specific publisher configuration → listener; the channel → connector mapping is automatic when using JmsConnector.configBuilder(); and to prepare a JMS Connector that can be used by any channel.

[0152] Implicit (Helidon) configuration Below is an example of how a system can be implicitly configured to work with JMS according to an embodiment.

[0153]

number

[0154] Below is an example of how a system can be (implicitly) configured to consume messages from a JMS environment, according to an embodiment.

[0155]

number

[0156] According to an embodiment, the above example shows how the system can be used to provide a JMS connector that can be used by any channel.

[0157] Below is an example of how a system can be (implicitly) configured to produce messages into a JMS environment according to an embodiment.

[0158]

number

[0159] According to an embodiment, the above example shows how the system can be used to provide a JMS connector that can be used by any channel.

[0160] **** Reactive Oracle AQ Connector According to an embodiment of a system that supports HelidonSE reactive messaging, the system can be used to connect a stream to an AQ environment with reactive messaging as follows.

[0161]

number

[0162] Sending and receiving Below is an example of how a system can be configured to produce and consume messages from an AQ environment according to an embodiment.

[0163]

number

[0164] According to an embodiment, the above example shows how the system can be used to prepare an Oracle UCP; set up an AQ connector to provide a data source with identifier test-ds; set up a channel to send messages to queue example_queue_1 with data source test-ds; set up a channel to receive messages from queue example_queue_1 with data source test-ds; register the connector and channel; add a publisher for multiple test messages and immediately publish these messages to example_queue_1; and subscribe to callbacks for messages sent from example_queue_1.

[0165] **** HelidonMP Reactive Messaging As described above, according to embodiments, a microservices environment (microservices library) may be provided as one or more software libraries, such as, for example, a HelidonMP programming model or HelidonMP programming environment.

[0166] According to an embodiment, MicroProfile Reactive Messaging uses CDI beans to produce, consume, and process messages on reactive streams. Such messaging beans are expected to either be beans that live for the lifetime of the application or beans that belong to a pseudo-scope. Messages are managed by methods annotated with @Incoming and @Outgoing, and invocation is always driven by the message core, either at assembly time or for every message coming from the stream. Beans can have methods annotated with @Incoming, @Outgoing, or both.

[0167] [Table 6] Table 3

[0168] Consuming a method with the annotation @Incoming According to an embodiment, this annotation requires one attribute value that defines the channel name. Such an annotated messaging method can work in two ways: it can consume all messages coming from the stream connected to the channel, or it can provide a reactive stream subscriber and connect it to the channel.

[0169] An example of consuming all messages from channel example-channel-2 according to an embodiment is shown below.

[0170]

number

[0171] An example of preparing a subscriber for a reactive stream on channel example-channel-1 according to an embodiment is shown below.

[0172]

number

[0173] Producing a method with the annotation @Outgoing According to an embodiment, the annotation requires one attribute value that defines the channel name. Such an annotated messaging method can work in two ways: it can produce a single message to a stream connected to the channel, or it can provide a reactive stream publisher and connect it to the channel.

[0174] An example of producing only one message on a channel, example-channel-1, according to an embodiment is shown below.

[0175]

number

[0176] The following is an example of providing a reactive stream publisher that publishes three messages to a channel example-channel-1 according to an embodiment.

[0177]

number

[0178] Processing methods with @Incoming and @Outgoing annotations According to an embodiment, these methods act as processors, consuming messages from one channel and producing messages to another. Such annotated messaging methods can work in several ways: by processing all messages; by providing a reactive stream processor and connecting between the channels; or by providing a new publisher (equivalent to the flatMap operator) on all messages.

[0179] The following example shows how to process all messages from channel example-channel-1 and output them to the following channels according to an embodiment:

[0180]

number

[0181] An example of preparing a processor stream connected between channels according to an embodiment is shown below.

[0182]

number

[0183] The following is an example of processing all messages from channel example-channel-1 into a single flattened stream that is output to channel example-channel-2, according to an embodiment.

[0184]

number

[0185] According to an embodiment, to enable the use of reactive messaging in a software project, the following dependencies may be declared in the project:

[0186]

number

[0187] Health Check According to an embodiment, messaging in Helidon has built-in health probes for liveness and readiness. To enable them, the following dependency can be declared in your project:

[0188]

number

[0189] According to an embodiment, the above example shows how the system can be used to provide liveness (a channel is considered UP until the cancel or onError signal is interrupted); readiness (a channel is considered DOWN until the onSubscribe signal is interrupted). By checking the health endpoints / health / live and / health / ready, every messaging channel can be seen as having its own probe.

[0190]

number

[0191] According to an embodiment, the reactive messaging Message class can be used to wrap and unwrap data between methods and connectors. Messages can be wrapped and unwrapped explicitly by using org.eclipse.microprofile.reactive.messaging.Message#of(T), or implicitly through the messaging core. Examples of explicit and implicit wrapping and unwrapping are shown below:

[0192]

number

[0193] Acknowledgment According to an embodiment, messages carry a callback for receipt acknowledgment, and acknowledgment is possible automatically in messaging methods via org.eclipse.microprofile.reactive.messaging.Message#ack, or according to an explicit or implicit acknowledgement strategy by the messaging core. Explicit strategy configuration can be provided by the annotation @Acknowledgment, which requires a single attribute value that expects a strategy type that is an enumeration of org.eclipse.microprofile.reactive.messaging.Acknowledgment.Strategy.

[0194] Table 4 shows example acknowledgment strategies according to an embodiment.

[0195] [Table 7] Table 4

[0196] An example of a manual acknowledgement, according to an embodiment, is shown below.

[0197]

number

[0198] Calling ack() prints "This particular message was acked!" to System.out. An example of manual acknowledgment, according to an embodiment, is shown below: .

[0199]

number

[0200] Calling ack() prints "This particular message was acked!" to System.out. An example of explicit pre-processing acknowledgment, according to an embodiment, is shown below:

[0201]

number

[0202] An example of an explicit acknowledgment after processing according to an embodiment is shown below.

[0203]

number

[0204] Messaging Connector Bean According to an embodiment, messaging connectors may be provided as beans that live for the lifetime of an application, implementing an IncomingConnectorFactory, an OutgoingConnectorFactory, or both.

[0205] An exemplary connector, example-connector, according to an embodiment is shown below.

[0206]

number

[0207] An example of a configuration for mapping channels to connectors according to an embodiment is shown below.

[0208]

number

[0209] An example of producing a message to a connector according to an embodiment is shown below.

[0210]

number

[0211] An example of consuming a message from a connector according to an embodiment is shown below.

[0212]

number

[0213] setting An example of a configuration for accessing a connector according to an embodiment is shown below.

[0214]

number

[0215] In this example, the configuration context is merged from the channel context and the connector context.

[0216] An example of a channel to connector mapping configuration with custom properties is shown below according to an embodiment.

[0217]

number

[0218] According to an embodiment, the above example shows how the system can be used to provide channel-to-connector mappings; provide channel configuration properties; and provide connector configuration properties.

[0219] An example of consuming a message from a connector according to an embodiment is shown below.

[0220]

number

[0221] Reactive Kafka Connector According to an embodiment of a system that supports HelidonMP reactive messaging, the system can be used to connect streams to a Kafka environment with reactive messaging as follows:

[0222]

number

[0223] An example of a connector configuration according to an embodiment is shown below.

[0224]

number

[0225] An example of consuming messages from a Kafka environment according to an embodiment is provided below.

[0226]

number

[0227] An example of producing a message to a Kafka environment according to an embodiment is provided below.

[0228]

number

[0229] **** Reactive JMS Connector According to an embodiment of a system that supports HelidonMP reactive messaging, the system can be used to connect streams to a JMS environment with reactive messaging as follows:

[0230]

number

[0231] setting According to an embodiment, Table 5 shows example attributes that may be used with the connector name: helidon-jms.

[0232] [Table 8] Table 5

[0233] The configured JMS factory According to an embodiment, a simple use case involves looking up a JMS connection factory from a naming context. An example connector configuration according to an embodiment is shown below:

[0234]

number

[0235] Injected JMS factories A more detailed example setup according to an embodiment is shown below: where a connector may work with an injected factory instance, for example:

[0236]

number

[0237] Consume An example of using unwrapped values ​​to consume one by one from a JMS environment according to an embodiment is shown below.

[0238]

number

[0239] An example of consuming from a JMS environment one at a time using manual ACK according to an embodiment is shown below.

[0240]

number

[0241] Produce An example of producing a message into a JMS environment according to an embodiment is provided below.

[0242]

number

[0243] Below is an example of a more advanced way to produce messages into a JMS environment, according to an embodiment.

[0244]

number

[0245] Another example of advanced production of messages into a JMS environment using a custom mapper according to an embodiment is shown below.

[0246]

number

[0247] Reactive Oracle Advanced Queuing Connector According to an embodiment of a system that supports HelidonMP reactive messaging, the system can be used to connect streams to an AQ environment with reactive messaging as follows: According to an embodiment, this connector is adapted to extend the HelidonJMS connector with an AQ-specific API.

[0248]

number

[0249] setting According to an embodiment, Table 6 shows examples of attributes that may be used with the connector name: helidon-aq.

[0250] [Table 9] Table 6

[0251] The configured JMS factory According to an embodiment, a simple use case involves delegating the construction of an AQJMS connection factory to a connector. An example connector configuration is shown below:

[0252]

number

[0253] According to an embodiment, the system allows for the use or reference of configured data sources, for example, Oracle UCP (Universal Connection Pool) data sources. An example connector configuration with an Oracle UCP data source is shown below:

[0254]

number

[0255] Injected JMS factories According to an embodiment, for a more advanced setup, the connector can work with an injected AQJMS connection factory.

[0256]

number

[0257] Consume Below is an example of using unwrapped values ​​to consume one by one from the AQ environment, according to an embodiment.

[0258]

number

[0259] An example of consuming one by one with manual ACK from an AQ environment according to an embodiment is shown below.

[0260]

number

[0261] Produce An example of producing a message to an AQ environment according to an embodiment is provided below.

[0262]

number

[0263] Oracle AQ (Advanced Queuing) Example Another example of using reactive messaging with an AQ environment, according to an embodiment, is shown below. This example uses the MicroProfile reactive messaging implementation, an AQ messaging connector, and Helidon's support for Oracle UCP (Universal Connection Pool) data sources to connect with HelidonMP.

[0264]

number

[0265] In this example, the UCP connection pool is used as a data source to connect to the Oracle database, which involves first creating a UCP data source and then referencing that UCP data source from the AQ connector configuration with the mp.messaging.connector.helidon-aq.data-source configuration property.

[0266]

number

[0267] Once a UCP data source is set up, it can have multiple reactive messaging methods. For example, you can have one method to publish messages every 2 seconds on an outgoing channel called to-aq, and another method to consume messages on an incoming channel called from-aq. Both channels are configured with a destination of example-queue-1. Produced messages are consumed immediately after a short trip to the Oracle database.

[0268]

number

[0269] According to an embodiment, the AQ connector is fully integrated with the MicroProfile reactive messaging acknowledgement feature. The default ack mode is AUTO_ACKNOWLEDGE, which means that all incoming messages are acknowledged immediately once they are received by the connector. If an error occurs during message processing, such as an error between the connector and the phase after the message is considered successfully consumed, the message will not be resent. To transfer the actual acknowledgement control to the business code, the acknowledge-mode can be set to CLIENT_ACKNOWLEDGE.

[0270]

number

[0271] All messaging methods have a well-defined default acknowledgment strategy or you can manually call Message.ack(), leaving acknowledgment to the messaging itself. Like other Helidon connectors, the AQ connector works with the HelidonSE reactive messaging API. All you need is the AQ connector dependency.

[0272]

number

[0273] For example, you can use the AQ connector with SE messaging by adding the snippet directly to the main method.

[0274]

number

[0275] According to various embodiments, the teachings herein may be conveniently implemented by one or more conventional general-purpose or special-purpose digital computers, computing devices, machines, or microprocessors, including one or more processors, memory, and / or computer-readable storage media, programmed according to the teachings of the present disclosure. Based on the teachings of the present application, appropriate software coding can be readily prepared.

[0276] In some embodiments, the present invention includes a computer program product that is a non-transitory computer-readable storage medium(s) having instructions stored thereon. The computer program product can be used to program a computer to perform any of the processes of the present teachings. For example, such a storage medium may include, but is not limited to, a hard disk drive, a hard disk, a fixed disk, or other electromechanical data storage device, a floppy disk, an optical disk, a DVD, a CD-ROM, a microdrive, and any type of disk, including a magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory device, a magnetic or optical card, a nanosystem, or any other type of storage medium or device suitable for temporarily storing instructions and / or data.

[0277] The above description has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the scope of protection to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art.

[0278] For example, although various embodiments of the systems and methods described herein are described for use in a Helidon microservices environment, various embodiments can be used in other types of microservices environments or other computing environments.

[0279] The embodiments have been chosen and described to best explain the principles of the present teachings and their practical application, thereby enabling those skilled in the art to appreciate various embodiments and, in addition, various modifications thereof suited to particular uses contemplated. The scope of the present disclosure is indicated by the appended claims and their equivalents.< / r> < / name>

Claims

1. 1. A system for using a reactive messaging client in a microservices environment, comprising: a computer including one or more processors, the computer providing access to a microservices environment for use by a software application, the system further comprising: a reactive engine that provides reactive messaging APIs and operators that can be used with reactive streams for use in long-running activities or other types of transactions related to microservices, the reactive messaging APIs and operators enabling client and server applications to communicate within the microservices environment; and one or more messaging connectors adapted to provide publishers and subscribers for channels used for reactive messaging with services and / or server applications.

2. The system of claim 1 , wherein the microservices environment is a Helidon environment for use in one or more cloud computing or other environments.

3. 10. The system of claim 1, wherein the system supports the use of microservices architectural patterns for implementing transactions, such as the Saga pattern.

4. 4. The system of claim 3, wherein the Saga pattern operates such that persistent state / events associated with transactions and services are persisted or stored locally in a database that supports the use of SagaID.

5. 5. The system of claim 4, wherein if for some reason the system determines that the transaction must be rolled back by performing a compensation operation, appropriate compensation can be made in the database itself using the information including the Saga ID associated with the service and stored in the database.

6. 1. A method for using a reactive messaging client in a microservices environment, comprising: In relation to a microservices environment for use in software applications, providing a reactive engine that provides reactive messaging APIs and operators that can be used with reactive streams for use in long-running activities or other types of transactions related to microservices, the reactive messaging APIs and operators enabling client and server applications to communicate within the microservices environment; A method comprising providing one or more messaging connectors adapted to provide publishers and subscribers for channels used for reactive messaging with services and / or server applications.

7. The method of claim 6 , wherein the microservices environment is a Helidon environment for use in one or more cloud computing or other environments.

8. The method of claim 6 , wherein the system supports the use of microservices architectural patterns for implementing transactions, such as the Saga pattern.

9. 9. The method of claim 8, wherein the Saga pattern operates such that persistent state / events associated with transactions and services are persisted or stored locally in a database that supports the use of SagaID.

10. 10. The method of claim 9, wherein if for any reason the system determines that the transaction must be rolled back by performing a compensation operation, appropriate compensation can be made in the database itself using the information stored in the database associated with the service, including the SagaID.

11. A non-transitory computer-readable storage medium having stored thereon instructions that, when read and executed by one or more computers, cause the one or more computers to perform steps, the steps including: In relation to a microservices environment for use in software applications, providing a reactive engine that provides reactive messaging APIs and operators that can be used with reactive streams for use in long-running activities or other types of transactions related to microservices, the reactive messaging APIs and operators enabling client and server applications to communicate within the microservices environment; A non-transitory computer-readable storage medium comprising providing one or more messaging connectors adapted to provide publishers and subscribers of channels used for reactive messaging with services and / or server applications.

12. 12. The non-transitory computer-readable storage medium of claim 11, wherein the microservices environment is a Helidon environment for use in one or more cloud computing or other environments.

13. 12. The non-transitory computer-readable storage medium of claim 11, wherein the system supports the use of a microservices architectural pattern for implementing transactions, such as the Saga pattern.

14. 14. The non-transitory computer-readable storage medium of claim 13, wherein the Saga pattern operates such that persisted state / events related to transactions and services are persisted or stored locally in a database that supports the use of SagaID.

15. 15. The non-transitory computer-readable storage medium of claim 14, wherein if for some reason the system determines that the transaction must be rolled back by performing a compensation operation, the appropriate compensation can be made in the database itself using the information including the SagaID associated with the service and stored in the database.

Images