Mssaging system represent a single action or event. Most messaging scenarios, however, deals with multiple messages. Sending and receiving a message, as a simple example. Most complex message flow span many messages, and may stretch over long period of time. When Udi Dahan has introduced the notion of a saga, I was thrilled. Here there was a way of dealing with complex multi message flow with almost effortless ease.
But a saga is limited to the scope of a single service. Quite often, a single operation in the system span multiple services. Sagas no longer suffice to give us a good view about what is going on in the system. In an attempt to use a term which isn't already heavily overloaded (transaction, operation, interaction), I picked the term conversation. Another term that I also heard is chain, as in chain of messages. But I like conversation better.
A conversation is an aggregation of all the actions that happen in a system as a result of a some unique trigger. Notice that we are talking about the entire system here, not about a particular service. A conversation spans services, and sagas.
A simple example would be the order coffee at Starbucks again. I start the conversation by asking the cashier to give me some coffee. The cashier notify the barista, and starts the payment authorization process, accept my money, tell the barista to release the drink, and move on to the next customer. There are at least three different sagas in separate services here that we deal with. A conversation (represented by the conversation id, of course) allows us to follow the track of all the actions taken as part of this conversation.
Unlike the concept of a saga, a conversation is used for tracking, debugging, auditing and reporting. It is mostly an offline tool, which I envision as some searchable repository for all the related messages and other meta data related to that particular conversation.