JBoss remoting w/ JGroups & JMS

[tom.elrod]

I intend on implementing a JGroups transport layer within the JBoss Remoting module. I know that the new JMS implementation already has P2P support based on JGroups directly (which is where the idea originally came from). Therefore, it may not make sense to try to integrate the jboss remoting version into JMS once it is done, since the same capability already exists. However, I think the jboss remoting implementation can be useful in other applications (such as JMX Remoting). So it will be there if there is a desire to use it.

IMHO, I think it would be good in the long run to have all jboss projects use jboss remoting, where there is a good fit. The main reason for this is so there is not duplicate remoting code in different projects.

Also, I would like to contribute to the JMS project if help is needed. I know there are a lot of people working on it, so just let me know if/where I can be of use.

[nphelps]

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.

[adrian.brock]

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.

Regards,
Adrian