Why JavaEE / EJB3?

[Marc E]

Greetings all,
For a current project, I'm trying to decide whether to stick with how
we've always done it or whether to invest the time, energy, and resources
into making it a full J2EE app. I've never worked with ejb, jms, etc before.
The "way we've always done it" is Tomcat/jsp/jstl/pojo. No servlets, no
MVC, no need for multiple clients (swing vs. html vs. mini devices), no need
for internationalization. just straight up database (via jndi and datasource
setup in server.xml) and html (ala jsp).

What i'm trying to guague is whether moving to java ee will reduce our
complexity and maintenance, save coding time, and basically just help me get
this damn thing out the door as quick and painlessly as possible, given our
needs.

1) have to be able to run this on a cluster of servers with session
failover. load balancing is done with cisco hardware (I think). but if user
1 hits server a on one request and server b on second request, obviously his
session has to move with him. IDEALLY, ear/war files would all be in one
location, say, a NAS device, with all nodes in the cluster pointing to that
one deployed file.

2) need to manage 3-4 different environments with the least amount of pain
possible: dev, test, staging, prod. problems would be in location of the
code relative to the server, database names (datasource name would be the
same, but the URL for the database would be different in all 3
environments), etc. for example, on dev, the code might live at
\\server\share\code\version but on prod it would be at
\\server\someothershare\share\code

3) all the other usual requirements: session/application state, etc.

4) a handful (less than 5) chunks will be exposed as web services. typically
we've done this via AXIS with good results.

5) we'd be using jboss/tomcat if we went the java ee route

6) eclipse plugins that would help get people up to speed would be nice

7) easy debugging. don't want to have to restart the server everytime a
change is made to a jsp or class file

I suppose the problem is that since i don't know much about the java ee
stack, i don't know at all how, if at all, it can help me solve these
problems or solve them with less complexity than would be involved in just
sticking with the current method. I imagine the scenario i describe above
is so common that everybody does it and that there are thousands of articles
and opinions and best practices.

Forgive me if i'm not asking the right questions...possibly i don't even
know what questions to ask without learning more about the java ee stack.
i'm currently doing that right now and am hoping for some guidance.

thanks a lot for all opinions.

Marc

 

[Alex Hunsley]

Greetings all,
For a current project, I'm trying to decide whether to stick with how
we've always done it or whether to invest the time, energy, and resources
into making it a full J2EE app. I've never worked with ejb, jms, etc before.
The "way we've always done it" is Tomcat/jsp/jstl/pojo. No servlets, no
MVC, no need for multiple clients (swing vs. html vs. mini devices), no need
for internationalization. just straight up database (via jndi and datasource
setup in server.xml) and html (ala jsp).

Hi Marc
a book I recommend to people asking themselves this question:
"J2EE Design and Development, Expert one-on-one", Rod Johnson, published
by Wrox Press Ltd.
Early on he covers good reason to use, or not to use, J2EE solutions.
lex

 

[Marc E]

Thanks Alex. I'll check it out. any thoughts of your own on this, given
your experience?

 

[Scott Ellsworth]

For a current project, I'm trying to decide whether to stick with how
we've always done it or whether to invest the time, energy, and resources
into making it a full J2EE app. I've never worked with ejb, jms, etc before.
The "way we've always done it" is Tomcat/jsp/jstl/pojo. No servlets, no
MVC, no need for multiple clients (swing vs. html vs. mini devices), no need
for internationalization. just straight up database (via jndi and datasource
setup in server.xml) and html (ala jsp).

We have done both the 'big J2EE' apps and the little 'CRUD from
database' apps, and have found that both approaches can work, but that
J2EE has a lot of overhead. We hope this will improve with EJB3.

In general, we only go to J2EE when there is a compelling reason, but if
there is one, WebLogic or JBoss, here we come.

I would suggest picking up Hibernate first. You can then continue to
use Tomcat/JSP/JSTL/Pojo for most of your presentation layer, but can
move the database calls to the backend. This isolates you from SQL at
the presentation layer, and is a good first step to J2EE.

Since EJB3 looks a lot like Hibernate, the effort is not wasted. Even
if you decide not to go with EJB3, you still have a useful persistence
layer that you know.

It is also a good way to further divide the presentation and backend.
You can move to something like JBoss fairly easily, so you get some
container managed data sources.

If you do go JMS, consider ActiveMQ over the built in JBoss messaging
system. We found it ran a lot faster. YMMV, of course.

1) have to be able to run this on a cluster of servers with session
failover. load balancing is done with cisco hardware (I think). but if user
1 hits server a on one request and server b on second request, obviously his
session has to move with him. IDEALLY, ear/war files would all be in one
location, say, a NAS device, with all nodes in the cluster pointing to that
one deployed file.

Beware of this. We found order of magnitude slowdowns when our ear and
war files were stored on a NAS. Better is to have an autodeploy system
that pushes it from a central NAS to all of your deployed servers
automatically. (Better still: test it and see, as you may have gotten a
better NAS than we did.)

Scott

 

[Alex Hunsley]

We have done both the 'big J2EE' apps and the little 'CRUD from
database' apps, and have found that both approaches can work, but that
J2EE has a lot of overhead. We hope this will improve with EJB3.

In general, we only go to J2EE when there is a compelling reason, but if
there is one, WebLogic or JBoss, here we come.

I would suggest picking up Hibernate first. You can then continue to
use Tomcat/JSP/JSTL/Pojo for most of your presentation layer, but can
move the database calls to the backend. This isolates you from SQL at
the presentation layer, and is a good first step to J2EE.

Since EJB3 looks a lot like Hibernate, the effort is not wasted. Even
if you decide not to go with EJB3, you still have a useful persistence
layer that you know.

Would just like to add here that Torque is quite nice XML based
persistence layer - and simpler than Hibernate for some things. It's not
very heavyweight, though.