Slashdot Mirror

← Back to Stories (view on slashdot.org)

EJB 3.0 in a Nutshell

Posted by michael on from the with-sprinkles dept.

Rusty Nuts writes "JavaWorld has a great article on the future of Enterprise JavaBeans (EJB). Are you frustrated learning EJB 2.1 or already know EJBs but loathe its complexities? Hold on a bit more for the the future of EJBs is looking brighter for you."

4 of 27 comments (clear)

  1. Book recommendations by LizardKing · · Score: 2, Interesting

    I'm quite happy with using Java Servlets and JavaServer Pages - they're great technologies that clearly address shortxcomings on what came before.

    However, Enterprise Java Beans make my brain ache. I've tried reading a couple of books that had reasonable reviews on Amazon, but I've still not got much confidence that I could use them well. Can anyone recommend some decent books on EJB's, or is it not worth the bother?

    1. Re:Book recommendations by bay43270 · · Score: 4, Interesting

      You should be happy using servlets and jsp. Together, they provide you with most of the functionality you will ever need. Most companies switch to J2EE because IBM and Bea spend a lot of money pushing it. They think they need J2EE for these features:
      - Transactions
      - Persistance
      - Security
      - Scalability

      Transactions (like the servlet api) are provided via an API subset that you can add to any program (J2EE or otherwise).

      The J2EE persistence layer is almost silly. It would take a bit of writing to explain the historical reasons for the mistakes, but essentially Entity Beans were made to fulfill a need that no one had (client side references to server side persistable objects). Sun then changed their mind as to what need they filled (they are now simply a persistence model), and then kept making improvements to compete at this new task. Almost any other persistence model runs as well and they are all less complicated. J2EE 3 promises to improve on both fronts, but by leaving backwards compatibility, they haven't really reduced the learning curve much.

      J2EE also has method level declarative security. Since the declarations are in the deployment descriptor, their not really dynamic. This isn't anything really exciting either.

      Scalability is a bit difficult to argue. The lighter weight alternatives to J2EE (servlet containers, Spring, etc.) may scale to a decent size, but I haven't seen any example of huge applications being run with these solutions. If anyone hears of an Ebay sized app running on a Tomcat cluster, please post.

      If you really want to learn EJB still, I would look for an entry level J2EE job. The books explain the implementation details, but I have yet to see any give honest explanations of when you should use parts of J2EE and what their limitations are.

  2. ejb3 sounds like a hack by npgmr · · Score: 2, Interesting

    Hey, this's suppose to be professional programming right? Why does this ejb3 way of programming looks so much like a hack and is not backward compatible?

    Anyone can take a look at the spec. and you will know what I mean. I'd rather stay away from those arcane annotation style, and stick with Hibernate/Spring/XDoclet.

    If something has been done, might as well try to co-exist with them. If trying to compete, fine, but at least do it properly. With those new stuff, it's not going to earn any more respect than EJB 2.x.

    Sometimes it's good to be non-backward compatible, but not in this case.

  3. Re:Spring, Hibernate... by mcbevin · · Score: 4, Interesting

    Sure Hibernate is years ahead of any entity bean effort. But so is JDO already.

    I find JDO and Hibernate both really nice technologies. The main difference being that JDO is a standard with multiple implementations (mostly commerical), vs Hibernate being a single open-source project, and that JDO uses code-morphing vs Hibernate just using reflection, which makes JDO more powerful but requires a post-compilation code-morphing stage.

    If Sun would take either of these and replace the entity beans with them in the next J2EE spec that'd be great. But how do you come to the conclusion that JDO is basically going to be Hibernate?? JDO _is_ already on a level with Hibernate both in features and ease of use. JDO 2.0 brings a few good features missing from the JDO 1.x spec, but other than that is no major change.