J2EE or just JSP/Servlet?

[Pete]

Hi,

I would just like to get some advices from you guys.

I am working on the development of web software that is going to
connect on an big Oracle database and generates different charts (i.e.
a scoreboard system).

I want to develop it using the Java/JSP/Servlet technology because I
am very familiar with the Java language and I've tried JSPs in the
past.

The system is likely to be used by a hundred of persons each day and
it will have to generate a lot of charts and graphics by connecting to
the DB. To do this, I will use the JFreeChart API.

My big question is should I use Tomcat and a strictly jsp/servlet
solution or use something like JBoss to integrate some EJB in the
process (and have a more J2EE compliant solution).

I'm still not sure which questions I should ask myself to be able to
answer this problem.

I find cleaner to put strictly the user interface layer in the JSPs
and put all the code in the JavaBean or EJB (I still have problem
differencing these two concepts though (JB and EJB)...). Does Tomcat
allow that or will I need EJB if I don't want my JSPs to be polluted
by tons of java code???

And does Eclipse and Lomboz sounds like a good idea for the
development of such a project or should I look elsewhere?

Also, would it also be a good idea to integrate Struts in this project
or Struts is just for J2EE projects?


Thanks a lot,

Pete

 

[Chris Smith]

My big question is should I use Tomcat and a strictly jsp/servlet
solution or use something like JBoss to integrate some EJB in the
process (and have a more J2EE compliant solution).

I'm still not sure which questions I should ask myself to be able to
answer this problem.

The big ones are:

1. What problems do you expect EJB to solve?
2. Is EJB the best solution to those problems?

EJB is designed to contribute things like very basic security (meaning
I've never worked on a project where EJB's declarative security is
sufficient to meet the more unusual requirements), concurrency,
transaction support (though more confusing than useful unless you've got
distributed transactions), and O/R mapping of entity beans for very
simple object models. My own rule of thumb is that the instant I need
distributed transactions, I start considering EJB. Other people would
draw that line a lot closer, though. (It seems, for example, like U.S.
government military contractors aren't give the choice; EJB is assumed
the instant they write a line of Java code.)

Looks to me like in your case, EJB is just going to get in the way and
make things more complex. The hard part of your application is
apparently not involved in managing transactional contexts across
multiple data sources or really anything else that EJB is good at. CMP
entity beans are definitely not a good idea for gathering summary data
for reporting purposes, so you'd be writing your own database code
anyway. A more flexible O/R mapping tool might help a little, though,
by letting you write SQL in an external context and map the *results* of
your own queries to an object model; CMP can't really do that very well.

I find cleaner to put strictly the user interface layer in the JSPs
and put all the code in the JavaBean or EJB (I still have problem
differencing these two concepts though (JB and EJB)...). Does Tomcat
allow that or will I need EJB if I don't want my JSPs to be polluted
by tons of java code???

EJB is absolutely not required in order to write JSPs without Java code.
It doesn't even do anything to help in that way. You'll want to look
into what's called the "JSP model 2 architecture" and tag libraries
(including JSTL) and plain EL (in JSP 2.0) for very effective ways to
provide a nice clean interface between JSPs and Java code. These are
the ways to solve that problem regardless of whether your application
uses EJBs to implement business logic.

And does Eclipse and Lomboz sounds like a good idea for the
development of such a project or should I look elsewhere?

I'm pretty happy with Eclipse. Lomboz would be more useful if you
decide to go the EJB route.

Also, would it also be a good idea to integrate Struts in this project
or Struts is just for J2EE projects?

Struts is a great idea for a servlet/JSP application, and in no way
means you need to choose an EJB architecture. It really is independent
of the implementation of business logic, and is more about organizing
your presentation code better.

JSF (JavaServer Faces) is another alternative to consider.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Jim Cochrane]

The big ones are:

1. What problems do you expect EJB to solve?
2. Is EJB the best solution to those problems?

[Warning - somewhat off-topic, but related questions below.]

EJB is designed to contribute things like very basic security (meaning
I've never worked on a project where EJB's declarative security is
sufficient to meet the more unusual requirements), concurrency,
transaction support (though more confusing than useful unless you've got
distributed transactions), and O/R mapping of entity beans for very
simple object models. My own rule of thumb is that the instant I need
distributed transactions, I start considering EJB. Other people would
draw that line a lot closer, though. (It seems, for example, like U.S.
government military contractors aren't give the choice; EJB is assumed
the instant they write a line of Java code.)

I always wonder why so many of the job posts I see require EJB experience.
(It seems like at least 70% to 80%.) And I wonder if they are requiring
EJB because their project really needs that functionality, or because
they've programmed themselves to think that one must use EJB for all
substantial Java projects, whether or not it's really necessary.

Do you, or others, have any take on this?

Looks to me like in your case, EJB is just going to get in the way and
make things more complex. The hard part of your application is
apparently not involved in managing transactional contexts across
multiple data sources or really anything else that EJB is good at. CMP
entity beans are definitely not a good idea for gathering summary data
for reporting purposes, so you'd be writing your own database code
anyway. A more flexible O/R mapping tool might help a little, though,
by letting you write SQL in an external context and map the *results* of
your own queries to an object model; CMP can't really do that very well.

How would you rate the Hibernate product as an O/R mapping tool?


Thanks!

 

[Murray]

I always wonder why so many of the job posts I see require EJB experience.
(It seems like at least 70% to 80%.) And I wonder if they are requiring
EJB because their project really needs that functionality, or because
they've programmed themselves to think that one must use EJB for all
substantial Java projects, whether or not it's really necessary.

Do you, or others, have any take on this?

Absolutely. There appears to be a common belief that if you're not using
EJBs then you can't say it's a J2EE app. Which of course is rubbish. EJB is
just one of many solutions to building an enterprise application. It is
often very hard to convince a customer that they don't need EJB, but usually
informing them that it will cost twice as much knocks some sense into them
;-)

How would you rate the Hibernate product as an O/R mapping tool?

Hibernate is brilliant. Just completed a major financial webapp using
Hibernate in conjunction with Spring with great success. IMO its query
language is much more flexible and useful than EJB QL and development time
and performance is faster. Of course, like Chris, I would still consider
using EJBs if the project required distributed transactions and other
advanced features.

btw, Hibernate is used as the persistence mechanism in the new EJB 3.0 spec

 

[Chris Smith]

Hibernate is brilliant. Just completed a major financial webapp using
Hibernate in conjunction with Spring with great success. IMO its query
language is much more flexible and useful than EJB QL and development time
and performance is faster.

I agree 100% with this analysis. I'd add that not only is HQL more
flexible than EJB-QL, but the mapping described by Hibernate is
generally much more flexible than that described by EJB's CMP. It
actually allows you to create an appropriate *view* of the data that's
taylored to the task you're trying to perform, which ought to be
considered the purpose of such a tool. EJB CMP generally takes an
approach where the database table and object model form a 1-to-1
correspondence and there are only very basic kinds of relationships
between entities, and the result is either poor OO design, poor database
schema design, or more commonly both. This, to me, is more important
than the query language.

Nevertheless, for Pete's situation here where the task at hand is
reporting, I would question whether O/R mapping is an appropriate take
on the problem to begin with. It will depend on the details of the
task, but many reporting applications make heavy use of derived results
from SQL, involving heavy use of aggregate functions, GROUP BY clauses,
etc. These are sufficiently different from the entity-manipulation that
O/R mapping is designed for that the O/R mapper may complicate the
application

btw, Hibernate is used as the persistence mechanism in the new EJB 3.0 spec

Is that right? That's rather exciting news, actually. Do you know a
good reference for further information?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Murray]

I agree 100% with this analysis. I'd add that not only is HQL more

flexible than EJB-QL, but the mapping described by Hibernate is
generally much more flexible than that described by EJB's CMP. It
actually allows you to create an appropriate *view* of the data that's
taylored to the task you're trying to perform, which ought to be
considered the purpose of such a tool.

I concur. Hibernate can be especially useful if you're working with a legacy
database schema that you have no ability to modify, as was the case with the
project I worked on. Using EJB CMP our object model would have been almost
as ugly as the db shema, but with Hibernate we were able to, as you say,
create a nice OO *view* of the db.

Is that right? That's rather exciting news, actually. Do you know a
good reference for further information?

I should have been more specific: the persistence mechanism in EJB3 will be
based on concepts from Hibernate i.e. the use of POJOs, similar mapping
strategies and a more complete query language. It probably won't be
Hibernate exactly, but Gavin King and JBoss people apparently had a LOT of
input into the EJB3 spec (and the pro-JDO people are crying because of it).

TSS Article
http://www.theserverside.com/news/thread.tss?thread_id=25779

EJB3 Draft Spec
http://jcp.org/aboutJava/communityprocess/edr/jsr220/index.html

 

[Roedy Green]

Hibernate is brilliant.

Does Hibernate look at your database and your class definitions and
somehow try to guess the mapping, or you do compose some XML to do
that?

I was reading a tutorial on it that said it analysed classes by
reflection. Is that just to help turn the XML map into code to
shuffle the data around?

 

[Murray]

Does Hibernate look at your database and your class definitions and
somehow try to guess the mapping, or you do compose some XML to do
that?

I don't believe there's a tool that takes an existing db schema and an
existing object model and tries to create a valid mapping between the two.
You'd have to creating the XML mapping yourself. However there is a tool
that will create mapping files from your db schema, and from those mapping
files you can generate Java code. Also you can start from the other end:
create your Java model, generate the mappings, and then generate the schema
DDL from the mappings. See http://www.hibernate.org/102.html

I was reading a tutorial on it that said it analysed classes by
reflection. Is that just to help turn the XML map into code to
shuffle the data around?

Hibernate uses reflection in several places. e.g. when accessing attributes
of the objects it persists. Say your class has several private instance
variables. Hibernate uses runtime reflection to set/get these properties,
either directly or via the getX()/setX() bean methods (depending how it is
configured). I also imagine the mapping/code generation tools would need to
use reflection at some point.

 

[Jim Cochrane]

Absolutely. There appears to be a common belief that if you're not using
EJBs then you can't say it's a J2EE app. Which of course is rubbish. EJB is
just one of many solutions to building an enterprise application. It is
often very hard to convince a customer that they don't need EJB, but usually
informing them that it will cost twice as much knocks some sense into them
;-)

Good strategy. But since it looks like there are quite a few projects
using EJB that don't need to be, apparently there aren't enough people
around to point out this cost factor to the decision makers :-(

However, I think there may be some momentum building for using "lighter"
toolsets than EJB and I suspect that within a few years these toolsets will
tend to be chosen over EJB in a significant percentage of projects.

Hibernate is brilliant. Just completed a major financial webapp using
Hibernate in conjunction with Spring with great success. IMO its query
language is much more flexible and useful than EJB QL and development time
and performance is faster. Of course, like Chris, I would still consider
using EJBs if the project required distributed transactions and other
advanced features.

btw, Hibernate is used as the persistence mechanism in the new EJB 3.0 spec

Thanks for the info. Sounds like Hibernate is truly a high-quality
product!

 

[Chris Smith]

Good strategy. But since it looks like there are quite a few projects
using EJB that don't need to be, apparently there aren't enough people
around to point out this cost factor to the decision makers :-(

However, I think there may be some momentum building for using "lighter"
toolsets than EJB and I suspect that within a few years these toolsets will
tend to be chosen over EJB in a significant percentage of projects.

It's interesting that, from what I've read, one of main goals of EJB 3.0
seems to be to build a lighter-weight version of EJB, especially where
data entities are involved. There are still going to be great
advantages to avoid some of the fundamental aspects of the EJB app
server framework, but this might help a lot.

I, too, see some momentum building against EJBs, and I see it as people
making more cautious decisions and giving less blind trust to vendors.
Gone are the days when, as Gartner famously pointed out, much money was
invested into J2EE app servers only to fail to use the "expensive"
pieces of the server. There are still some areas where the presumption
of deploying on WebSphere or WebLogic is strong (I mentioned earlier
that U.S. military contractors seem to assume such an architecture
without even a discussion stage), but commercial companies that need to
compete with production and results are certainly finding that more care
is of benefit. This isn't just isolated to J2EE app servers; a lot of
people trying to make big monolithic sales of anything over the past few
years have been struggling with customers that want to see demonstrated
results first.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sudsy]

Jim Cochrane wrote:

I always wonder why so many of the job posts I see require EJB experience.
(It seems like at least 70% to 80%.) And I wonder if they are requiring
EJB because their project really needs that functionality, or because
they've programmed themselves to think that one must use EJB for all
substantial Java projects, whether or not it's really necessary.

Do you, or others, have any take on this?

<snip>

EJBs and even J2EE are not required for many Internet-accessible
applications. There's a wide spectrum of available solutions
including Apache, Apache/Tomcat, JBoss, Apache/JBoss,
Apache/Tomcat/JBoss, WebSphere, WebLogic, JRun, etc., etc.
You could even go retro with CGI or PHP.
(no flames from the PHP adherents, please)
But there are situations where the upside of using a single,
coherent framework from a single vendor is justifiable. If you
want to avoid all the configuration issues, getting the various
packages talking to one another, etc. then having a single
platform can make a lot of sense. Only on support call to make
if things don't work the way they should...
Do EJBs make sense in large projects? I believe that they do if
you have a sizeable team. Being able to split up the development
effort into manageable chunks while adhering to published inter-
faces (from the design effort) can speed up the process. Of course
this also assumes the use of other workgroup tools such as CVS and
the like.

But now we also have to consider Web Services in these discussions...

Just my $0.02 worth.

 

[Michael Borgwardt]

Thanks for the info. Sounds like Hibernate is truly a high-quality
product!

One particularly valuable aspect of it is its very thorough documentation.

 

[Tim Jowers]

I don't believe there's a tool that takes an existing db schema and an
existing object model and tries to create a valid mapping between the two.

<snip>
I've used Cast Iron Systems Application Router, BEA LiquidData a
little, and also XML mappers and custom softwares and yet to see any
that does this. You define the XML schema for the objects and get out
XML or maybe XML Beans. The mapping work is still manual; so, I'm just
playing with spitting out web code from database using JDBC metadata
and a few slack constraints on how tables are named. Trick is how to
map the multi-table relations to code and web forms. Sounds like I
need to check out Hibernate.

Pete, do you know how computers work and understand when software is
in RAM and what the differences between static and non-static are? Do
you know how to write queues and use other data structures? If so,
forget EJB, you'll be faster on your own and with a large team would
end up with 50% who have to follow the recipe as they do not really
understand what J2EE is. Something to be said about making a framework
more complex than the problem being solved. Of course, if the team is
large, J2EE is one well-defined way to divy up the tasks.

My $.02, TimJowers