anchor.diff:  === Using the LRA Saga Service
   
   The LRA Saga Service is an implementation based on the MicroProfile sandbox LRA specification.
  -It leverages a *external Saga coordinator* to control the execution of the various steps of the Saga.
  +It leverages an *external Saga coordinator* to control the execution of the various steps of the Saga.
   The proposed reference implementation for the LRA specification is the http://jbossts.blogspot.it/2017/12/narayana-lra-implementation-of-saga.html[Narayana LRA Coordinator].
   Users can follows instructions present on the Narayana website to *startup a remote instance of the coordinator*.
   
  
positive.code: 
  So, when the compensating action _direct:cancelOrder_ is called, it may not find the Order record that should be cancelled.
  It is important, in order to guarantee full global consistency, that *any main action and its corresponding compensating action are commutative*,
  i.e. if compensation occurs before the main action it shoud have the same effect.
  
  Another possible approach, when using a commutative behavior is not possible,
  is to consistently fail in the compensating action until data produced by the main action is found (or the maximum number of retries is exhausted):
  
negative.code: == Examples
  
  Suppose you want to place a new order and you have two distinct services in your system: one managing the orders and one managing the credit.
  Logically you can place an order if you have enough credit for it.
  
  With the Saga EIP you can model the _direct:buy_ route as a Saga composed of two distinct actions, one to create the order and one to take the credit.
  *Both actions must be executed, or none of them*: an order placed without credit can be considered an inconsistent outcome (as well as a payment without an order).
  
  [source,java]
  ----
  