We can attach our routing slip to the original message, so that each step can inspect the slip for the next step. A routing slip represents the list of steps (and the progress), as well as a place for us to stash any extra information needed further down the line:
Routing slips don’t exist in NServiceBus, but it turns out it’s not too difficult to implement. It turns out this pattern is a well-known pattern in the messaging world (which, in turn, borrowed its ideas from the real world): the routing slip pattern. As long as the steps don’t deviate from the plan once started, we don’t need to have any more “smarts” in our steps. Not all orders have the same set of steps, but that’s OK. Each step’s job is to simply perform its operation, and once completed, pass the order to the next step.
My order then flows through the system based on the pre-defined steps:Įach step doesn’t change the order, nor do they decide what the next step is (or even care who the next step is). The only decision to be made is to inspect the order and write the steps down. Once I place my order, the sequence of steps to fulfill my order are known up front, based on simply examining my order. In our sandwich model, we need to tweak our picture to represent the reality of what’s going on. Nor is there a need for a central controller to figure out the next step – we already know the steps up front! The key differentiator is that there’s nothing really to coordinate – the process of steps is well-defined and known up front, and individual steps shouldn’t need to make decisions about what’s next. If only one centralized worker coordinated all steps, it’s difficult to imagine how this level of throughput could be achieved. Henry Ford’s Model T rolled off the assembly line every 3 minutes. Humans have already found that assembly lines are great ways of breaking down a long process into individual steps, and performing those steps one at a time. Nor does the order in which we do things change much. Many times, however, there’s no need to worry about compensations in case of failures. But is there really any decision to be made in the picture above? In a true saga, we have a sequence of steps and a set of compensating actions (in a very simplistic case). Not quite clear in this picture is that if we were to model this process as a saga, we’d have a central point in which all messages must flow to for decisions to be made on the next step. They come at a cost though, with the shared state and single, centralized processor.īack in our sandwich shop example, we had a picture of an interaction starting a process and moving down the line until completion:
Process managers offer a great deal of flexibility in modeling complex business processes and splitting out concerns. However, the general problem of message routing doesn’t always require a central point of control, such as is provided with the saga facilities in NServiceBus. In the last few posts on sagas, we looked at a variety of patterns of modeling long-running business transactions. Saga alternatives – routing slips 26 April, 2013.
0 kommentar(er)
