File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: WAR or EAR