Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

WAR or EAR

 
Arfoo Huang
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic