+972 52-548-6969
Messaging Concepts - Conversation > Saga > Message
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.
Comments
aka a workflow or orchestration of services possibly?
Actually the term Saga originated fro the world of databases:
www.rgoarchitects.com/Files/SOAPatterns/Saga.pdf:
"Hector Garcia-Molina and Kenneth Salem defined the term Saga back in 1987 as a way to solve the problem of long lived database transactions. Hector and Kenneth described a Saga as a sequence of related small transactions. In a Saga the coordinator (database in their case) makes sure that all of the involved transactions are successfully completed. Otherwise, if the transactions fails the coordinator runs compensating transactions to amend the partial execution.
I also don't think that saga is limited to the scope of a single service. It is a shared context of related messages that can invovles a lot of services that share that context.. Naturally you also have to account to that within each of the services somehow
Arnon
@henke
Orchestration of services is different since there you have an external party (the orchestration engine) which controls the flow, where as in sagas the services are autonomous and drive the flow individually
Arnon
Hello Ayende,
SSDL is a metadata language that supports the kind of multiparty conversations you're describing above. Look at http://ssdl.org and especially the SC framework therein at http://ssdl.org/docs/v1.3/html/SC%20SSDL%20Protocol%20Framework%20v1.3.html.
Jim
I agree with last comment from Arnon. Sagas is much more around flow around autonomous services, and conversation (as conversation scope) around a flow in an orchestrating service.
Do we need different wording to define a flow involving more than one service? The orchestration vs choregraphic aspect sounds transversal...so I would vote for 1 word-concept : conversation.
"Conversation" is naturally understood as a cooperation between actors having one aim.
What you're describing is BAM in an EDA environment:
A service which subscribes to events published by other services and can show what's going on across service boundaries.
Like you mentioned, this is useful for tracking, debugging, auditing, and reporting. But, the thing is, the "conversation" you describe cannot replace the necessary long-running state management required by each service.
Udi,
Indeed, it is not meant to.
State is either in a saga (part of ongoing process) or part of the system data.
Comment preview