Side question about architecture/design when you do this kind of S.A.S.E. stuff:
I think I'm missing something important. My first reaction to the S.A.S.E. idea is, "Hey, cool! Very parallel and decoupled. Processes don't need to know ahead of time whose requests they will respond to or who they will send results to. It's all up for grabs dynamically at run time."
But when thinking through the implementation a little bit, it seems that the datatype of the payload *does* need to be known on both sides of the comm link so that the sender can package it and the receiver can interpret it. So now things are back to being more coupled again, and the advantages are less obvious.
I don't really view things as parallel processes interacting, but rather hierarchal processes, where the higher-level "callers" use the API defined by the lower-level ones. Just as in regular programming API's, the low-level code is not dependant on the higher-level code, and the higher-level code has to deal with the datatypes returned by the low-level code.
As for Datatype coupling, that seems less important than communication coupling. That "the 'Temperature' module publishes a Temperature as a number" is less coupling than "the 'Temperature' module sends its readings only to a single Queue named 'main_UI'".