Re: EJB 3.0 simplifies enterprise bean types
Arved Sandstrom wrote:
Depends on the size and composition of the project, but you won't be far
off. Thing is too, even with EJB 1.x once you figured out the techniques for
one class of beans - CMP entity beans, BMP entity beans, SFSBs, SLSBs, how
to set them up and code them and call them - it was all boilerplate after,
and didn't add that much to the effort. For any project that has hundreds
(or more) EJBs of various types I don't suppose the simplifications matter
all that much. I'll agree with Lew that the coding model is indisputably
cleaner, but I doubt we're saving much time because of it.
It's been bugging me since EJBs came out - when is it worthwhile to use 'em?
Many developers I knew were gun-shy of EJBs, having used them. I've used them
on jobs - unwieldy sometimes, but always a few folks in the shop understand
them well. Heck, I've written and debugged them, too, but the rationale for
their existence never seemed much beyond, "The architect said to put 'em
here." Excuse me, "The Architect said ..."
One alternative is POJOs; repeat for each web app. It's not too hard to write
the same component many times (copy-and-paste helps, natch). True, there are
fragilities in the build-from-common-skeleton approach. Are they worse than
the difficulties with EJBs? Holistically, you must consider both coding and
operational effort.
Maybe it's the way people used them that's soured me. Maybe I just haven't
seen well-rationalized EJBs in practice.
I'm playing with Glassfish now, and portal, seeking the Renaissance ideal of
rapid development AND deployment. Facility with the tools should yield
insight into their proper niche.
One place I see the call for EJBs is Transaction World. and the work world
abounds with demands for multiple access points to common application
services. (Example: Separate GUI, custom XML and SOAP web service endpoint
access to an online shopping site.)
The mentality of the "new" EJB appeals to the way I think. Instead of
thinking about "Home" and "Remote" interfaces and keeping them straight from
the Java keyword sense, I'm thinking about business logic and message flow
with hooks into the enterprise framework. It's more like aspect-oriented
programming - the EJB-ness offers hatchways into shared context.
It is possible to deploy EJBs now, and JPA stuff, with relatively light
reliance on orthogonal XML deployment descriptors. Too many deployment
environments I've seen have put the "ugh" in "spaghetti". At least with the
3.0 way that is not required.
What is the true power of EJBs?
What is the right way to use them?
--
Lew
You are in a maze of twisty little passages, all alike.
- Crowther and Woods