Systems and methods for a reactive messaging client for use in a microservices environment

Abstract

According to embodiments, systems and methods are described herein 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, systems can include a reactive messaging API for long-running activities or other types of transactions associated with microservices, which enables the systems to additionally support various reactive messaging features, such as, for example, transaction handling, asynchronous messaging, use of reactive streams or messaging channels in the microservices environment.

Description

[0001] Copyright Notice

[0002] This patent document contains copyrighted material. The copyright holder does not object to any fax reproduction of the patent document or patent disclosure as it appears in the patent documents or records of the Patent and Trademark Office, but otherwise retains all copyright.

[0003] Priority claims:

[0004] This application claims priority to U.S. Provisional Application No. 63 / 009,954, filed April 14, 2020, entitled “SYSTEM AND METHOD FOR REACTIVEMESSAGING CLIENT FOR USE WITH A MICROSERVICES ENVIRONMENT”, which is incorporated herein by reference. Technical Field

[0005] The embodiments described herein are generally related to cloud computing and other computing environments, software development, and microservice architectures, and are particularly directed to systems and methods for enabling the use of reactive messaging clients in microservice environments. Background Technology

[0006] Microservice architecture has become popular for developing software applications that will be provided as cloud services in a cloud computing environment. Such an environment allows software applications to be presented as a loosely coupled collection of services that can be deployed independently and communicate with each other over a network. Summary of the Invention

[0007] According to embodiments, this document 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 long-running activities or other types of transactions associated with microservices, enabling the system to additionally support various reactive messaging features, such as the use of transaction processing, asynchronous messaging, reactive streaming, or messaging channels in a microservices environment. Attached Figure Description

[0008] Figure 1 The illustration depicts an example microservice environment that provides a development framework (such as Helidon) according to an embodiment.

[0009] Figure 2 The illustration depicts an example Helidon SE microservice environment according to an embodiment.

[0010] Figure 3 The illustration depicts an example Helidon MP microservice environment according to an embodiment.

[0011] Figure 4 The illustration depicts an example microservice environment that enables one or more cloud, database, or other integrations according to an embodiment.

[0012] Figure 5 The illustration shows the use of a database client in a microservices environment according to an embodiment.

[0013] Figure 6 The illustration depicts the use of a remote procedure call framework (such as the gRPC framework) in a microservices environment according to an embodiment.

[0014] Figure 7 The illustration further illustrates the use of a database client in a microservices environment according to an embodiment.

[0015] Figure 8 The illustration depicts the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0016] Figure 9 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0017] Figure 10 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0018] Figure 11 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0019] Figure 12 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0020] Figure 13 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0021] Figure 14 The illustration depicts a process of using reactive messaging in a microservices-oriented environment according to an embodiment. Detailed Implementation

[0022] As mentioned above, microservice architecture has become popular for developing software applications that are to be provided as cloud services in cloud computing environments. Such environments can present software applications as a collection of loosely coupled services that can be deployed independently and communicate with each other over a network in a service-oriented architecture.

[0023] Software development frameworks such as Helidon facilitate the development of microservices. For example, Helidon offers a Standard Edition (SE) and MicroProfile (MP) programming models or environments, each providing a collection of software libraries that can be used to provide software developers with the foundation for creating microservices, including features such as configuration, security, and web server functionality.

[0024] The technological advantages offered by such environments include reducing the need for software developers to program according to specific tools or deployment models, and enabling the running of microservices without the need for application servers. Microservice libraries can interoperate with other software development, deployment, and monitoring tools, such as Docker, Kubernetes, Prometheus, or OpenTracing.

[0025] Microservices Environment (Helidon)

[0026] Figure 1 The illustration depicts an example microservice environment that provides a development framework according to an embodiment, such as Helidon, for example.

[0027] like Figure 1 As shown, according to an embodiment, the microservice environment (microservice library) 100 may be provided as one or more software libraries, such as, for example, the Helidon SE or Helidon MP programming model or environment.

[0028] According to an embodiment, Figure 1 The components and processes shown herein, as well as those further described herein with respect to various other embodiments, can 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 can be provided by a cloud computing system or other suitably programmed computer system.

[0029] According to an embodiment, the Helidon SE environment 110 may include various libraries, application programming interfaces (APIs), or other components, such as, for example, a reactive web server 111 that provides asynchronous and reactive APIs for creating web applications; a configuration API 112 that provides a Java API to load and process configuration attributes in key / value form into configuration objects, which applications can then use to retrieve configuration data; and a security component 113 that provides authentication, authorization, and outbound security; and may also include metrics 114, health checks 115, and tracking 116, or other components.

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

[0031] Helidon Standard Edition (SE)

[0032] Figure 2 The illustration depicts an example Helidon SE microservice environment according to an embodiment.

[0033] like Figure 2 As shown in the examples, the Helidon SE environment supports a functional programming style that directly utilizes web servers, security, and configuration components; provides software developers with transparency and control; and supports Java features such as reactive streaming, asynchronous, and functional programming. The Helidon SE environment provides a framework through which software developers can build lightweight reactive microservices.

[0034] Helidon MP (MP)

[0035] Figure 3 The illustration depicts an example Helidon MP microservice environment according to an embodiment.

[0036] like Figure 3 As shown, according to an embodiment, the Helidon MP environment supports a more declarative programming style by using a family of MicroProfiles for the API built on top of the Helidon library. MicroProfile definitions (e.g., specified by the Eclipse MicroProfile project) can be used to support application portability across multiple MicroProfile runtimes.

[0037] Integration with cloud, database or other systems / services

[0038] Figure 4 The illustration depicts an example microservice environment that supports one or more clouds, databases, or other integrations according to an embodiment.

[0039] like Figure 4As shown, according to an embodiment, a microservice environment enables a client (computer) device 150 with 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 local systems or services.

[0040] For example, according to an embodiment, when used with an enterprise application environment, microservices can be used to interact with, connect to, transform, or display data from various enterprise application software products (such as, for example, the Oracle Fusion Application Environment); or to communicate with enterprise server applications, databases, or other environments (such as, for example, the Oracle Database Environment or the Oracle Coherence Environment).

[0041] Database client for microservice environments

[0042] According to embodiments, microservice environments such as Helidon SE can be used to develop non-blocking reactive web server implementations. In such environments, a smaller number of threads can handle a larger load due to the reactive nature of the implementation. However, if the web server or client application needs to communicate with the database using blocking methods such as JDBC, this requires locking threads in the reactive web server or client application, which can lead to performance issues in the reactive application.

[0043] According to embodiments, a microservices environment such as Helidon SE may include a database client and a database client API that provides a unified reactive API for communicating, accessing, retrieving data, and generally working with a database in a non-blocking manner. The database client can operate with a database driver and may include a thread pool and control any blocking of threads, while the database client API itself is used by software developers in a non-blocking manner, for example, in conjunction with a JDBC driver in a blocking reactive client application. Because the database client performs database operations only when requested, it reduces backpressure; it also supports features such as metrics, tracing, health, and security.

[0044] Figure 5 The illustration shows the use of a database client in a microservice environment according to an embodiment.

[0045] like Figure 5As shown, according to an embodiment, database client 200 can operate with various database drivers (e.g., JDBC driver 204 or MongoDB Reactive Streams Java driver 206) to enable access to one or more database environments through client application 202; and similar operations can be performed on SQL and NoSQL databases, so the API can support CRUD operations regardless of whether the database used in the backend is an Oracle JDBC database or a MongoDB database.

[0046] According to an embodiment, by moving native query code to a configuration file, the database client allows client applications to use another database by changing the configuration associated with the database client. For example, the database client can be configured with:

[0047] Source: JDBC or MongoDB

[0048] connection: Database connection parameters

[0049] statements: Named statements when used

[0050] According to the embodiment, the database client API can provide methods to run statements with parameters and retrieve the results of statement execution. In SQL statements, ordered or named parameters can be represented as ? or ?, respectively. <name>,For example:

[0051] SELECT name FROM Pokemons WHERE id=?

[0052] SELECT name FROM Pokemons WHERE id=:id

[0053] According to an embodiment, a statement can be executed by calling the execute() method after setting the statement parameters; this method returns a CompletionStage. <r>, where R is the result of the statement execution. The following example illustrates a JDBC query with ordered parameters that is not executed within a transaction:

[0054] The following example illustrates a JDBC query with named parameters running within a transaction:

[0055] According to an embodiment, a microservice (e.g., Helidon) environment can support the use of a remote procedure call (RPC) framework or component, such as gRPC, which enables client and server applications to communicate within the microservice environment to build a connected system.

[0056] Figure 6 The illustration depicts the use of a remote procedure call framework, such as the gRPC framework, in a microservices environment according to an embodiment.

[0057] like Figure 6 As shown, according to an embodiment, the gRPC framework provides an environment or API 208 that enables service connectivity and supports advanced features such as load balancing, tracing, health checks, and authentication.

[0058] Generally, the gRPC framework uses a protocol buffer as its interface definition language (IDL) and message exchange format, enabling the definition of services and methods that can be invoked remotely. The computer server runs the gRPC server (GrpcServer) to handle client calls via a local object (stub) on the client side. This allows client applications to directly call methods on the server application as if they were local objects. Clients and servers can communicate with each other in various types of environments and supported languages, such as Java, Ruby, Android, Swift, or other types of languages.

[0059] 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 the incoming request, executing the service methods, and encoding the service response. On the client side, the client uses its local object (terminal object) that implements the same methods as the service, whereby the client can call those methods on the local object, thereby wrapping the parameters for the call in an appropriate protocol buffer message type, which is then provided by gRPC as a request to the server.

[0060] Figure 7 The illustration further illustrates the use of a database client in a microservices environment according to an embodiment.

[0061] like Figure 7 As shown, according to an embodiment, a microservice environment (microservice library) allows client applications (such as database clients as described above) to access and communicate with microservices or interact with the cloud, database, or other systems or services to access data, process transactions, or perform other operations associated with those systems or services.

[0062] Reactive messaging client

[0063] According to an embodiment, the system may include a reactive messaging API for long-running activities or other types of transactions associated with microservices, which enables the system to additionally support various reactive messaging features, such as the use of transaction processing, asynchronous messaging, reactive streaming, or messaging channels in a microservices environment.

[0064] Figure 8 The illustration depicts the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0065] like Figure 8 As shown, 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 in a microservices environment.

[0066] According to an embodiment, the system includes one or more messaging connectors (connectors) 212 adapted to provide publishers and subscribers with channels used in reactive messaging with services and / or server applications. For example, as further described below, connectors may be provided to support reactive messaging clients using Kafka, JMS, Oracle Advanced Queues (Oracle AQ, AQ), which provide messaging queuing services used by Oracle databases, or other types of messaging, database, or server environments.

[0067] Figure 9 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0068] like Figure 9 As shown, according to an embodiment, a microservice environment (e.g., a Helidon MP environment) may include a reactive messaging API 230 for use by a (reactive messaging) client application 220 when accessing or communicating with microservices or interacting with the cloud, database, or other systems or services to handle transactions associated with those systems or services.

[0069] According to the embodiments, in a transactional environment, communication with microservices is generally message-based or event-based. For example, as part of a transaction, the first method or service invoked may be associated with the second method or service invoked; subsequently, for example, a third or subsequent method or service may be used.

[0070] According to an embodiment, by enabling client applications to execute in a reactive manner, the application can determine, for example, how many messages it should receive at a specific time, or how many threads it needs to process those messages; and which operations to perform to reduce back pressure in the client application.

[0071] Figure 10 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0072] like Figure 10 As shown in the embodiments, reactive messaging APIs can also be developed for use in other microservice environments, such as, for example, the Helidon SE environment.

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

[0074] Figure 11 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0075] According to embodiments, traditional transactional application environments can utilize two-phase commit and the XA protocol, which involve synchronous communication, resource locking, and recovery via rollback. However, this approach generally does not scale well in microservice environments due to the latency of held locks.

[0076] like Figure 11 As shown, according to an embodiment, the system supports the use of a microservices architecture pattern to implement transactions, such as features of AQ or other database (DB) environments 240, which can use asynchronous communication and local resources, and support recovery through compensatory actions. This approach scales well and is well-suited to support long-running activities and transactions in a microservices environment.

[0077] According to an embodiment, a reactive messaging client can be developed as an implementation defined by MicroProfile, such as that specified in the Eclipse MicroProfile project.

[0078] According to an embodiment, the system supports the use of long-running activities, such as those described by the Eclipse MicroProfile Long-Running Activity (LRA) API, which enables loosely coupled services to coordinate long-running activities.

[0079] According to the embodiments, the system can support the operation of LRAAPI by using a microservice architecture pattern (such as the saga pattern), similar to how the Java Transaction API may support two-phase commit and XA in a traditional transaction application environment.

[0080] Generally, according to embodiments, the saga pattern can be used to enable business transactions to span multiple services, such as e-commerce applications operating under multiple billing or other transaction services. In such environments, the data required for a particular transaction may be controlled by different services or stored in different databases, preventing the use of a conventional two-phase commit process. The saga pattern allows transactions to be executed as a series of local transactions, where each local transaction updates the database and publishes a message or event to trigger 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.

[0081] like Figure 11 As further shown in the embodiment, the saga mode operates such that persistent state / events 250 associated with transactions and services can be persisted or stored locally 244, for example in a database such as an AQ database that supports the use of saga identifiers (saga ids).

[0082] Figure 12 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0083] like Figure 12 As shown, according to an embodiment, multiple microservices (A, B, C) can register in a long-running activity associated with a transaction so that the transaction can be committed when the time arrives, with each microservice committing.

[0084] According to an embodiment, if the system determines, through performing compensation actions, that a transaction must be rolled back for some reason, then information including the saga ID associated with the service and stored in the database can be used to perform appropriate compensation at the database itself; rather than, for example, a failure requirement in a service or causing each service to run its own compensation log. The database environment itself can determine, based on the saga ID, what appropriate compensation it needs to perform in order to repair the transaction.

[0085] Figure 13 The illustration further illustrates the use of a reactive messaging client in a microservices-oriented environment according to an embodiment.

[0086] like Figure 13 As shown in the embodiments, the reactive messaging API can also be used with microservice-enabled AQ environments or other microservice environments (such as, for example, Helidon SE environments).

[0087] Figure 14 The illustration depicts a process of using reactive messaging in a microservices-oriented environment according to an embodiment.

[0088] like Figure 14 As shown, according to an embodiment, at step 262, a microservice environment (microservice library) is provided at a computer including one or more processors and memory, which provides a development framework that enables software developers to create and use microservices.

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

[0090] At step 266, one or more messaging connectors are provided, which are adapted to provide publishers and subscribers with channels for use in reactive messaging with services and / or server applications.

[0091] At step 268, the system enables communication between the client and the service and / or server applications via the reactive messaging API and one or more connectors.

[0092] Reactive messaging engine (Reactive Engine)

[0093] As described above, according to an embodiment, the system includes a reactive engine that provides a reactive messaging API and operators that can be used with reactive streams to enable client and server applications to communicate within a microservices environment.

[0094] For example, according to an embodiment, the reactive engine provides a set of operators that can be used with reactive streams based on java.util.concurrent.Flow. In this embodiment, a chain of stream processing operators can be constructed either using io.helidon.common.reactive.Multi for streams with multiple values ​​or using io.helidon.common.reactive.Single for streams with a single value. According to an embodiment, the following describes an example of using a chain of multiple stream processing operators:

[0095]

[0096] According to the embodiment, the following describes an example of using a single stream processing operator chain:

[0097]

[0098] Table 1 illustrates examples of reactive operators supported by the system according to embodiments. The examples provided are for illustrative purposes only; other types of reactive operators may be supported according to various embodiments.

[0099]

[0100]

[0101]

[0102] Table 1

[0103] Operator chain

[0104] According to the embodiment, when it is necessary to prepare part of the operator chain in advance, the choice between the `compose` and `to` operators can be used. According to the embodiment, the following is an example of combining operator chains:

[0105]

[0106] According to an example, in order to enable the reactive engine to be used with a software project, the following dependencies can be declared in the project:

[0107] <dependency>

[0108] <groupid> io.helidon.common< / groupid>

[0109] <artifactid> helidon-common-reactive< / artifactid>

[0110] < / dependency>

[0111] Reactive flow operators

[0112] According to an embodiment, the system provides an implementation of the MicroProfile ReactiveStreams Operators Specification prepared by the Eclipse Foundation; it defines a standardized method for manipulating data with reactive streams, operators used in conjunction with stages, and a graph using builders to prepare stages from which streams can be constructed. According to the embodiment, the following describes an example of the use of closed graphs:

[0113] AtomicInteger sum=new AtomicInteger();

[0114] ReactiveStreams.of("1","2","3","4","5")

[0115] .limit(3)

[0116] .map(Integer::parseInt)

[0117] .forEach(sum::addAndGet)

[0118] .run()

[0119] .whenComplete((r,t)->System.out.println("Sum:"+sum.get()));

[0120] Sum:6

[0121] Table 2 illustrates examples of supported operators used with stages according to embodiments. The examples provided are for illustrative purposes only; other types of reactive operators may be supported according to various embodiments.

[0122]

[0123]

[0124]

[0125] Table 2

[0126] picture

[0127] According to an embodiment, the graph is a pre-prepared flow builder with stages that can be combined to form a closed graph with methods via and to. According to an embodiment, the following illustrates an example of a combined graph and a running flow:

[0128]

[0129]

[0130] According to an example, in order to enable the use of MicroProfile reactive streams (as defined by the MicroProfile Reactive Streams Operators Specification) in a software project, the following dependencies can be declared in the project:

[0131] <dependency>

[0132] <groupid> io.helidon.microprofile.reactive-streams< / groupid>

[0133] <artifactid> helidon-microprofile-reactive-streams< / artifactid>

[0134] < / dependency>

[0135] ****

[0136] Helidon SE Reactive Messaging

[0137] As described above, according to the embodiments, a microservice environment (microservice library) can be provided as one or more software libraries, such as, for example, the Helidon SE programming model or environment.

[0138] Asynchronous messaging is a common form of communication in microservice environments. While it is possible to directly build reactive streams by combining operators and connecting them to a reactive API, the system provides additional tools to address various use cases, depending on the implementation.

[0139] For example, connecting streams to external services often requires a significant amount of boilerplate code for configuration handling, backpressure propagation, acknowledgments, etc. According to embodiments, to support such tasks, the system provides multiple connectors, transmitters, and orchestration mechanisms. When provided as a reactive messaging API, the system allows connectors and transmitters to be connected and configured via channels using reactive streams.

[0140] According to embodiments, embodiments of systems supporting Helidon SE reactive messaging support the same configuration format as the connectors that are its MicroProfile peers. For example, the Helidon MP connector can be used for Helidon SE reactive messaging, but with some limitations (e.g., there is no CDI in Helidon SE).

[0141] aisle

[0142] According to an embodiment, a channel is a pair of named Publishers and Subscribers. Channels can be connected together via processors. Registration of the channel's Publisher or Subscriber can be provided by a reactive messaging API, or it can be implicitly configured to use a registered connector to generate such Publishers or Subscribers. According to an embodiment, the following describes an example of a simple channel configuration:

[0143] Channel <string>channel1=Channel.create("channel1");

[0144] Messaging.builder()

[0145] .publisher(channel1,Multi.just("message 1","message 2")

[0146] .map(Message::of))

[0147] .listener(channel1,s->System.out.println("Intecepted message"+s))

[0148] .build()

[0149] .start();

[0150] processor

[0151] According to the embodiment, the processor operates as a typical reactive processor because it acts as the Subscriber for the upstream component and the Publisher for the downstream component. In terms of reactive messaging, the processor can connect two channels to a reactive stream. The following describes an example of processor usage according to the embodiment:

[0152]

[0153]

[0154] information

[0155] According to an embodiment of a system supporting Helidon SE reactive messaging, the system uses the same message wrapping concept as MicroProfile messaging; the difference is that SE reactive messaging provides almost no implicit or automatic acknowledgments. Another difference lies in the variants of the `Messaging.Builder#listener` and `Messaging.Builder#processor` methods and the consumer or function parameters, which can conveniently expand the payload. Since manual acknowledgments are not possible after such implicit expansion, it is necessary to perform implicit acknowledgments (acks) before executing callbacks.

[0156] Message Connector

[0157] As described above, according to an embodiment, the system includes one or more messaging connectors adapted to provide publishers and subscribers with channels for use in reactive messaging with services and / or server applications.

[0158] For example, according to embodiments, the system may include a connector that provides a component or connection channel to an external source. To make connector creation and use as simple and universal as possible, embodiments of systems supporting Helidon SE reactive messaging use the same API for connectors as MicroProfile reactive messaging. This allows connectors to be used in both variants of Helidon (although, as indicated above, there is a limitation that connectors must be able to function without CDI). Examples of such connectors include the Kafka connector; the JMS connector; and / or the AQ connector, examples of which are further described below.

[0159] According to an example, in order to enable the use of reactive messaging in a software project, the following dependencies can be declared in the project:

[0160] <dependency>

[0161] <groupid> io.helidon.messaging< / groupid>

[0162] <artifactid> helidon-messaging< / artifactid>

[0163] < / dependency>

[0164] According to an embodiment, a message connector for reactive messaging can be provided as a factory that generates publishers and subscribers for the channels used in reactive messaging. The message connector can be provided as an IncomingConnectorFactory, an OutgoingConnectorFactory, or both. According to an embodiment, an example connector—example-connector—is described below:

[0165]

[0166]

[0167] According to an embodiment, the following describes an example of a channel-to-connector mapping configuration:

[0168] mp.messaging.outgoing.to-connector-channel.connector:example-connector

[0169] mp.messaging.incoming.from-connector-channel.connector:example-connector

[0170] According to an embodiment, the following describes an example of generating messages to the connector:

[0171]

[0172] According to an embodiment, the following describes an example of consuming messages from the connector:

[0173]

[0174]

[0175] Configuration

[0176] According to embodiments of systems supporting Helidon SE reactive messaging, the messaging connector can be explicitly configured either by an API or implicitly configured by configuration symbols for MicroProfile reactive messaging. When the configuration is supplied to the connector by the messaging implementation, there are two mandatory attributes:

[0177] The channel-name name of the channel with this connector, which is configured as a publisher or subscriber, such as Channel.create('name-of-channel') in explicit configuration or mp.messaging.incoming.name-of-channel.connector:channel-name in implicit configuration.

[0178] The connector name is specified by the connector name: @Connector("connector-name")

[0179] According to an embodiment, the following describes an example of connector access configuration:

[0180]

[0181]

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

[0183] Explicit configuration

[0184] According to an embodiment, explicit configuration can be provided for the channel publisher using `Channel.Builder#publisherConfig(Config config)`, and explicit configuration can be provided for the channel subscriber using `Channel.Builder#subscriberConfig(Config config)`. The configuration provided by Helidon is merged with enforced attributes and any implicit configurations found. The resulting configuration is then provided to the connector. According to an embodiment, the following illustrates an example of consuming messages from a Kafka connector using explicit configuration:

[0185]

[0186]

[0187] According to the embodiments, the above examples illustrate how the system can be used to: prepare channels for connecting Kafka connectors to specific publisher configurations → listeners; provide configuration channel → connector mappings, which is automatic when using KafkaConnector.configBuilder(); and prepare Kafka connectors that can be used by any channel.

[0188] Implicit configuration

[0189] According to an embodiment, implicit configuration without any hard-coded information can be provided according to the notation of MicroProfile reactive messaging. According to an embodiment, the following describes an example of a channel-to-connector mapping configuration with custom attributes:

[0190] mp.messaging.incoming.from-connector-channel.connector:example-connector

[0191] mp.messaging.incoming.from-connector-channel.first-test-prop:foo

[0192] mp.messaging.connector.example-connector.second-test-prop:bar

[0193] According to the embodiments, the above examples illustrate how the system can be used to: provide channel-to-connector mapping; provide channel configuration features; and provide connector configuration features.

[0194] According to an embodiment, the following describes an example of consuming messages from the connector:

[0195]

[0196] Reusability in MP Message Passing

[0197] According to the embodiment, since the reactive messaging API is the same for the MicroProfile reactive messaging connector, all that's needed to make the connector work in both environments is to annotate it with @ApplicationScoped. This connector can be considered a bean in Helidon MP.

[0198] ****

[0199] Reactive Kafka Connector

[0200] According to an embodiment of a system that supports Helidon SE reactive messaging, the system can be used to connect streams to a Kafka environment with reactive messaging, as described below.

[0201]

[0202]

[0203] Explicit configuration (configuration builder)

[0204] Based on an embodiment, the following describes an example of how a system can be explicitly configured to consume messages from a Kafka environment:

[0205]

[0206]

[0207] According to the embodiments, the above examples illustrate how the system can be used to: prepare channels for connecting Kafka connectors to specific publisher configurations → listeners; when using KafkaConnector.configBuilder(), the channel → connector mapping is automatic; and prepare Kafka connectors that any channel can use.

[0208] Based on an embodiment, the following illustrates an example of how a system can be explicitly configured to produce messages to a Kafka environment:

[0209]

[0210] According to the embodiments, the above examples illustrate how the system can be used to: prepare channels for connecting Kafka connectors to specific publisher configurations → listeners; when using KafkaConnector.configBuilder(), the channel → connector mapping is automatic; and prepare Kafka connectors that any channel can use.

[0211] Implicit (Helidon) Configuration

[0212] Based on an embodiment, the following illustrates an example of how a system can be implicitly configured to operate with Kafka:

[0213]

[0214] Based on an embodiment, the following illustrates an example of how a system can be implicitly configured to use messages from a Kafka environment:

[0215]

[0216] According to the embodiments, the above examples illustrate how the system can be used to: prepare Kafka connectors that can be used by any channel.

[0217] Based on an embodiment, the following illustrates an example of how a system can be implicitly configured to produce messages to a Kafka environment:

[0218]

[0219] According to the embodiments, the above examples illustrate how the system can be used to: prepare Kafka connectors that can be used by any channel.

[0220] ****

[0221] Reactive JMS Connector

[0222] According to an embodiment of a system that supports Helidon SE reactive messaging, the system can be used to connect streams to a JMS environment with reactive messaging, as described below.

[0223]

[0224] Explicit configuration (configuration builder)

[0225] According to an embodiment, the following describes an example of how the system can be explicitly configured to use messages from a JMS environment:

[0226]

[0227]

[0228] According to the embodiments, the above examples illustrate how the system can be used to: prepare channels for connecting JMS connectors to specific publisher configurations → listeners; when using JmsConnector.configBuilder(), channel → connector mapping is automatic; and prepare JMS connectors that any channel can use.

[0229] According to an embodiment, the following describes an example of how the system can be explicitly configured to generate messages to a JMS environment:

[0230]

[0231]

[0232] According to the embodiments, the above examples illustrate how the system can be used to: prepare channels for connecting JMS connectors to specific publisher configurations → listeners; when using JmsConnector.configBuilder(), channel → connector mapping is automatic; and prepare JMS connectors that any channel can use.

[0233] Implicit (Helidon) Configuration

[0234] According to an embodiment, the following describes an example of how the system can be implicitly configured to operate with JMS:

[0235]

[0236]

[0237] According to an embodiment, the following describes an example of how a system can be (implicitly) configured to use messages from a JMS environment:

[0238]

[0239] According to the embodiments, the above examples illustrate how the system can be used to: prepare a JMS connector that can be used by any channel.

[0240] According to an embodiment, the following describes an example of how a system can be (implicitly) configured to generate messages to a JMS environment:

[0241]

[0242]

[0243] According to the embodiments, the above examples illustrate how the system can be used to: prepare a JMS connector that can be used by any channel.

[0244] ****

[0245] Reactive Oracle AQ Connector

[0246] According to an embodiment of a system that supports Helidon SE reactive messaging, the system can be used to connect streams to an AQ environment with reactive messaging, as described below.

[0247]

[0248] Sending and receiving

[0249] According to an embodiment, the following describes an example of how to configure the system to generate and consume messages going to / from the AQ environment:

[0250]

[0251]

[0252] According to the embodiments, the above examples illustrate how the system can be used to: prepare Oracle UCP; set up the AQ connector and provide the identifier test-ds for the data source; set up a channel with the data source test-ds to send messages to the queue example_queue_1; set up a channel with the data source test-ds to receive messages from the queue example_queue_1; register the connector and channel; add publishers for several test messages to immediately publish them to example_queue_1; and subscribe to callbacks for any messages from example_queue_1.

[0253] ****

[0254] Helidon MP Reactive Message Passing

[0255] As described above, according to the embodiments, a microservice environment (microservice library) can be provided as one or more software libraries, such as, for example, the Helidon MP programming model or environment.

[0256] According to an embodiment, MicroProfile reactive messaging uses CDI beans to produce, consume, or process messages on a reactive stream. Such messaging beans are expected to be either ApplicationScoped or Dependent. Messages are managed by methods annotated with @Incoming and @Outgoing, and calls are always driven by the message core—whether at assembly time or for each message from the stream. Beans can have methods annotated with @Incoming, @Outgoing, or both.

[0257]

[0258] Table 3

[0259] Consumption methods annotated with @Incoming

[0260] According to the embodiment, the annotation has a required attribute `value` that defines the channel name. This annotated messaging method can function in two ways: consuming each message from a stream connected to the channel; or preparing subscribers to a reactive stream and connecting them to the channel.

[0261] According to the embodiment, the following describes an example of consuming each message from channel example-channel-2:

[0262] @Incoming("example-channel-2")

[0263] public void printMessage(String msg){

[0264] System.out.println("Just received message:"+msg);

[0265] }

[0266] According to the embodiment, the following describes an example of preparing a reactive streaming subscriber for channel example-channel-1:

[0267]

[0268] Methods for generating the @Outgoing annotation

[0269] According to the embodiment, the annotation has a required attribute `value` that defines the channel name. This annotated messaging method can function in two ways: either by generating an exact message for a stream connected to the channel; or by preparing a reactive stream publisher and connecting it to the channel.

[0270] According to the embodiment, the following describes an example of generating a specific message for channel example-channel-1:

[0271]

[0272] According to the embodiment, the following describes an example of preparing to publish three messages to a reactive stream publisher on channel example-channel-1:

[0273]

[0274]

[0275] Processing methods with @Incoming and @Outgoing annotations

[0276] According to embodiments, such methods act as processors, consuming messages from one channel and producing messages to another. This annotated messaging method can function in several ways: processing each message; preparing processors for reactive streams and connecting them between channels; or preparing a new publisher on each message (equivalent to the flatMap operator).

[0277] According to an embodiment, the following describes an example of processing each message from channel example-channel-1 to the following channels:

[0278]

[0279] According to an embodiment, the following describes an example of a processor stream to be connected between the following channels:

[0280]

[0281] According to an embodiment, the following describes an example of processing each message from channel "example-channel-1" as a stream to be flattened into channel "example-channel-2":

[0282] According to an example, in order to enable the use of reactive messaging in a software project, the following dependencies can be declared in the project:

[0283]

[0284] Health check

[0285] According to an implementation, messaging in Helidon includes built-in health probes for activity and readiness. To activate it, the following dependency can be declared in the project:

[0286] According to the embodiments, the above examples illustrate how the system can be used to provide: an activity level - a channel is considered UP until a cancel or onError signal is intercepted on it; and a readiness level - a channel is considered DOWN until an onSubscribe signal is intercepted on it. By inspecting the health endpoints / health / live and / health / ready, it can be seen that each messaging channel has its own probe.

[0287]

[0288]

[0289] information

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

[0291]

[0292] confirm

[0293] According to the implementation, the message carries a callback for receiving acknowledgments. Acknowledgments in the messaging method may be performed manually via `org.eclipse.microprofile.reactive.messaging.Message#ack` or automatically by the messaging core according to an explicit or implicit acknowledgment strategy. Explicit strategy configuration can be provided by the `@Acknowledgment` annotation, which has a required attribute `value`, the value of which is expected to come from the strategy type enumeration `org.eclipse.microprofile.reactive.messaging.Acknowledgment.Strategy`.

[0294] Table 4 illustrates examples of the verification strategy according to the embodiments.

[0295]

[0296] Table 4 illustrates examples of manual verification based on the embodiments:

[0297]

[0298]

[0299] Calling ack() will print "This particular message has been acknowledged!" to System.out. The following is an example of manual acknowledgment, as described in the implementation:

[0300]

[0301] Calling ack() will print "This particular message has been acknowledged!" to System.out. The following example illustrates explicit acknowledgment before processing, according to an implementation:

[0302]

[0303]

[0304] According to the embodiments, the following describes an example of confirmation after explicit processing:

[0305]

[0306] Message Connector Bean

[0307] According to an embodiment, the message connector can be provided as a bean that implements the application scope of IncomingConnectorFactory, OutgoingConnectorFactory, or both.

[0308] According to an embodiment, the following describes an example connector:

[0309]

[0310] According to an embodiment, the following describes an example of a channel-to-connector mapping configuration:

[0311] mp.messaging.outgoing.to-connector-channel.connector:example-connector

[0312] mp.messaging.incoming.from-connector-channel.connector:example-connector

[0313] According to an embodiment, the following describes an example of generating messages to the connector:

[0314]

[0315] According to an embodiment, the following describes an example of consuming messages from the connector:

[0316]

[0317] Configuration

[0318] According to an embodiment, the following describes an example connector access configuration:

[0319]

[0320]

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

[0322] According to an embodiment, the following describes an example of a channel-to-connector mapping configuration with custom features:

[0323] mp.messaging.incoming.from-connector-channel.connector:example-connector

[0324] mp.messaging.incoming.from-connector-channel.first-test-prop:foo

[0325] mp.messaging.connector.example-connector.second-test-prop:bar

[0326] According to the embodiments, the above examples illustrate how the system can be used to: provide channel-to-connector mapping; provide channel configuration features; and provide connector configuration features.

[0327] According to an embodiment, the following describes an example of consuming messages from the connector:

[0328]

[0329] ****

[0330] Reactive Kafka Connector

[0331] According to an embodiment of a system that supports Helidon MP reactive messaging, the system can be used to connect streams to a Kafka environment with reactive messaging, as described below.

[0332]

[0333] According to an embodiment, the following describes an example of connector configuration:

[0334]

[0335]

[0336] According to the embodiment, the following describes an example of consuming messages from a Kafka environment:

[0337]

[0338] According to the embodiment, the following is an example of generating messages to a Kafka environment:

[0339]

[0340] ****

[0341] Reactive JMS Connector

[0342] According to an embodiment of a system that supports Helidon MP reactive messaging, the system can be used to connect streams to a JMS environment with reactive messaging, as described below.

[0343]

[0344]

[0345] Configuration

[0346] According to the embodiments, Table 5 illustrates examples of attributes that can be used with the connector name: helidon-jms.

[0347]

[0348] Table 5

[0349] Configured JMS factory

[0350] According to an embodiment, a simple use case involves looking up the JMS ConnectionFactory in a naming context. The following describes an example of connector configuration according to an embodiment:

[0351]

[0352] Injected JMS factory

[0353] According to the embodiment, the following describes an example of a more advanced setting, where the connector can work with the injected factory instance, for example:

[0354]

[0355]

[0356] Consumption

[0357] According to the embodiment, the following describes an example of consuming values ​​one by one from the JMS environment using expanded values:

[0358]

[0359] According to the embodiment, the following describes an example of consuming items one by one from a JMS environment using manual confirmation:

[0360]

[0361] produce

[0362] According to an embodiment, the following describes an example of generating messages to a JMS environment:

[0363]

[0364] According to an embodiment, the following describes an example of generating more advanced messages to a JMS environment:

[0365]

[0366] According to the embodiment, the following is another example of using a custom mapper to generate messages to the JMS environment at an advanced level:

[0367]

[0368]

[0369] ****

[0370] Reactive Oracle Advanced Queuing Connector

[0371] According to an embodiment of a system supporting Helidon MP reactive messaging, the system can be used to connect streams to an AQ environment with reactive messaging, as described below. According to an embodiment, this connector can be adapted to extend the Helidon JMS connector with an AQ-specific API.

[0372]

[0373] Configuration

[0374] According to the embodiments, Table 6 illustrates examples of attributes that can be used with the connector name: helidon-aq.

[0375]

[0376]

[0377] Table 6

[0378] Configured JMS factory

[0379] According to an embodiment, a simple use case involves leaving the construction of the AQJMSConnectionFactory to the connector. The following is an example of connector configuration:

[0380]

[0381]

[0382] According to the implementation, the system allows the use or reference of configured data sources, such as, for example, the Oracle Universal Connection Pool (UCP) data source. The following describes an example of connector configuration using an Oracle UCP data source:

[0383]

[0384]

[0385] Injected JMS factory

[0386] According to an embodiment, for more advanced settings, the connector can work with the injected AQJMSConnectionFactory:

[0387]

[0388]

[0389] Consumption

[0390] According to the embodiment, the following describes an example of consumption one by one from the AQ environment, with expanded values:

[0391]

[0392] According to the embodiment, the following describes an example of consumption one by one from the AQ environment, with manual confirmation:

[0393]

[0394] produce

[0395] According to an embodiment, the following describes an example of generating a message to an AQ environment:

[0396]

[0397] ****

[0398] Oracle Advanced Queues (AQ) Example

[0399] Based on the embodiments, the following is another example of using reactive messaging in an AQ environment. In this example, to connect to Helidon MP, we use the MicroProfile reactive messaging implementation, the AQ messaging connector, and Helidon's support for Oracle Universal Connection Pool (UCP) data sources.

[0400]

[0401] In this example, a UCP connection pool is used as the data source for connecting to the Oracle database; this involves first preparing the UCP data source, and then referencing it from the AQ connector configuration using the mp.messaging.connector.helidon-aq.data-source configuration property.

[0402]

[0403]

[0404] Once the UCP data source is set up, we can prepare reactive messaging methods. For example, we can prepare one method to publish messages every 2 seconds to an outgoing channel called to-aq; and another method to consume messages to an incoming channel called from-aq. Both channels are configured for the example-queue-1 destination. The generated messages are used immediately after a short round trip to the Oracle database.

[0405]

[0406]

[0407] According to the embodiment, the AQ connector is fully integrated with the MicroProfile reactive messaging acknowledgment feature. The default acknowledgment mode is AUTO_ACKNOWLEDGE, meaning that each received message is acknowledged immediately after being received by the connector. In the event of a failure during message processing (such as an error between the connector and the stage), the message will not be resent once it is considered successfully consumed. To move actual acknowledgment control to the business code, we can set the acknowledgment mode to CLIENT_ACKNOWLEDGE.

[0408]

[0409] We can leave the acknowledgment to the messaging itself, as each messaging method has an explicitly defined default acknowledgment strategy or requires a manual call to `Message.ack()`. Like other Helidon connectors, the AQ connector works with the HelidonSE reactive messaging API; all that's needed is the AQ connector dependency:

[0410]

[0411] The AQ connector can also be used with SE messaging, for example, by adding a fragment directly to the main method:

[0412]

[0413]

[0414] According to various embodiments, the teachings herein can be conveniently implemented using one or more conventional general-purpose or special-purpose computers, computing devices, machines, or microprocessors (including one or more processors, memory, and / or computer-readable storage media programmed according to the teachings of this disclosure). As will be apparent to those skilled in the art of software, a skilled programmer can readily prepare appropriate software code based on the teachings of this disclosure.

[0415] In some embodiments, the teachings herein may include a computer program product, which is one or more non-transitory computer-readable storage media on which / therein stores instructions that can be used to program a computer to perform any of the processing described herein. Examples of such storage media may include, but are not limited to, hard disk drives, hard drives, fixed disks or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems or other types of storage media or devices suitable for non-transitory storage of instructions and / or data.

[0416] The foregoing description is provided for illustrative purposes. It is not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed. Many modifications and variations will be apparent to those skilled in the art.

[0417] For example, while various embodiments of the systems and methods described herein illustrate use in the Helidon microservices environment, these embodiments can be used with other types of microservices environments or other computing environments.

[0418] These embodiments were chosen and described in order to best illustrate the principles of this teaching and their practical application, thereby enabling others skilled in the art to understand the various embodiments and various modifications suitable for the contemplated practical use. The scope is intended to be defined by the following claims and their equivalents.< / string> < / r> < / name>

Claims

1. A system for using a reactive, asynchronous, and non-blocking messaging client in a microservice environment, comprising: A computer, including one or more processors, that provides access to a microservices environment for use with software applications; The reactive engine provides reactive messaging APIs and operators that can be used with reactive streams to enable reactive client and server applications to communicate reactively within a microservices environment for use with long-running activities or other types of transactions associated with microservices. as well as One or more messaging connectors adapted to provide publishers and subscribers for channels used in reactive messaging with services and / or server applications; Several of these microservices can be registered in long-running activities associated with transactions; The system described above enables transactions to be executed as a series of local transactions, where each local transaction updates the database and publishes a message or event to trigger the next local transaction; The state or events associated with transactions and services are persisted or stored locally in the database for use in committing or rolling back the long-running activities; and If the system determines that the transaction will be rolled back, the information stored in the database can be used to perform appropriate compensation actions at the database to repair the transaction.

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

3. The system as described in claim 1, wherein the system supports the use of a microservice architecture pattern to implement transactions, the microservice architecture pattern including the saga pattern.

4. The system of claim 3, wherein the saga mode operation enables persistent state / events associated with transactions and services to be locally persisted or stored in a database that supports the use of saga identifiers.

5. The system of claim 4, wherein if the system determines that a transaction must be rolled back by performing a compensation action, then information including the saga id associated with the service and stored in the database can be used to perform appropriate compensation in the database itself.

6. A method for using a reactive, asynchronous, and non-blocking messaging client in a microservices environment, comprising: The following are provided in association with a microservices environment for use with software applications: The reactive engine provides reactive messaging APIs and operators that can be used with reactive streams to enable reactive client and server applications to communicate reactively within a microservices environment for use with long-running activities or other types of transactions associated with microservices. as well as One or more messaging connectors adapted to provide publishers and subscribers for channels used in reactive messaging with services and / or server applications; Several of these microservices can be registered in long-running activities associated with transactions; A transaction is executed as a series of local transactions, where each local transaction updates the database and publishes a message or event to trigger the next local transaction; The state or events associated with transactions and services are persisted or stored locally in the database for use in committing or rolling back the long-running activities; and If it is determined that the transaction will be rolled back, the information stored in the database can be used to perform appropriate compensatory actions at the database level to repair the transaction.

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

8. The method of claim 6, wherein, It supports the use of microservice architecture patterns to implement transactions, including the saga pattern.

9. The method of claim 8, wherein the saga pattern operation enables persistent state / events associated with transactions and services to be locally persisted or stored at a database that supports the use of saga identifiers.

10. The method of claim 9, wherein if the system determines that a transaction must be rolled back by performing a compensation action, then information including the saga id associated with the service and stored in the database can be used to perform appropriate compensation in the database itself.

11. A non-transitory computer-readable storage medium comprising instructions stored thereon, the instructions, when read and executed by one or more computers, causing the one or more computers to perform a method for using a reactive, asynchronous, and non-blocking messaging client in a microservices environment, the method comprising: The following are provided in association with a microservices environment for use with software applications: The reactive engine provides reactive messaging APIs and operators that can be used with reactive streams to enable reactive client and server applications to communicate reactively within a microservices environment for use with long-running activities or other types of transactions associated with microservices. as well as One or more messaging connectors adapted to provide publishers and subscribers for channels used in reactive messaging with services and / or server applications; Several of these microservices can be registered in long-running activities associated with transactions; A transaction is executed as a series of local transactions, where each local transaction updates the database and publishes a message or event to trigger the next local transaction; The state or events associated with transactions and services are persisted or stored locally in the database for use in committing or rolling back the long-running activities; and If it is determined that the transaction will be rolled back, the information stored in the database can be used to perform appropriate compensatory actions at the database level to repair the transaction.

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

13. The non-transitory computer-readable storage medium of claim 11, wherein, It supports the use of microservice architecture patterns to implement transactions, including the saga pattern.

14. The non-transitory computer-readable storage medium of claim 13, wherein the saga mode operates such that persistent state / events associated with transactions and services can be locally persisted or stored at a database that supports the use of saga identifiers.

15. The non-transitory computer-readable storage medium of claim 14, wherein if the system determines that a transaction must be rolled back by performing a compensation action, then information including the saga id associated with the service and stored in the database can be used to perform appropriate compensation in the database itself.

Images