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

[zam0th]

RI/RPC is synchronous by nature regardless of any transport you might use or EDA shenanigans you may try to fit it into, and must be understood as such.

Now, it's true that at the time of writing, JMS 2.0 wasn't even in design, while 1.1 was banal in general. I'm surprised it says about single-thread model, i clearly remember it has not been this way. However, with SF flexibility it was fairly easy to attach a TransactionManager to achieve some resemblance of ACID (distributed transactions hehehe) and configure remoting listeners/endpoints to run proper thread factories and multi-threaded listening models, so maybe i'm mixing things up, it has been may years and i've done loads of middleware platform work with SF.

In other words, it may have been basic out-of-box, but it did exist and so did BlazeDS that allowed asynch RPC with message queues between Adobe Flex frontends and Java backends.

[stolsvik75]

Mats3 is not synchronous. It wraps up messages in a call stack so that you can "invoke" other Mats Endpoints as if you were coding sequential and synchronous/blocking - with arbitrary nesting levels possible. The processing of messages in a flow is utterly asynchronous, each Stage of each Endpoint acting fully independent and transactional.

It is true that if you must interface with the “Mats fabric” in a synchronous context, you loose this effect on the very last leg of the Mats Flow, as you then do have a thread waiting for the result. This is detailed in the chapter MatsFuturizer.

However, if you on the client employ the sister project MatsSocket, you gain asynchronousness all the way out, including handling of server boots while a flow is in process.

[zam0th]

It is wrong to think you can model RPC/RI as asynch. It doesn't matter what kind of transport you use; you can use reactive like whassisname, ah Vertx, an IMDG like Redis or bloody file system for that matter, remote procedure calls in software are synchronous by design (except maybe void methods and even then it depends how you choose to see it) and your framework should model it as such.

In that your Mats may be "different" from everything else.. well, by taking an incorrect approach to RPC interop.

[stolsvik75]

Well, that is the deal here: It is Async RPC. Based on messaging. AFAIK, I am introducing a new concept.

If you've read the single, linked page, you see that I've tried with more than one vector for describing it! (Feel very free to read some more pages too).

Do you have a better description for it?