Comments on: Saga Persistence and Event-Driven Architectures

By: Living in the Tech Avalanche Generation » NServiceBus - Linq To SQL Saga Persister Part 2.0

Mon, 07 Dec 2009 11:52:32 +0000

[...] how to use the extensibility points provided by NServiceBus to create a persistence mechanism for Sagas. Notice I said two persisters, one for LINQ To SQL and another for the Entity Framework, this post [...]

By: Getting Started With NServiceBus: Part 3 Sagas « Plan B Software

Getting Started With NServiceBus: Part 3 Sagas « Plan B Software — Tue, 03 Nov 2009 01:24:01 +0000

[...] gives a much better explanation of them here and there is some more information about them on the NServiceBus Wiki [...]

By: Testing Message Handlers with NServiceBus » Kang The Koder

Testing Message Handlers with NServiceBus » Kang The Koder — Sun, 27 Sep 2009 10:33:32 +0000

[...] is a dll called “NServiceBus.Testing” which provides us with the ability to easily test your sagas. This enables us to move forward with greater confidence in knowing that the code that we have [...]

By: Living in the Tech Avalanche Generation » A Linq To SQL Saga Persister for NServiceBus

Mon, 21 Sep 2009 12:57:41 +0000

[...] features in the technology of our choice, and the subject of this post regards extending the Saga Persister. However at this point let me just say that it may well be worth your while to read Udi’s post on [...]

By: Andy Z

Andy Z — Thu, 18 Jun 2009 13:50:45 +0000

After sending my last post I realized that the object which is receiving the event notification will likely not have access to any context other than the domain object itself. So, if the domain object (in this case the Customer) does not have an associated list of Email domain objects there may not be a way to add an Email domain object into the context of the Customer or to hold on to an email request and have it sent as part of (or directly after) the context in which the Customer object exists is serialized.

I hope that this apparent problem is just my lack of understanding rearing its head and not something which is difficult to overcome.

Thanks again,
Andy

By: udidahan

udidahan — Fri, 12 Jun 2009 21:05:10 +0000

Raghunath,

Not all sagas have very much state-management to them.
Many are just simple integration pieces.

I have no direct problem with things being declarative, it’s just that that’s not an end unto itself, but a means that does not make sense in all cases.

Hope that makes sense.

By: Raghunath

Raghunath — Thu, 11 Jun 2009 11:10:10 +0000

Udi,
I see the direction saga would move towards.
I may be vague in what I say, I was just thinking if some thing like what is said this post http://blog.pixelingene.com/?p=32
is possible with saga using concepts such as
– Saga
– Initial Trigger
– Event Messages
– Transitions
– Handler
and linking programmatic saga thro XAML Extensions which save you lot of hand-written code improve readility.
I also see WF4 also being more declarative.
Thanks,
Raghunath

By: udidahan

udidahan — Wed, 10 Jun 2009 18:26:24 +0000

Raghunath,

There is some interesting some going on in declarative saga declaration in the Mass Transit project – that is under consideration for inclusion in nServiceBus.

“I think the code base could gets voluminous, lot of code and time consuming”

What I’ve found is that these sagas don’t just pile up but belong in the context of higher-level business services and bounded contexts. This partitioning prevents things from getting out of hand.

About the “time consuming” parts, well, it’s really not. The fact that the code is isolated from most everything else, as well as being highly unit-testable (with the NServiceBus.Testing library), removes most obstacles from getting it functional and stable – performance and scalability are handled “by default” by the messaging aspects around it.

Does that answer your questions?

By: Raghunath

Raghunath — Wed, 10 Jun 2009 06:54:19 +0000

Udi you post have been great. Recently I have been refreshing thro an earlier read of NService Bus and Saga.
As I have understood long running process flow(consiciously avoiding the word workflow), effectively implemented in state machine scheme of things constitute a Saga. Saga represented a blueprint of process flow and on how it is supposed to behave in deterministic manner. We could have numerous instance of this blueprint aided by the messaging infrastructure, SagaMessage and handler.
When we go ahead try to implement various such process flow in the form of numerous blueprints of saga library I think the code base could gets voluminous, lot of code and time consuming. Thinking in this direction would it be helpful to make some portion of saga declarative. By declarative part I do not mean config associated but could we think of declarative saga using XAML which self describe the saga in XAML if possible associating declarative saga with programmatic saga.
If that would be task, I would like to understand, from you, thoughts on what it would take to do such a thing.

By: Martin

Martin — Tue, 21 Apr 2009 19:56:52 +0000

Thanks for this great post explaining Sagas!

By: Habib

Habib — Tue, 21 Apr 2009 06:13:05 +0000

The clearest explanation of “Saga” i have ever seen.
Thank you very much.

By: DotNetShoutout

DotNetShoutout — Mon, 20 Apr 2009 12:44:40 +0000

Saga Persistence and Event-Driven Architectures…

Thank you for submitting this cool story – Trackback from DotNetShoutout…

By: BjartN

BjartN — Mon, 20 Apr 2009 12:36:35 +0000

Well written and interesting. Thx.