This is awesome. I have been thinking of a similar idea.
Separation of concerns... Core "messaging" implementation separated from the
overall messaging solution, allowing multiple messaging solutions with
varying needs to be maintained separately while also making it possible to
replace the engine implementation easily:
----------------------
messaging-solution
----------------------
| * client API
| * transaction management (including XA, if so desired)
| * features (such as Virtual Topics)
| * message containers (queues, topics, chat rooms, private message
rooms)
| * persist message for longer-term access, as-needed
|
| <--- *** Messaging Engine API
|
V
---------------------
messaging-engine
---------------------
* persist messages for guaranteed delivery (only; and not a required
feature of the engine)
* route messages
* transaction support
* enable enforcement of order
* moving messages to endpoints
NOTE: this needs more thought; the separation above may not be a good
dividing line, but I hope it makes my thinking more clear.
One key I see here - the ability to create a complete messaging solution
that is tuned to specific use-cases (e.g. small, embedded architecture; or
large, enterprise messaging backbone), while using the same engine. And,
the means to replace the engine with another one as long as the API is met.
James - is this in-line with your idea?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/PROPOSAL-Pluggable-Brokers-tp4694058p4694072.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
