![]() In addition to the basic routing slip pattern, MassTransit Courier also supports compensations which allow processing steps to store process-related data so that reversible operations can be undone, using either a traditional rollback mechanism or by applying an offsetting operation. Combining the routing slip pattern with a state machine such as Automatonymous results in a reliable, recoverable, and supportable approach for coordinating and monitoring message processing across multiple services. ![]() Leveraging a durable messaging transport and the advanced saga features of MassTransit, MassTransit Courier provides a powerful set of components to simplify the use of routing slips in distributed applications. MassTransit Courier is a framework that implements the routing slip pattern. This dynamic behavior is in contrast to a more explicit behavior defined by a state machine or sequential workflow that is statically defined (either through the use of code, a DSL, or something like Windows Workflow). Depending upon the content of the message, the routing slip creator can selectively add processing steps to the routing slip. When all the processing steps have completed, the routing slip is complete.Ī key advantage to using a routing slip is it allows the processing steps to vary for each message. As each processing step completes, the routing slip is forwarded to the next step. The Routing Slip PatternĪ routing slip specifies a sequence of processing steps for a message. Like most things in computer science, this problem has already been solved. And this should be possible without modifying a central control point that dispatches messages to each service. In addition to being able to dynamically route messages, the business needs to allow new services to be created and added to the inventory of available services. With every service invocation being initiated by the saga, combined with the saga observing service events and responses, the saga tables gets very busy.īeyond the complexity of increasing saga responsibilities, more recently the business has requested the ability to selectively route a message through a series of services based on the content of the message. Another concern was the level of database contention on the saga tables. Now, instead of only orchestrating the transaction, the saga is responsible for identifying which services to invoke based on the content of the transaction. The saga becomes rich with knowledge, and with great knowledge comes great responsibility (after all, knowledge is power right?). Knowledge of the new services becomes part of the saga, as well as the logic to identify which services need to be invoked for each transaction. When the saga has invoked the final service the business transaction is complete.Īs the processing required within a business transaction changes with evolving business requirements, a new version of the saga is required that includes the newly created processing steps. Command completion is observed using an event or response message by the saga, at which point the next processing step is invoked. Using the existing MassTransit saga support to manage the state of the transaction, the actual processing steps are created as autonomous services that are invoked by the saga using command messages. Over the past few years building distributed systems using MassTransit, a pattern I consistently see repeated is the orchestration of multiple services into a single business transaction. With MassTransit Courier, the intent is to provide a mechanism for creating and executing distributed transactions with fault compensation that can be used alongside the existing MassTransit sagas for monitoring and recovery. Over the past few months, the community has argued discussed how the use of the word saga has led to confusion and how early implementations included in both NServiceBus and MassTransit do not actually align with the original paper published in 1987 by Princeton University and written by Hector Garcia-Molina and Kenneth Salem in which the term was coined. When sagas were originally conceived in MassTransit, they were inspired by an excerpt from Chapter 5 in the book SOA Patterns by Arnon Rotem-Gal Oz. ![]() This article introduces MassTransit.Courier, a new project that implements the routing slip pattern on top of MassTransit, a free, open-source, and lightweight message bus for the. Implementing Routing Slip with MassTransit
0 Comments
Leave a Reply. |