General J2EE: Moving from collocated to distributed architecture

  1. Hi, I'm looking for a direction rather then an answer.... We have a J2EE application deployed on ~30 Weblogic servers. We have presentation handled by Servlet/JSPs and business logic handled by Stateless Session EJBs with DAO (encapsulating either JDBC or CORBA for access to legacy system). Since this configuration is a big hit in licensing cost, we are looking for alternative architecture/deployment and would like to evaluate alternative of splitting web and app servers. We do understand the performance implications of such a move but are willing to pursue this direction to see what will be a cost gain versus performance lost. It looks like we need to move towards an architecture, where we'll have more web serevers and less app servers. So... here is a question: what tools/metrics or methodology should we use to describe alternative architecture with required CPU,Memory and number of Web/Application servers. I would appreciate any direction towards available tools and literature that would assist us in this task. (and yes :-) we do consider switching from Weblogic to open source app server as another alternative to drive costs down)
  2. easiest thing to do is to simply switch to JBoss(has a proven track record.), if your application is following the J2EE specification(it works on 30 weblogic servers it sounds like u guys did a good job)... if it was a new project i would use Spring/Hibernate & Terracotta.
  3. Check statistics of every web request, If you have multiple backend request(EJB calls/Corba calls) then your proposition may change. And check the h/w configurations of different tier systems. Have powerful h/w for appservers compared to webservers. If want to minimize licensing cost, Can think of moving your web apps to i.e. tomcat and use Weblogic for ejbs and other serious stuffs.
  4. the low-cost way.. Apache LB, or hardware LB | | \/ Tomcat(JSP containers) | | \/ Apache LB, or hardware LB | | \/ J2EE(Jboss farm)
  5. A couple of years ago we were in a similar situation and we decided to replace our JSP,servlets and EJBS. First of all you need come to a conclusion about the advantages of using EJBs/Appservers. If it is just scalability and object pooling you using the EJBs for, I don't see much point in it as the same thing could be easily achieved by using other lightweight yet powerful and popular open source frameworks. How about using POJOs and Spring using *commons object pooling* , hibernate for DAO layer and going the SOA way accessing your distributed services through webservices or RMI (or even JINI to access distributed components if you could afford the luxury of using it) all deployed on a tomcat server? A lot of banks in the UK use spring for their mission critical transaction processing system.