File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes WAR or EAR Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "WAR or EAR" Watch "WAR or EAR" New topic


Arfoo Huang
Ranch Hand

Joined: Jul 30, 2002
Posts: 31
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

Joined: Nov 04, 2001
Posts: 1873
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
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.
I agree. Here's the link:
subject: WAR or EAR
It's not a secret anymore!