There's another thread that asks the question "What do I need to know to write/use EJBs?" here. My question about Head First EJB is this: Does it give us any help on when to use features? For example: When do I want to use BMP (or some other means of storing data) instead of CMP? When does it make sense to use Session Beans and JDO vs Entity Beans? Please note that while I am interested in the answers to these questions, I'm more interested in whether Head First EJB covers these kind of things. Thanks!
SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
For reasons best known to Sun, EJB best practices and patterns were not included in the objectives of the exam. BTW the objectives read like contents of the specs leaving out all references to earlier versions of EJB. When and whether to use EJBs were naturally beyond the scope of specs. Hence I do not expect these to be covered in Head First. Kathy has mentioned elsewhere that these were included earlier but were dropped later as the book was getting too big and this chapter would be available in web site. Best wishes
Hi Burk, A very good point raised by you. Infact all the books of EJB , Ed-Roman, Oreilly, Wrox depicts BMP,CMP, BMT, CMT but none of them has a very explicit explaination as to when to use what in case of real -life based scenarios. I think if this book covers that it would be great. Rishi SCJP,SCWCD,IBM/OOAD
Howdy Burk, Great question, and I wish I had a better response... we cover *some* of these issues directly, but not all, and in some cases, not much. We do talk about session vs. entity beans, when to choose which, quite a LOT in the book, because that's relevant to learning about the bean lifecycles and behaviors in great detail. For some issues, we are assuming/hoping that in the context of learning what is REALLY going on within the Container, some of the decisions will become obvious (as opposed to some of the really stupid choices we've seen EJB developers make simply because they did not understand how it all worked). We do talk about session vs. entity beans, when to choose which, quite a LOT in the book, because that's relevant to learning about the bean lifecycles and behaviors in great detail. What we do NOT really talk about is choosing JDO vs. Entity beans. The exam covers entity beans, and we felt it was just out of the scope of the book to go down that road. We simply couldn't do a good job of making it a good certification book and include too many outside topics (because, as I said, the book is already 750 pages, 100 more than it was supposed to have). We believe these topics are important, though, and some will be on the web site soon. We also do not cover BMP, and we no longer feel that as of 2.0, the CMP vs. BMP discussion is relevant (although it was EXTREMELY important with EJB 1.1). Although one still may, rarely, find a reason to need BMP, it is far less likely with EJB 2.0, and really just for very special cases. So it was not worth covering in the book, especially since it is not on the exam for the same reason. Third-party benchmarks keep confirming that CMP performs better than BMP in almost every conceivable way (although again, there can be exceptions) and that it is really up to the vendors on how many optimizations they do with CMP. But there are just SO many reasons to go with CMP -- speed, efficiency (again, the multi-vendor benchmarks like ecPerf, even with EJB 1.1, showed CMP outperforming BMP in nearly every case), and especially the ease with which you can develop portable beans (and queries) that are not tied to a particular database. Anyway, I know that this can be a little controversial, but it is the path that Sun has taken, the industry supports, the J2EE team has confirmed with customers and vendors, and we stick to it with the certification exam book. We talk *a little* about WHEN using EJB is appropriate, but this book assumes that you have already made the decision to LEARN the technology, and this book is all about *learning* it inside and out, and again, we hope that it becomes obvious that when you do not need either the services provided by the Container, or the scalability, that you might really have to think hard about whether EJB is appropriate. But as Bert has said, you can't have one book that really does *everything*, so we've tried to do the best job we could with TWO serious goals: 1) Helping you really *get* the core concepts of EJB at a deep level of understanding, in the quickest possible way (and least painful). We believe that this understanding will do more to promote good development than anything else, and we don't believe there's any book that covers these deep details in the way that we do (and must, since they're on the exam!) 2) Helping you prepare for and pass the exam. If we tried to go beyond that, or make it an advanced EJB tips and tricks and best practices development and deployment book, it would have been at the expense of our first two objectives, and we wanted to be very clear about our focus. But that's not to say the book isn't full of tips / best practices scattered througout the various topics where they appear. Still, you make a compelling point about this "When is at least as important as WHAT", and I *do* think we could have put more of this in the book than we really did. We'll try to address some of that on the web site. So, you make a good point, and this is my best defense of why we have only a limited part of that in the book. Perhaps another question might be why this wasn't on the exam... and perhaps the WHEN question will show up on a future version! We tend to start with the most technically objective questions in the first version of an exam, and introduce more patterns/practices/subjective issues only carefully, and later in the life of the exam. Because these types of questions/objectives on the exam provoke a LOT of controversy -- with people claiming that one person's "best practice" is another person's "really bad idea". But this question of WHEN is fairly straight forward, and has certainly been abused, as EJB's have sometimes gotten a bad reputation because they were used when they shouldn't have been. There's even a point in our book where one of the characters gets really upset about what a lame idea it is to go to ALL this trouble of using EJB for such a small payoff, just to do a Hello World application, so, we appreciate the problem... anyway, good question and now I wish we'd done more! -Kathy [ October 29, 2003: Message edited by: Kathy Sierra ]