Comments on: Saga implementation patterns – Controller

By: Scott Banwart's Blog › Distributed Weekly 199

Scott Banwart's Blog › Distributed Weekly 199 — Fri, 22 Mar 2013 09:00:18 +0000

[...] Saga implementation patterns – Controller [...]

By: Saga implementation patterns – variations | Jimmy Bogard's Blog

Saga implementation patterns – variations | Jimmy Bogard's Blog — Thu, 21 Mar 2013 02:13:38 +0000

[...] Command-oriented (request/response) in the Controller pattern [...]

By: Nick

Nick — Mon, 18 Mar 2013 16:55:00 +0000

Gotcha. That makes a lot of sense Jimmy. Cheers

By: jbogard

jbogard — Mon, 18 Mar 2013 16:00:00 +0000

This is the model I prefer for coordinating workflows inside a bounded context. Makes things much more explicit and obvious.

By: Nick

Nick — Mon, 18 Mar 2013 15:23:00 +0000

I was meaning a business workflow, as in a use case of the system which spans multiple services.

I read the article again and can see what you mean now. I wasn’t used to seeing sagas used like this when – Udi and others always seem to be talking about pub/sub. I’m sure this has its place though.

By: jbogard

jbogard — Mon, 18 Mar 2013 14:38:00 +0000

I’m not sure what the difference is – you could implement a workflow inside an NServiceBus saga. A saga could live inside each one, yes. But I might still have something orchestrating the whole affair.

By: Nick

Nick — Mon, 18 Mar 2013 09:44:00 +0000

Is that really a saga? It looks more like a workflow because it touches multiples services (payments, shipping, fraud). From what I know, which is not a lot tbf, a saga would live inside one of those.

If actions need to occur in a certain order, then a message is put back on the queue until it can be processed – i.e. the other actions have completed and left the system in the required state.

Genuine questions.

By: jbogard

jbogard — Fri, 15 Mar 2013 22:29:00 +0000

You’re right – there are a few different ways to model this.

I might have the saga send a bunch of commands and wait for replies, or I could have the saga publish a message and wait for events on the other side.

But it’s not impossible for a saga to observe a process it doesn’t initiate. Imagine our grillers. They don’t initiate a saga, but there’s a clear interaction between the grilling and building of a sandwich, usually by two different people. It’s the interaction between the two that signifies a “done” sandwich.

By: jbogard

jbogard — Fri, 15 Mar 2013 18:18:00 +0000

It could be, but it’s really the subsequent messages that make it a controller/observer.

In our McDonald’s example, we could have the initial “PlaceOrder” command begin the saga, or the “OrderAccepted” event do it instead. Either way, the lifecycle is either dictated by requests/responses or an events all around.

By: Phil Cleveland

Phil Cleveland — Fri, 15 Mar 2013 17:03:00 +0000

How is the Saga initiated? Is the Saga itself a Command Handler? Or is there some abstraction (e.g. SagaManager), which is a Command Handler signed up to the command bus? Or am I missing some piece completely? Thanks