The MicroProfile specification aims to propose a standard solution about the management of the transactions in distributed systems as microservices, based on the saga pattern.

The specification is Long Running Actions (LRA) for MicroProfile: it's built by the Narayana team under the Eclipse MicroProfile initiative. Currently, it is in a "in progress" state, and it is one of the main topics under discussion in the community.

It proposes a new API for the coordination of long-running activities: the approach would be totally different from the one implemented, for example, in the Extended Architecture. The target is to guarantee a globally consistent outcome without the need to set locks on data that limits the scalability of the system.

The Narayana LRA implementation is based on the standard specifications provided by Java EE/Jakarta EE and MicroProfile (in particular, Context and Dependency Injection (CDI) and JAX-RS).

Unlike the frameworks we described previously, Narayana (and, in general, the LRA specification) uses an orchestration saga model.

The main actors in Narayana frameworks are as follows:

• LRA coordinator: This manages the saga processing, and can be a standalone service or embedded within an application service. Its main responsibilities are the LRA's initialization, participant enlisting, and either saga completion or compensation.
• Saga participant: This is a service that is involved in the LRA. Each one is required to provide at least one REST endpoint that serves as the compensation handler.

The execution of the LRA operation is done via an invocation to an LRA coordination service. This service responds with a unique identification value related to the initiating service.

When a business service is built by multiple microservices, there is the need to group and coordinate all the actors involved in the functionality. In an LRA implementation, the system enlists the participants with the LRA coordinator, using the ID returned by the coordinator. At the end of the process, either in case of success or in case of failure, one of the participating services that knows the LRA identification (the ID) contacts the coordinator to close (success) or compensate (failure) the LRA. The coordinator performs the corresponding requested action for each enlisted participant.

The participants that are involved in a saga transaction can have two states, as follows:

• Success: The activity has completed successfully, so the participants can consider the transaction closed
• Fail: The activity has completed unsuccessfully, and all participants involved in the LRA must perform compensation in the reverse order

Let's start to implement an example scenario.