http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Udi, Indeed, it is not meant to. State is either in a saga (part of ongoing process) or part of the system data. http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment7http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment7Thu, 06 Nov 2008 21:18:40 GMTWhat 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. http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment6http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment6Thu, 06 Nov 2008 21:16:46 GMTI 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. http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment5http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment5Thu, 06 Nov 2008 09:42:46 GMTHello Ayende, SSDL is a metadata language that supports the kind of multiparty conversations you're describing above. Look at [http://ssdl.org](http://ssdl.org) and especially the SC framework therein at [http://ssdl.org](http://ssdl.org)/docs/v1.3/html/SC%20SSDL%20Protocol%20Framework%20v1.3.html. Jim http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment4http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment4Thu, 06 Nov 2008 09:42:07 GMT@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 http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment3http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment3Thu, 06 Nov 2008 06:02:58 GMTActually the term Saga originated fro the world of databases: [www.rgoarchitects.com/Files/SOAPatterns/Saga.pdf](http://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 http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment2http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment2Thu, 06 Nov 2008 06:00:04 GMTaka a workflow or orchestration of services possibly? http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment1http://ayende.com/3675/messaging-concepts-conversation-saga-message#comment1Thu, 06 Nov 2008 03:43:42 GMT