The default for JBoss is optimized in this case, since the MDB:s use an in vm connection factory. But it does not mean that your MDB is not "accessable" from the ouside. All JMS destinations are accessable, and thereby the MDB:s.
Let me tell you my assumptions so that you understand the analogy I am trying to make.
I assume that even in a cluster, if I use EJB references, I am guaranteed that the EJB I create will be running on the same JVM as the creator.
Even thought I may have the remote object running in several JVMs of the cluster, each one will keep any servicing local EJBs, on their own local machine.
What I would like to have the ability to do the same with JMS processing. Have the JMS messages sent by EJBs running on one machine, being served by local instances of the MDB, just like with the analogy with local EJBs.
Today, you could do such thing by binding a separate JMS queue/topic to the same jndi name on each machine in the cluster, but that sounds like a deployment nightmare. It would be much nicer, if the JMS implementation would keep things separate for you. So you just bind the same "local" queue/topic and you get the desired effect.
Hi, I am sorry but I have not looked into the cluster stuff yet, the only thing I do know is that there is not cluster support in MDB or in JBossMQ. Anyone that want's that would have to contribute it ;-).
As for destinations in MDB and other EJB the default is allways local. You have to change the ProviderAdapter to get remote destinations to work.
You might however benifit from the "automagic code" in MDB:s. If you deploy and MDB with a destination that does not exists, a temorary one (allwasy local) is created. This might be dangerous (the destination is not there when the MDB is not deployed, and the destination will be destroyed when the MDB is undeployed) or great because you can skip setting up destinations.
If you have other ideas how to implement the MDB container, pleas contribute ideas and code snipets.