I've been putting in some time for a little ninja project at work. The plan is to get rid of JBoss and switch to ActiveMQ, Spring Remoting with Lingo, Spring MDPs instead of MDBs and plain old Tomcat for the web apps.

So far I've removed JBoss and updated our proprietary command execution framework to use Lingo. I haven't really tested very much at all, but so far it's at least working good enough for me to load the server and log into our rich client.

In doing so I chose Lingo since it lets me use JMS for normal remote calls and for async calls. Previously our command execution framework internally used JMS for the async case, which required special handling. With Lingo I have one solution that does both, which is nice.

The downside to Lingo is that there is no proper integration with ACEGI security. There is some information on the web that claims a proper integration exists, but all they do is pass the authenticated username to the server in a JMS header. That is of course totally unacceptable since without secured queues/topics anyone could send any username. At the very least they could send username and credentials to force a re-authentication on every remote method invocation, which would be quite inefficient. It would be nicer if instead they passed the entire SecurityContext (which is what ACEGI does for standard Spring RMI remoting) and then use that to authenticate on the server. Ideally there would be a session, just like with ACEGI and Http remoting, so that we don't have to re-authenticate all the time.

I haven't looked at Lingo/ACEGI in detail, but this is something I might attempt to do in future. For now I'm just passing around the SecurityContext and handling authentication in our proprietary framework outside of Lingo.

Anyway, overall the transition away from JBoss has been pretty smooth. I've been able to delete a ton of XML configuration files and code to deal with our own JMS remoting implementation. Lingo with ActiveMQ is much more straight forward to use and configure.

Hopefully soon I can get around to plugging in standard Tomcat and porting over our webapps. Of course I also have to do some performance testing along the way. :-)