There is an overloaded acronym here
MC -> MicroContainer (I'll use this one :-)
MC -> Messaging Core
"ju...@jb..." wrote :
| Right. At which point the question that comes up is why there is need for two implementations of fast, synchronous, in-VM bus implementations?
|
| If the Messaging Core is capable of equal performance to MicroContainer bus, should it then be placed as the bus for the MicroContainer?
|
The MicroContainer Bus is just a switching mechanism
name -> object reference (which can be aspectized to have a "container")
The Messaging Core is a "container" implementation for message routing which could be
remote/local, synchronous/asynchronous, reliable/unreliable, etc.
The Message Core only becomes a bus when you put a broker in front of it
e.g. for the jms facade, create channels that implement queues/topics and add them to the destination manager.
Other brokers/buses are equally possible as front ends (including the MC bus),
in the same way as you can have a byte code engineered class, a dynamic proxy
or some other front end to an AOP aspect chain.
The "container" could equally be an aspectized POJO with an enhanced version
of the asynchronous/remoting aspects (e.g. add reliablity).
You shouldn't confuse the two responsibilites:
1) Dispatch based on a name/indirection (the bus)
2) The method/aspects of the dispatch (the container)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3887177#3887177
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3887177
|
