This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
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
Author

WAR or EAR

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: 1871
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
 
GeeCON Prague 2014
 
subject: WAR or EAR