struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitchell Morris" <>
Subject RE: [OT]: Struts, Web Development, J2EE, and what is too much?
Date Wed, 12 Mar 2003 01:56:38 GMT
As always, you get what you pay for.

If your goal is to minimize the amount of developer effort expended, it's
going to be hard to do less work than you would with Hibernate. The downside
is that Hibernate isn't exactly high-performance as compared to your own
compiled code; this isn't surprising since most of the heavy lifting is
accomplished via static reflection which is traditionally 10-15 times slower
than directly compiled function calls. Each version of the JDK improves that
ratio somewhat, but it's probably never going to get all that close to 1.
The upside is the cache is built-in and you don't have to write much (if
any) extra code to get persistence.

If what you want is raw performance, then straight JDBC is probably your
winner (caveat attached below). Abstractions add expressivity and
flexibility, but the cost is generally measured in performance metrics. The
downside of direct JDBC is you have to write your own O/R mapping code, or
write/use an O/R mapper like CoCoBase or Jaxor. You also have to write your
own caching code, even if you decide to use Turbine JCS or TopLink ... they
only provide the API and you're still on the hook for the glue.

Either way, you've got some work ahead of you. But that's why we're raking
in the big dot-com dollars, right? BWA-hahahahaha. Ahem.

Arguing for EJBs for purely performance reasons is Marc Fleury of the JBoss
project. His thesis is stated in <URL:>, and I
wouldn't reject his thinking out of hand given the track record of the J2EE
container he's spearheading.

sometimes-more-is-more-ly y'rs,

> -----Original Message-----
> From: Molitor, Stephen []
> Sent: Tuesday, March 11, 2003 12:44 PM
> To: 'Struts Users Mailing List'
> Subject: RE: [OT]: Struts, Web Development, J2EE, and what is
> too much?
> Aaron,
> You've opened up a big can of worms!  There is much debate on
> this topic.
> Regarding entity beans and transactions:  The recommended
> practice is to use
> the 'Session Facade' pattern to wrap access to your entity
> beans  inside a
> stateless EJB session bean.  The reason is remote calls to
> entity EJB's are
> too slow.  Instead, only use local interfaces for you entity
> beans.  Your
> Struts actions would never talk to entity beans directly;
> instead they would
> call 'service' methods on session beans.  This also means you
> need lots of
> little data transfer beans to transfer the data in and out of
> the session
> facade.  (Or you can sacrifice explicitness and type safety and use
> dyna-beans.)  The session facade also provides a good place
> for transaction
> boundaries.  An action will usually call one method on the
> session bean, and
> that method is a transaction.  The user hits a button, and
> either all his
> changes or saved, or they all get rolled back.  That kind of 'atomic
> request' is a nice simple transaction model that works for
> most situations.
> However, there is a lot of extra effort involved in creating
> the session
> facades and data transfer objects, and keeping them in sync.
> Example:  the
> xPetStore application, which shows how to use xDoclet, was implemented
> twice, once using EJB, and once using just Servlets and
> Hibernate (an open
> source O/R mapping tool).  Excluding the code that xDoclet
> generated for
> you, the EJB version still had more than twice as many lines
> of source code
> in the business tier compared to the Hibernate version.  So
> even with a tool
> like Xdoclet, there is still significant extra cost to doing EJB.
> Also, as Robert alluded to, EJB entity beans don't really support
> object-oriented development.  A good OO domain model is typically fine
> grained, with inheritance, relationships to other objects,
> etc.  The fact
> that entity beans don't allow re-entrancy (object 'a' calls a
> method on
> object 'b', which calls a method on 'a'), inhibits your
> entity model.  Of
> course, if your business model is simple, that might be OK.
> IMHO, the only compelling reason to use EJB is if you need to
> provide access
> to remote Java clients to your business tier.  (Web services
> are another
> option that also supports non-Java clients.  But they do add
> overhead.)
> Even there, I would just use session beans, not entity beans.
>  In our app,
> we're using Struts with Hibernate and doing everything in the
> web container.
> We have a servlet filter that start, stops and rolls back the
> transaction;
> the 'atomic request' approach.  Getting EJB out of the mix
> really simplified
> things for us.  We do have a few cases where a remote Java
> client needs to
> talk to our business tier, so we will probably use EJB remote session
> facades for that.  But we'll only do the extra work when and
> where we need
> it.  Hibernate allows you to declaratively cache read-only
> objects.  (Or
> read-write too, if you're not using a cluster.)
> Ted Husted has an example app on his page using Struts and
> Hibernate.  OJB
> is another popular option.  Long term, JDO may or may not
> catch on .  All of
> these tools over true transparent, object-oriented
> persistence, in stark
> contrast to EJB entity beans.
> Steve
> -----Original Message-----
> From: Robert McIntosh []
> Sent: Tuesday, March 11, 2003 10:39 AM
> To: Struts Users Mailing List
> Subject: Re: [OT]: Struts, Web Development, J2EE, and what is
> too much?
> Tony made some good points, and my take is that from your
> requirements,
> you may not need EJBs. However, if you layered your app sufficiently,
> then if you end up needing them later on, it shouldn't be too
> much of a
> problem. Of course I am assuming you are referring to Entity beans in
> this case...
> As for when to use EJBs, what I have always recommended to
> our clients
> is that EJBs are good for large scale applications that run
> on clustered
> machines and require transactions at the entity bean level. The
> transactions are good if you have multiple apps and clients that are
> modifying the same data. If your app is largely read only, it is the
> only one interacting with the data and you aren't worried about
> concurrent modifcation, then you probably don't need entity
> beans. Yes,
> most app servers can cache and mark entity beans as read-only
> or mostly
> read-only for performance, but there are other ways of doing
> the same thing.
> Another thing to consider is how your object model is
> designed. If you
> have lots of inheritance, entity beans aren't going to fit you well.
> Same can be said if you have complex query requirements (joins,
> relationships that the object model doesn't support, etc.).
> Then again, in some cases as Nash pointed out, EJBs can be
> simplier from
> the perspective that any good app server can build the
> database for you
> and with tools like XDoclet, you don't have to write deployment
> descriptors and you don't have to maintain (i.e. code) the interfaces
> for home, remote and local.
> - Robert
> Aaron O'Hara wrote:
> >I know this question has probably been asked before, and that biased
> >publications have had their opinions on it, but I wanted to get some
> >feedback regarding some "real user experience" regarding the
> use of EJB
> >in a web application used along with Struts.
> >
> >I am creating a web application and I have decided to use
> struts.  The
> >application needs to be high performance, uses a single
> database (so it
> >doesn't have heterogeneous transactional db requirements).  I have
> >designed the application in layers, and it will only have a web
> >interface.  It's starting small, but will grow to have many
> functions.
> >Even though I'm confident that I need not invest in EJB's, I
> don't want
> >to develop the application to find out I should have used them (hence
> >why I'm creating this post).
> >
> >In what scenarios have people found the use of EJB beneficial?  When
> >have they been overkill?  Does struts integrate smoothly with EJBs?
> >
> >My fear is that I'll make the application overly complex by
> implementing
> >EJBs, but I'd like to hear from people with experience building large
> >web-only projects with struts.
> >
> >Thanks,
> >
> >Aaron
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> >
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message