I used to be on board with this vision, but I've become less convinced of it as time has gone on. In fact, I was originally planning on coding the JMS core class DIRECTLY to the remoting framework in order to avoid the IL crap currently implemented in the JBossMQ code base. I'm no longer convinced that this is the ideal solution. While I do see value in implementing a JGroups transport in the remoting framework. I just don't see that value in JMS.
Frameworks are a very nice thing, and I'm generally very supportive of them. In fact, I think the remoting framework is wonderful. However, sometimes a framework that abstracts another framework is actually counterintuitive and makes getting the job done more cumbersome. In fact, you often spend a lot of time working around the abstraction to regain the power of the underlying framework. In my mind, this is the likely result of using the remoting framework to expose the JGroups framework to the peer-to-peer JMS implementation.
It depends how good the framework is.
e.g. JBoss clustering has an abstraction on the top of JGroups
that is used elsewhere. But Sacha still implemented the
cache invalidtion directly on JGroups.