Switching from session beans to Spring remoting: what do I lose?

Hi,

Our company used to build its software projects on a 3-tiered architecture with a Swing client, an EJB server running session and entity beans and a database.

Last year we switched to a more POJO-based approach by replacing entity beans with a DAO layer using Hibernate. However, we chose to keep a layer of session beans delegating to Spring-managed POJOs. Thus we had to keep an EJB container in the architecture. This project was successful and I'm very satisfied with this replacement and Spring in general (kudos to its creators!)

Now is the time to start another project and I wonder if we should get rid of the appserver and use Spring RMI remoting instead. I understand the basics of Spring remoting in simple cases, but I can't figure out if this solution is robust and scalable enough when the number of clients grows up. With session beans, an EJB container uses pools and other behind-your-back tricks to optimize things. I'm afraid using raw RMI won't give us the same degree of performance in highly multiuser environments.

We also use other J2EE protocols (JMS, JCA...) but I think Spring (or third-party tools) offer valuable implementations or replacements for them.

What do you think? Thanks for your answers
Baptiste

The way you are designing your application, it sounds like you have enough flexibility that you can change your server side to meet your needs. For now you can start with RMI, and then as the performance starts to suffer, replace RMI with something else. You wouldn't have to change your client code (just your client config file) or your business object.

Application servers tend to extend their optimization beyond just the container. The problem with generic RMI is that it uses the default serialization of data from client to server (and visa versa). For example oracle's OC4J uses ormi, BEAs weblogic uses t3, both employ their own optimized serialization techniques which are encoded and decode by the respective stub and skeletons generated with their propriatry rmi compiler (rmic). As with any distributed architecture, network latency is usually the key area of concern and while ejb containers have been getting a rough time from the "new is good" spin doctors they do offer a great deal with regard to reducing this type of latency. You can write your own serialization optimizer but this is not only difficult but I doubt you would come anywhere near the propriatry offerings. Once you have your custom serializer it is just a matter of preprocessing the data before request-response. I am wondering if interface 21 will address this issue and provide a generic serialization optimizer preprocessor?

Hope this help and good luck with your choice. I suggest you test the vanilla spring remoting under very heavy load and see if it causes any major dramas based on current netowrk stats.

Steve

Actually, Spring fully supports BEA's T3 both on server and client, as indicated here: http://dev2dev.bea.com/pub/a/2005/09...er.html?page=3

I think using ormi will be pretty much the same, though I don't have any experience with it.

And what about local session ejb? Are where any alternative to decouple client and server code within single jvm?