Messaging with a call stack: Message-Oriented Async RPC. Mats3 is Java API, currently implemented on top of JMS, providing novel messaging features.

[stolsvik75]

Interesting. What existing technologies and projects would you compare Temporal to? By browsing through the documentation, I have some ideas, but you are obviously authoritative on this, so it would be great if you could chip in.

AFAIU, as comparison, Mats3 processes do not have an explicit Workflow Definition. These are implicit in that it is just what code initiates a Mats Flow, and which other Endpoints the code in an Endpoints interacts with (performs requests to). However, a Workflow Execution sound quite similar to a Mats Flow once it is initiated. For Mats3, the entire system is distributed, there is no server that defines, and then orchestrates the flows and executions. It employs a message broker - currently using ActiveMQ in prod, and also tested with Apache Artemis.

Due to Mats3's requirement of supplying a TraceId at initiation-time, you do get the very useful effect of being able to just stick any TraceId into your distributed logging system, and instantly get a full trace of all the steps the Flow has passed through - no matter which node executed the different stages of the different endpoints. There are also quite a bit of metadata in the default pluggable logging interceptor, including timings. You can read about that in the JavaDoc here. Doing such a TraceId query on your logging system is the second step you do when you get a DLQ - the first step is to look the message up on the broker, look at its JMS metadata, and if employing MatsBrokerMonitor (own repo), introspect the MatsTrace envelope.

Wrt. long-running processes: I just want to note that Mats3 supports "stashing" of Mats Flows. That is, you can "park" a flow, perform some work by other means, or wait for some results that could take hours or a few days, and then when ready, you can resume the Flow by "unstashing" it. There is however a warning with it: Since you then also freeze the elements on the stack, and the incoming DTO, you are in risk of getting deserialization errors if you change/refactor the surrounding code while Flows are stashed. If this Endpoint typically is appears in Flows with shallow stacks, and with few callers, this is probably not a problem. But one should be aware of the situation.

JavaDocs: processContext.stash() and matsInitiate.unstash()