Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Programming

EJB 3.0 in a Nutshell 27

Posted by michael 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."
This discussion has been archived. No new comments can be posted.

EJB 3.0 in a Nutshell More

EJB 3.0 in a Nutshell

Comments Filter:

  • Book recommendations (Score:2, Interesting)

    by LizardKing ( 5245 )

    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?

    • Re:Book recommendations (Score:5, Interesting)

      by bay43270 ( 267213 ) on Friday August 13, 2004 @01:19PM (#9961255) Homepage
      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.

      • You should be happy using servlets and jsp

        Um, no thanks. JSP sucks. Having code in the UI layer is a big no-no. JSP's are hard to maintain. I agree with you that J2EE persistence with EJB's sucks, but you can certainly do a lot better than jsp and servlets.

        Check out Tapestry [apache.org], a much better way to write web apps than JSP, using MVC so that your html page is just an html with certain id's on some tags, and you have components that can be placed inside other components to make up a page. Or use Struts. Or

        • with struts I've been able to have no code in my JSPs at all. it's not that hard, you just have to spend more time designing it.

          I'm not attacking your or making any claims about your skill level. Slashdot is a festering buch of he said she said bullshit and I want to make sure folks are clear.

          happy java coding!
        • In typical slashdot fashion, you've taken my comment totally out of context (and removed the context so no one would notice). I was trying to point out the huge overhead of J2EE, and how a lighter framework is more useful in most situations. You only proved my point further by suggesting even more useful lightweight frameworks.

          You are right, in that JSP isn't the cleanest solution. Tapestry is much cleaner. I've seen demos of velocity.. it just looks like another syntax of jsp to me. I don't see how i
          • Yup, sorry.

            I read the parent to your post AFTER I replied to you. Actually I think my original post goes more to the grandparent than to you, since he was saying that J2EE is too much bloat and that plain JSP and servlets was enough (clearly not the case and you already know it).

      • Re:Book recommendations (Score:3, Insightful)

        by ekuns ( 695444 ) *
        The most obvious reason for using J2EE that I can see (perhaps the only reason for the great majority of apps) is JMS. Other than that, most of the J2EE stuff is much too heavyweight for most applications.

      • Re:Book recommendations (Score:1)

        by Anonymous Coward
        I've been a POJO programmer for a while and recently got into an EJB project (with some trepidation). The first book I grabbed was Rod Johnson's Expert one-on-one J2EE (which was the progenitor of Spring). Excellent book. I learned a lot from it; especially which parts of EJB were good (SLSB) and which are bad (entity beans).

        EJB 2.0 is not a complete solution -- and I don't see 3.0 being that way either. Luckily, the Java community provides us with the grout to fill in the cracks of our projects: we ju
    • EJB has so many problems. And EJB is NOT NECESSARY. Take a look at Rod Johnson's book Expert One-on-One J2EE Development without EJB [amazon.com]
    • Can anyone recommend some decent books on EJB's, or is it not worth the bother?

      I used to teach at USF. I had a simple sample application coded many different ways for the students to study. You can find that sample code on this page, http://testbox3.menlo.edu/demo/ism410/faves.html [menlo.edu].

      The last two code samples linked from this page feature EJB code. One uses a stateless session bean and the other one also uses a Bean Managed Persistance entity bean.

      This is a little out of date but the samples were desi

  • A small step in the right direction (Score:5, Informative)

    by metamatic ( 202216 ) on Friday August 13, 2004 @12:59PM (#9960967) Homepage Journal
    One of the biggest failings of EJB 1.x and 2.x was that there was no standardization around deployment descriptors. This made a mockery of "write once deploy anywhere", because every different combination of application server and EJB container required a different mess of XML files before it would accept your EAR file and deploy your application. Naturally, all these files had completely different tools for generating them, and sometimes the tools weren't driveable from standard build tools like ANT.

    Now with EJB 3.x they're promising to make a half-assed attempt at solving the problem. Now you'll annotate your Java code, and the vendors will supply tools to turn the standard annotations into their proprietary deployment files.

    So, you'll still have to deal with a mess of different tools, and you still won't be able to deploy the same application EAR anywhere, but at least you'll only have one set of syntax to learn to specify the deployment information, and you'll be able to keep the info in the same place as the actual code. So, a minor improvement.

    Other stuff looks to be just as muddle-headed as before. Yay, a new syntax for EJB QL, to make it almost exactly the same as the SQL it was supposed to be a simple alternative to. Of course, nobody in their right minds uses entity beans anyway [pobox.com]...
  • ...on EJB3 here [freeroller.net]. A sample:

    Also, is anyone else distraught by the obsessive use of the acronyms POJO/POJI? While it's understandable that a bunch of open sores asshats enjoy indulging in this fappery, I find it highly upsetting that this 'street lingo' has made its way into a supposedly professional serious spec. Is it so hard to say JavaBean/Interface? What's even funnier is that in every case, the POJO/POJI silliness is never used standalone, but always in paranthesis after 'regular java bean' and 'regula

  • Spring, Hibernate... (Score:5, Informative)

    by chochos ( 700687 ) on Friday August 13, 2004 @03:21PM (#9962734) Homepage Journal
    I heard some rumors that the new JDO is basically going to be Hibernate (probably with a gazillion interfaces on top of it that will make up the JDO spec). To me this feels like Sun has accepted defeat in that area. Hibernate is obviously years ahead of any entity bean effort, so it makes sense that they make it the new JDO. Shouldn't they do something similar with Spring? I've been using it, and I must say it's pretty cool and powerful. I HATE EJB's, and Spring offers a much more flexible way to work with beans. You can have stand-ins for JTA, pooled datasources, etc which make unit tests a lot easier. It doesn't seem like EJB 3.0 will be able to run out of their J2EE context yet, so Spring will still be useful for this, and it gives you a lot more independence from the app server.

    • Re:Spring, Hibernate... (Score:5, Interesting)

      by mcbevin ( 450303 ) on Saturday August 14, 2004 @04:00AM (#9966262) Homepage
      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.

      • If you RTFA, it says JDO is using something very similar to the Hibernate Query Language.

        From what I've seen, Hibernate is not using reflection; it's using CGLIB, which if I understand correctly, generates code on the fly to speed up invocations that would normally use reflection, without the need to do post-compilation code-morphing. Perhaps it uses reflection for some stuff but it is my understanding that they're using runtime code generation for the parts that would become bottlenecks were they using

  • The EJB Bible (Score:2, Informative)

    by jnana ( 519059 )
    Every you need to know about EJBs is in this book [amazon.com].

    And yes, Spring [springframework.org] is an incredibly powerful, flexible, and *simple* framework to use. I don't know that I've ever used the terms elegant or beautiful for software remotely related to J2EE, but Spring is amazing.

    And no, I'm not involved in the project. Just a happy user.

  • ejb3 sounds like a hack (Score:2, Interesting)

    by npgmr ( 451808 )
    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 t
    • "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?"

      It's a new major version. EJB 3.x vs EJB 2.x. Most professional people consider this is the only time where it is acceptable to break backwards comaptibility.

      If Sun needs to break backwards comaptibility to simpify EJBs, I'm all for it.
      • "If Sun needs to break backwards comaptibility to simpify EJBs, I'm all for it."

        Just like the diff between java 1.4 and 1.5?

        I didn't know there's a need to specify version when I compile a c/c++ program. Btw, I'm a SCJP and I think Java is great. But the annotations is not something inside the comment, but part of the language! Is this really needed?

        Anyone who had used XDoclet and Hibernate would know that EJB 3 is not doing something new. The change is not technical, but commercial, in my opinion, t
        • I think a lot of the changes in 1.5 are a response to C#. But I don't think this is a bad thing, and if you don't use the new constructs and APIs and provided you don't tell the compliler to target 1.5 only, then any code you write in 1.5 will be backwards compatible.

          Also, I think annotations do belong with the class/method/field rather than in the comment. XDoclet is an excellent product but the only reason they overloaded the use of @tags in comments is because they couldn't put them in the actual source
  • That title makes me wonder what sort of nut would have that shell. Coconut's too small...

Slashdot Top Deals

Be sociable. Speak to the person next to you in the unemployment line tomorrow.

Close