Database Reference
In-Depth Information
The need for sagas
A saga is a design pattern that was originally coined in a paper by Hector Garcia-Molina in
1987,
http://www.amundsen.com/downloads/sagas.pdf
.
To quote a piece:
"A long-lived transaction (LLT) is a saga if it can be written as a sequence of transac-
tion that can be interleaved with other transactions."
In Arnon Rotem-Gal-Oz's topic on SOA Patterns, page 137 says:
"Sagas are a way for services to reach distributed consensus without relying on dis-
tributed transactions."
It is expressed by many references that sagas may be built differently, depending on the
need.
A saga pattern is supported by NServiceBus; for more information see
ht-
tp://docs.particular.net/nservicebus/sagas-in-nservicebus
.
A saga handles the persisting of
pieces of messages as part of an ESB. During a workflow of messages, a message is sent to
a saga; the saga persists the needed data and responds to the original client with messages.
A saga itself is a data object with an ID, getters, and setters. As messages are passed back
and forth between services, the saga is an intermediate to save valuable data. The data are
message parts.
The messages of a service bus are persisted by nature and can be replayed when there is an
issue with the delivery of the message with the endpoint; however, the saga keeps track of
the originator and can store other data to be associated with the original message. This up-
dated data, which is defined by the developer, may be the state of the message, the session
information related to the message, or any other data needed by the application. The saga
correlates messages it receives, synchronizes the activity using the corresponding ID, and
deals with other features such as timeouts and lookups.
The saga evolves in the ServiceBus architecture as a pattern; it is discussed in greater detail
in the next chapters.
Many common frameworks such as Microsoft MVC and EF are designed for business re-
quirements only, with additional frameworks to assist in nonfunctional requirements; this
point is stressed throughout this topic. Also, we emphasize the concept of ServiceBus.
