As mentioned earlier, sagas are a design pattern. They are not unique to NServiceBus but are common in most enterprise service bus systems. There are many references to sagas, for instance, http://vasters.com/clemensv/2012/09/01/Sagas.aspx and http://msdn.microsoft.com/en-us/library/jj591569.aspx. These details are discussed in greater detail later. For now, we will expand on the payment engine example we have been exploring.

First, a saga in NServiceBus is always started and updated by a message.

Even when a timer is fired, a message is created. This timeout message is to be handled by the saga—refer to the following class diagram.

In the class diagram, there is message that starts the saga container from Service1; this means that the message is originated from the service that communicates with the frontend. A saga data is created and saved to the database. This data may be retrieved when the message passes the saga again; this means that the data that was saved for a message from Service1 may be retrieved on the return trip from Service2. Therefore, when returning from the payment service, persisted data can be retrieved and the message can be updated with data that is not directly passed to the message.

There is a lot of debate on how sagas are used, mostly relating to how sagas can be extended and used in multiple ways. However, the basics remain the same. A message starts a saga, a saga saves the data that is associated with the message, a saga handles other types of messages, a saga is able to lookup the original message that it started with, a saga is able to add data to the original message, and a saga routes messages to different destinations.