There is a web-based application intended used by 10,000 people in one day. Should I use WAR only or EAR (including EJB)? I don't need the distribution feature of the EJB. However, is transaction management a problem if I use WAR (JSP, Servlet, Beans, Tags, ...) only? Thanks a lot.
Hi Arfoo, I guess you want to ask if you should use J2EE or not. In that case we have to consider features supported by J2EE like, - scalability - transaction mgmt - persistent store by JMS - workflow specific support by TimerService like APIs that can act similar to CRON jobs in unix based systems and schedular in windows systems etc... for e.g. While I am working a project that is so far webserver based, 1. I wanted my application to persistently store the state even if the webserver crashes and I worked on that design little bit 2. I wanted to support more users to my system and for that I needed some cache system and a broker object that mediates b/w DB and Cache and all 3. I wanted to have my application easy to manage and configure 4. I wanted TimerService like functionality badly.. 5. I wanted to pool JDBC connections so I thought about designs for each of the issues and it seemed to me that I can do it by myself but it would be nice if I can concentrate more on the business logic than inserting myself into maze of technical issues I was gonna face if I implemented all by myself....and thats where I thought- J2EE is the thing I should start looking into... I am sure this is the same course of action that leads ppl to use J2EE eventually.... So, I guess you should look into your system and identify what are you needs. If you just need a single service that J2EE provides and if you think you can implement it then you can avoid J2EE. After all, for a single thing we can't take whole J2EE on our head because J2EE, of course, comes with lot of issues being complex in nature... Hope this helps. Maulin