views:

749

answers:

4

What are the primary reasons for using the J2EE (EJB's) over just a simple servlet implementation?

I am working on developing a new project that will primarily be a web service that must be very fast and scalable.

Sorry for any confusion, Although I am experienced in Java, I am very new to the Java Web world, and may not be asking this question well.

+2  A: 

Is the web service stateless? If so, I don't see any real advantage in using a full blown JEE server over something lightweight like Tomcat or Jetty. You can deploy a jax-ws implementation with either of those, and do what you need pretty easily. If there's some kind of state involved, and you end up wanting to share that across multiple machines, that is where having JEE can come in handy.

With that said, I don't think JEE would decrease performance any at all. The app servers generally take longer to boot, and take more effort to manage, but once they are up and running the performance should be similar.

Brian Yarger
I agree that JEE app servers will cluster solutions nicely, but that's not the only reason for using them. Typically Web Services should be stateless (or non-conversational) and so statefulness is not a common driver for using JEE. I think that we see method-level security and non-trivial transactional requriements as stronger drivers towards full JEE EJB solutions
djna
+1  A: 

If your web services are likely to need any degree of "enterprise" features such as per-method security or transactions use EJBs.

With EJB 3 this is not actually very hard at all, a couple of annotations and you're done.

Otherwise simple POJOs behind a servlet are enough.

djna
"...If you web services are likely to need any degree of "enterprise" features such as per-method security or transactions use EJBs..." - not true at all if you're using Spring. You can do both those things and much more without EJBs.
duffymo
Yes, you're right about Spring. Would you agree that technically we can do Web Services with out-of-the-box JEE, POJOs, servlets - but for some requirements we would benefit from Spring? Would things such as per-method security and transactions be two such requirements?
djna
+4  A: 

EJB's specification 1.x and 2.x added complexity that for most webapps was not needed.

Due this complexities the new frameworks appeared to simplify the development and the runtime architecture ( Hibernate / Spring / other microcontainers / others ORM frameworks ) .

EJB's 3.x matches this changes ( through JDO and JPA ) and now, using Servlets with these enhanced frameworks or Java EE with EJB 3 + would give you basically the same results.

Using a Java EE Application Server would add you a number of administrative advantages ( GUI to manage pools, logs, monitoring, transactions etc. ) With out them you may have the same result but you would have to do it all by hand ( editing configuration files that is ) Which may not seem too problematic, but if you plan to have an administrator for your webapp It would be better to use the admin tools that come out of the box with this servers.

OscarRyz
Thank you Oscar, that is very good advice about the administrative advantages.
jW
+3  A: 

Servlets are HTTP request listeners; they can't respond to anything else.

If you embed a great deal of logic in servlets it won't be available to any other clients.

Write your app in POJOs. Get it thoroughly tested without an app server involved. Then worry about how you'd like to package and deploy it. Servlet? EJB? Web service? Something else? No problem - those are just packaging and deployment issues. Get the behavior that you want working properly in POJOs first.

Spring can give you a lot of options here. I'd recommend it.

duffymo
EJBs these days are pretty much POJOs, POJO + some annotation and they can have bothe RMI and Web Service interfaces. Using something such as Spring (or EJB 3 ;-) is good advice.
djna
True about EJB3. Open EJB makes it possible to run them without WebLogic or WebSphere, but I'd still prefer Spring.
duffymo
Thanks, I like your advice about just starting in POJO, and then worrying about the web server package. That sounds like a great plan, and it is good to hear that it isn't too painful to package it up for different containers.
jW