I would say that using J2EE architecture and EJB is most useful if you don't have
specific performance needs. When you don't have leeway on performance
you have to bite the bullet and use whatever gives you the performance you need.
Obviously EJB2.0 OR mapping is a huge key, this allows the full usage
of CMP as it's intended. CMP is a huge benefit since it puts more code on the
shoulders of the server vendor and not the application developer(or a
separate team of developers). And using a standardized architecture that is supported
by multiple app server vendors(who are in multiple price/quality
arenas) is a benefit in my eyes as well.
In the past we've done our own code generation for OR mapping, and at first it did not
handle transactions and connection pooling for you. We had to
upgrade it and maintain it to provide these features. With J2EE servers you get all
that stuff without having to maintain the code for it -- we've
upgraded our tier that has this code about 5 times over the past year and a half!
Probably the majority of us out there right now are inbetween a
pre-J2EE/EJB solution and a post solution. I'm looking forward to EJB2.0 and plan on
writing or using one code-generator for CMP Entity beans and
possibly generating Session Beans as well, or Session Bean shells for the different
interfaces and such. This will take care of the 'time-to-develop'
problem, remember, the use of EJBs is supposed to cut development/maintenance time.
Also you get a fully distributed system(probably the performance hit) which has it's
benefits if the application scope is right. Can the tiers of
business code you have written be accessed(re-used) by any app running on any machine,
no matter who develops it(VB team vs. Swing team vs. JSP or ASP
teams)? If you've implemented them using RMI then you may be able to, but again you
end up doing the maintenance and upgrades on that code too.
Even with all the benefits I've listed, I'm not developing production code with EJBs
just yet - one prototype application is all - the bleeding edge of
EJB looks to be a sharp one if the project/application isn't right for it.
The bottom line is time to market and a solution that fits the price - bigger
customers can afford to wait a bit and pay for WebLogic and the like - but
this list is most probably filled with us smaller company types who cater to smaller
customers.
Hopefully this info is useful -
Matt
