Initialize

Starting the saga lib

The lib is started using the provided builder class. It will use default implementations for things like persistence and timeouts if not specified otherwise. The build() method returns an instance ready to be used.

MessageStream msgStream = EventStreamBuilder.configure()
        .usingSagaProviderFactory(sagaProvider)
        .build();

This will start the saga lib with the following default behaviors:

• In-Memory-Storage The state of saga not finished will be stored in a dictionary in memory. The access is thread synchronized. To use a different kind of storage mechanism implement the interface StateStorage and provide an instance on the builders usingStorage method.
• Java Timers When requesting timeouts in memory Java Timers will be used to trigger Timeout messages. To change this behavior implement the interface TimeoutManager and provide an instance on the builders usingTimeoutManager method.
• Classpath Scanning During startup the saga-lib needs a list of all types implementing the Saga interface. By default the current classpath is scanned using the reflections library. This can be changed by creating a custom implementation of TypeScanner and setting the instance on the builders usingScanner method.
• Single Thread Background Executor There are two ways a message can be handled. The first one is synchronously using MessageStream.handle() and asynchronously by calling MessageStream.add(). By default add will put all message handling on a background daemon thread. This behavior can be changed by providing a custom Executor with the usingExecutor method. For example to have a pool of 5 threads doing the work, provide the executor returned from the JDKs Executors.newFixedThreadPool(5) method.

Saga Provider

Something the the user of the saga-lib always has to set is a possibility for the lib to create new instances of the actual saga type. This is done by providing an instance of the SagaProviderFactory interface using the saga-lib builder. This interface is responsible to return a specific Provider<T> when requested, which is capable to create new saga instances. The Provider<T> interface is defined in by JSR-330. Guice as well as Spring both support JSR-330 so it is quite easy to create custom providers. Using JSR-330 has the benefit that the lib does not depend on a specific dependency injection (DI) framework and still allows developers to use DI techniques like constructor injection for saga implementations.

The saga lib provides a separate saga-lib-guice maven artifact that already implements SagaProviderFactory forwarding all instance creation requests to Guice.

If no dependency injection library is used the consumer of the library is responsible to create a saga instance itself. The following code snippet shows a simple example of a SagaProviderFactory implementation supporting only one type of saga (MySaga).

public class MySagaProviderFactory implements SagaProviderFactory {
        @Override
        public Provider<? extends Saga> createProvider(final Class sagaClass) {
            return () -> new MySaga();
        }
    }