The only thing that bothers me about this approach is that it is more difficult to send a message for a special case. Forcing one to send a notification just for the sake of sending a message doesn't seem reasonable.
Putting the logic to create and send messages into the ChannelAdapter and sending a notification to it would fully isolate the MessageBus communications. Encapsulation not only of the message sending facility, but of the message class itself would be optimum from a maintainability and reusability standpoint.
Lets say you have a Pipes based app but feel it's more complicated than what you need and want to switch it over to MessageBus. Or lets say you started with message bus because it was easier and later decide you want to switch to pipes as your app grows a little and it offers something you need. I think it's reasonable to expect both these scenarios to play out once the MessageBus utility is available.
So, if you're creating Pipes messages all over the app, then you have a lot of refactoring to do on to move to MessageBus and use MessageBus messages. If you're going the other way and you're creating a lot of MessageBus messages all over the app, you've got the same problem.
But if all communication with other modules is truly incorporated in one actor then it's a matter of switching the JunctionMediator for the ChannelAdapter, and giving the latter the same notification interests that the former had. That notification interests list codifies in one place all the known external communications.
-=Cliff>